Page MenuHomePhabricator

WM_STATE not set to Iconic when window is iconified
Closed, ResolvedPublic

Description

On Enlightenment 0.24.2 and xorg 1.20.10, when a window is iconified to the IBox, its WM_STATE remains as "Normal" rather than "Iconic". This causes some applications to treat the window as still being visible, such as Chromium - where dragging a tab between windows can get dragged into an iconified window unexpectedly. Other window managers such as Gnome shell set the _NET_WM_STATE(ATOM) window property to _NET_WM_STATE_HIDDEN as well setting this state to "Iconic".

I've noticed other window managers set windows on other virtual desktops to the "Iconic" state also, which prevents Chromium from incorrectly placing dragged tabs into those unseen windows. This is also a problem in Enlightenment 0.24.2, where those windows on other desktops are left in a Normal state and can have tabs unexpectedly dragged into them even though they are not visible to the user.

dmccombs created this task.Apr 10 2021, 6:11 AM
dmccombs updated the task description. (Show Details)
dmccombs updated the task description. (Show Details)
dmccombs updated the task description. (Show Details)Apr 10 2021, 6:13 AM
dmccombs updated the task description. (Show Details)Apr 10 2021, 6:39 AM
devilhorns added a comment.EditedApr 10 2021, 10:18 PM

when a window is iconified to the IBox, its WM_STATE remains as "Normal" rather than "Iconic".

I complained about that one years ago ... nobody listened....

As Soon as it goes to IBOX, it should be an Icon....

devilhorns added a comment.EditedApr 10 2021, 10:19 PM

state min is state min .. hidden is hidden... ICONIC is iconic ;) ... yes, it can be done wl

Part of the problem becomes ... do we go by WL standards ? or X11 ?...

WL does not generally use WM_STATE as a proto....*shrug*... everyone expects it ... coming from an X11 world....They decided NOT to set Atoms on Hx....

I can see why they thought that .... It's easy to Abuse....

Anyway......

"On Enlightenment 0.24.2 and xorg 1.20.10, when a window is iconified to the IBox, its WM_STATE remains as "Normal" rather than "Iconic"."

Yes, this is partially because of what was done in Enlightenment the Window Manager.....

instead of being ICONic .... we are now? MINIMIZED ??? Wow ... ICOn is easy to type....

I miss eapps... lol

devilhorns added a comment.EditedApr 10 2021, 10:52 PM

Someone (I will say no names) changed what happens when you Iconify a window in E....

It is no longer iconified ... it is Minimized....YAWN

Guess we need to make a MINI-BOX then....

devilhorns triaged this task as Normal priority.Apr 11 2021, 12:46 AM

because apps will stop rendering when iconic ... thus the miniature thumbnails don't update... :)

What could apps be checking to determine if a window is iconic if this state is still set to normal to work around it?

IF you set it to iconic - they do things like stop rendering, thus why e stopped setting it to keep windows updating when minimized. the problem is that at least one app (firefox) totally broke assuming it will always be made iconic when you press the minimize button when it uses CSD... until then it worked fine as apps just never went iconic.

I've had some PRs to Chromium approved in the past, is there something I can check from Chromium to see if a window is minimized in Enlightenment? I could see if they'd accept it.

the issue i know of was with ffox, not chromium. i have, in got, re-enabled setting wm_state to iconic because of this. a bug was filed with ffox but nothing happened. assuming if you sent a request to the wm to iconify that you do get iconified is an assumption you can't make - ffox froze it's ui until it got the wm state change to iconic thus freezing everything. it assumed it would become iconic whenever it requested, rather than knowing a wm can choose not to honor that request if it does not want to.

now this chromium issue is something else. the problem is setting iconic has side effects - chromium stops rendering e.g. youtube video. we certainly do not want it to stop even if its on another desktop, because virtual desktops keep updating live. you can track the progress of a page load on another desktop just staring at your pager. if we set the state to iconic then it'll stop rendering. this happens to efl apps too. they suspend rendering.

now the problem is .. if we do set _NET_WM_STATE_HIDDEN .. chrome also stops rendering. there isn't a stats i know of where it keeps behaving as if were fully visible other than the normal state. not a standard one at any rate.

i could set netwm_state to hidden and keep wm_state normal as is .. so seeing that netwm and icccm properties disagree could be a hint to apps that they are in this situation - maybe keep rendering but at a lesser framerate or quality? e currently does not do this.

there are ways to know what desktop a window belongs to and which desktops are visible.

__E_WINDOW_ZONE(CARDINAL) = 1
__E_WINDOW_DESK(CARDINAL) = 1, 0

those properties tell you which zone (screen) the window belongs to and the desk property is x,y desktop the window belongs to. on root window e sets:

E_DESK_1(CARDINAL) = 0, 0
E_DESK_0(CARDINAL) = 0, 0

for example - E_DESK_1 is for zone 1 and E_DESK_0 is for zone 0 (and E_DESK_@ and so on for zone 2, 3, 4, etc.)

looking at root properties and your window properties can tell you if you are on a visible desktop. it'd be easier if e just set some property on your window for this and maybe if chrome chose to take netwm hidden as above AND icccm as normal == on another virtual desktop, so don't stop rendering, this might be easiest and do what is intended?

dmccombs added a comment.EditedThu, Dec 30, 2:15 PM

Just wanted to say that in Enlightenment 0.25.0, this change of setting _NET_WM_STATE_HIDDEN fixed the issue I was seeing in Chromium - when dragging tabs it no longer finds iconified windows unexpectedly. Success!