bug#63511: [Patch] Fix for hidden window bug

[Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Christian Schmidt <cs@aibiot.de> writes:

> prop->type == (Atom) 0 IMHO refers to an empty list, which is valid.

I'm sorry, but that contradicts the EWMH, which prescribes _NET_WM_STATE
as an array of Atom.  prop->type is only None (which is _not_ a type)
when the property is deleted.

> I would be surprised if this was a bug in E, given emacs is the only
> program I know of that exhibits this issue. I have discussed this
> issue extensively with raster, the main author of E, and we have come
> to the same conclusion: when _NET_WM_STATE_HIDDEN  the is the only
> active/set property, and then is removed/unset (sorry if my

_NET_WM_STATE_HIDDEN is not a property that may be ``set'' or ``unset''
(mind that this parlance is not X terminology), it's an element in a
property named _NET_WM_STATE.  Each window property is in fact an array
of items whose width in bits is the format of the property.

That property becomes empty when _NET_WM_STATE_HIDDEN is the only
element of that array and is subsequently removed; when that transpires,
GetWindowProperty still returns an empty array of the correct type, as
the property is still set.

The only two situations in which GetWindowProperty will return a type of
None is when Enlightenment sets the property type to None or deletes the
property in its entirety, both of which violate the EWMH.

> terminology is wrong, my days of X programming have been 20+ years
> ago, and these are corners I have never touched before), there is no
> code path in emacs that can handle this case. Also, the request does
> not hit the window manager, but it is X that replies. As such, the bug
> would lie within X11.

When a window property is changed to an empty value, its type remains
intact.  Enlightenment is not merely changing the property in this case,
but also deleting it, which contravenes the EWMH.

> What happens is that the array of atoms is empty, and thus the list is
> (Atom) 0. Currently this is interpreted as "keep the current state",
> and not to re-evaluate the (now empty) list of atoms to realize that
> _NET_WM_STATE_HIDDEN is not set.

An empty window property is empty -- its type remains intact, regardless
of the number of items within.  There's a distinct contrast between an
empty window property and a window property that has abruptly vanished.

> If that would be an issue, given there is no "unhidden" property that
> could be set, how should the WM handle this? E sets
> _NET_WM_STATE_HIDDEN when the window is hidden, and removes it when no
> longer hidden.

The window manager should empty the property instead of deleting it,
which is more or less proscribed by convention.  The removal of a WM
property from a client toplevel window should always coincide with a
corresponding change to _NET_SUPPORTED on the root window.