In general, the idea of raising a protocol error when the client tries to damage a surface with no buffer seems sensible. But the spec doesn't say damage_buffer requests must be followed by attach requests and we can't really predict the future.

Heh, I'm having some de ja vu.

I did this already, for the same situation for the same bug:
https://bugs.kde.org/show_bug.cgi?id=397834#c19

https://phabricator.kde.org/D28147

for damage()

Then damageBuffer got introduced with the existing bug!

This revision is now accepted and ready to land.Mar 19 2020, 8:35 PM

Closed by commit R127:ff9cadf00f21: [server] Don't make assumptions about the order of damage_buffer and attach… (authored by zzag). · Explain WhyMar 19 2020, 8:40 PM

This revision was automatically updated to reflect the committed changes.

Revision Contents
Changeset List

			Path	Packages
M			src/server/surface_interface.cpp (4 lines)

Diff	ID	Base	Description	Created	Lint	Unit
Base			Base
Diff 1	78041	6bfa71d		Mar 19 2020, 8:17 PM	★	★
Diff 2	78044	6bfa71d	R127:ff9cadf00f214c00b10884987bd9019838785d05	Mar 19 2020, 8:40 PM	★	★

Commit	Tree	Parents	Author	Summary	Date
31dff8e7d675	0c1035d3cac3	6bfa71d89aee	Vlad Zahorodnii	[server] Don't make assumptions about the order of damage_buffer and attach… (Show More…)	Mar 19 2020, 8:10 PM

Diff 78044

View Options

src/server/surface_interface.cpp

[server] Don't make assumptions about the order of damage_buffer and attach requestsClosedPublicActions

Details

Diff Detail

Revision ContentsChangeset List

Diff 78044

src/server/surface_interface.cpp

[server] Don't make assumptions about the order of damage_buffer and attach requests
ClosedPublic
Actions

Revision Contents
Changeset List