GNOME Bugzilla – Bug 127360
Open drawers don't inherit stickyness of parent panel
Last modified: 2015-03-24 13:00:56 UTC
gnome-panel 2.4.1 Openbox 3.0 Steps to reproduce: 1) Enable at least 2 workspaces 2) Create a panel, confirm that it's sticky (exists on all workspaces) 3) Add a drawer to that panel, and open it. 4) Switch to another workspace Expected results: - Drawer is open regardless of which workspace is selected. Observed results: - Drawer is visible only on the workspace it was opened on. Clicking on the drawer on another workspace closes it (with no visible indication). - On other workspaces, although the drawer is not visible, the parent panel will remain active even if its auto-hide sitteng would dictiate that it should be hidden again.
It works here. This could be a openbox issue... Would you mind trying to see if you can reproduce the bug with metacity ?
I could not reproduce with metacity, however... Quoth the openbox's Ben Jansens ( https://bugzilla.icculus.org/show_bug.cgi?id=1076 ): I think Metacity just makes DOCK typed windows appear on all desktops. Even though the drawer's window is actually only requesting to be on one desktop. If the drawer wants to stay visible, it should set it's desktop to match the parent's, and Openbox will respect that. If the drawer was a transient of the panel, then Openbox would apply the same desktop automatically, but the window provides no association with the panel for Openbox to follow as such. I believe gnome-panel is at fault for this one. The EWMH allow's an app to specify which desktop to appear on for a reason.
Because this doesn't happen in 'stock' gnome, I'm moving the severity down, but it still is a bug, I guess.
Oddly, this appears to not happen on the first time a drawer is opened. That is to say, the first time it's opened, it works perfectly, but any subsequent opens fail to become sticky.
Still there in 2.9.x?
Jeremy: any news? I guess we could set _NET_WM_DESKTOP to 0xFFFFFFFF for the panels...
Confirmed present in 2.10.1
And 2.11.92.
And 2.12.2
Mass changing: milestone 2.12.x => milestone 2.14.x
And 2.14.1.
And 2.16.2. Bug is over 3 years old, and persisted through 7 stable gnome releases. Is there anything wrong with Ben's interpretation of this problem?
Unless something has changed here, changes in openbox prevent this bug from occuring. As I no longer can duplicate it, it should probably be closed.
Thanks for the update.