GNU bug report logs - #63511
[Patch] Fix for hidden window bug

Previous Next

To reply to this bug, email your comments to 63511 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christian Schmidt <cs <at> aibiot.de>
To: bug-gnu-emacs <at> gnu.org
Subject: [Patch] Fix for hidden window bug
Date: Sun, 14 May 2023 21:13:33 +0200

[Message part 1 (text/plain, inline)]

Severity: normal
Tags: Patch

At least on enlightenment, when switching virtual desktop away from the 
on containing emacs and back, emacs does not render screen updates.
This patch fixes the cause.
Analysis for the bug tracker, copied from commit message:

If no state flags are set in the _NET_WM_STATE property,
the returned X property type will be "0". This situation
occurs when "_NET_WM_STATE_HIDDEN" was the only property
set for the emacs window, e.g. in enlightenment due to
change of a virtual desktop.
In the current code this causes copying of the iconified
state in x_get_current_wm_state(), which causes emacs to
stay hidden. For DMs such as Enlightenent or Gnome Shell
that use only the hidden but not the iconified state
this clashes with the intention of handling the
_NET_WM_STATE property notification in
handle_one_xevent(), which requires not_hidden &&
FRAME_ICONIFIED_P (f) to actually activate the frame.

-- 
AIBIoT GmbH        | CEO: Lukas Grunwald
Hornemannstraße 12 | HRB 206588
31137 Hildesheim   | Amtsgericht Hildesheim
Germany

[fix_hidden_window_bug.patch (text/x-patch, attachment)]

Message #8 received at 63511 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Christian Schmidt <cs <at> aibiot.de>, Po Lu <luangruo <at> yahoo.com>
Cc: 63511 <at> debbugs.gnu.org
Subject: Re: bug#63511: [Patch] Fix for hidden window bug
Date: Thu, 24 Aug 2023 01:24:11 +0200

Christian Schmidt <cs <at> aibiot.de> writes:

> At least on enlightenment, when switching virtual desktop away from the
> on containing emacs and back, emacs does not render screen updates.
> This patch fixes the cause.
> Analysis for the bug tracker, copied from commit message:
>
> If no state flags are set in the _NET_WM_STATE property,
> the returned X property type will be "0". This situation
> occurs when "_NET_WM_STATE_HIDDEN" was the only property
> set for the emacs window, e.g. in enlightenment due to
> change of a virtual desktop.
> In the current code this causes copying of the iconified
> state in x_get_current_wm_state(), which causes emacs to
> stay hidden. For DMs such as Enlightenent or Gnome Shell
> that use only the hidden but not the iconified state
> this clashes with the intention of handling the
> _NET_WM_STATE property notification in
> handle_one_xevent(), which requires not_hidden &&
> FRAME_ICONIFIED_P (f) to actually activate the frame.

Po, could you take a look at this patch please.

Message #11 received at 63511 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Christian Schmidt <cs <at> aibiot.de>, 63511 <at> debbugs.gnu.org
Subject: Re: bug#63511: [Patch] Fix for hidden window bug
Date: Thu, 24 Aug 2023 08:12:02 +0800

Stefan Kangas <stefankangas <at> gmail.com> writes:

> Christian Schmidt <cs <at> aibiot.de> writes:
>
>> At least on enlightenment, when switching virtual desktop away from the
>> on containing emacs and back, emacs does not render screen updates.
>> This patch fixes the cause.
>> Analysis for the bug tracker, copied from commit message:
>>
>> If no state flags are set in the _NET_WM_STATE property,
>> the returned X property type will be "0". This situation
>> occurs when "_NET_WM_STATE_HIDDEN" was the only property
>> set for the emacs window, e.g. in enlightenment due to
>> change of a virtual desktop.

Does Enlightenment _remove_ the property, or merely set its type to
something other than ATOM?

> Po, could you take a look at this patch please.

That's a bug in Enlightenment, as the type of _NET_WM_STATE should
always be set to an array of atoms irrespective of its contents.

If the window manager outright removes the property, clients have no
means to ascertain if the window manager has relinquished control over
the window, or it is still iconified by some other means (such as the
traditional WM_STATE).

I would prefer a check against that other property when that is the
case, rather than overriding the results of the loop below.

Message #14 received at 63511 <at> debbugs.gnu.org (full text, mbox):

From: Christian Schmidt <cs <at> aibiot.de>
To: Po Lu <luangruo <at> yahoo.com>, Stefan Kangas <stefankangas <at> gmail.com>
Cc: 63511 <at> debbugs.gnu.org
Subject: Re: bug#63511: [Patch] Fix for hidden window bug
Date: Mon, 28 Aug 2023 09:56:06 +0200

On 8/24/23 02:12, Po Lu wrote:
> Stefan Kangas <stefankangas <at> gmail.com> writes:
> 
>> Christian Schmidt <cs <at> aibiot.de> writes:
>>
>>> At least on enlightenment, when switching virtual desktop away from the
>>> on containing emacs and back, emacs does not render screen updates.
>>> This patch fixes the cause.
>>> Analysis for the bug tracker, copied from commit message:
>>>
>>> If no state flags are set in the _NET_WM_STATE property,
>>> the returned X property type will be "0". This situation
>>> occurs when "_NET_WM_STATE_HIDDEN" was the only property
>>> set for the emacs window, e.g. in enlightenment due to
>>> change of a virtual desktop.
> 
> Does Enlightenment _remove_ the property, or merely set its type to
> something other than ATOM?

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

>> Po, could you take a look at this patch please.
> 
> That's a bug in Enlightenment, as the type of _NET_WM_STATE should
> always be set to an array of atoms irrespective of its contents.

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 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.

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.

The scenario in which this occurs is a switch of a virtual desktop in E. 
E will only hide affected windows, not iconify them, which seems 
correct. E uses compositing and updates even windows on other virtual 
desktops in the pager when (and if) they redraw while hidden.

> If the window manager outright removes the property, clients have no
> means to ascertain if the window manager has relinquished control over
> the window, or it is still iconified by some other means (such as the
> traditional WM_STATE).

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.

> I would prefer a check against that other property when that is the
> case, rather than overriding the results of the loop below.

In summary: Two scenarios currently can cause SET_FRAME_ICONIFIED (f, 
true): _NET_WM_STATE_HIDDEN and wm_state in Iconic_State. A removal of a 
final property _NET_WM_STATE_HIDDEN does not trigger SET_FRAME_ICONIFIED 
(f, false), because of what appears to me like a misinterpretation of an 
empty Atom list.

However, as long as any other property, e.g. sticky, would be set, 
removing _NET_WM_STATE_HIDDEN would behave like the patched version.

I would agree that the check could be reasonable, though I can't really 
imagine a situation in which iconified+hidden is set, yet only hidden 
would be removed. In fact, the implementation notes give iconified as 
the typical use case of hidden, so these would go hand in hand.

This patch only adds correct handling of an empty _NET_WM_STATE Atom 
list, and does not otherwise alter behavior as described above. The 
unconditional initialization of actual_size seems ok to me as the 
alternative would be to have it set twice, once in the else tree, and 
secondly in another new else tree. I'd say both from code size and 
runtime performance this should be the better option.

Best regards,
Christian

Message #17 received at 63511 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Christian Schmidt <cs <at> aibiot.de>
Cc: Stefan Kangas <stefankangas <at> gmail.com>, 63511 <at> debbugs.gnu.org
Subject: Re: bug#63511: [Patch] Fix for hidden window bug
Date: Tue, 29 Aug 2023 09:22:44 +0800

Christian Schmidt <cs <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.