(Fedora 30 4.14 xfce; this arrived in the last few months as a regression. Thunar 1.8.9) I've got a LUKS encrypted partition on my main drive; it's an padlocked icon on the main desktop. When I click on it the, 'Enter a passphrase to unlock the volume' dialog appears. However at that point *all* other windows on all desktops disappear. The windows aren't minimised - they're still shown on the window list without [] and still appear on the workspace switcher. They reappear if I use alt-tab to view each one. I'm not sure where the problem is; Thunar or the window manager.
I *think* the message actually comes from gvfsudisks2volume.c; https://github.com/GNOME/gvfs/blob/master/monitor/udisks2/gvfsudisks2volume.c#L1501 but not sure how that bubbles back up.
Dr. Gilbert and I have been rambling on IRC about this a bit. The passphrase window grabs input and (tries to grab) focus; I can change virtual desktops but cannot select a region outside the dialog box on the same virtual desktop. If I use gigolo to open the crypt device, all is well - the dialog it spawns is the same as the polkit-gnome dialog (which is NOT what pops up the passphrase entry window when opening the encrypted device from the desktop icon). If I unlock it from within Thunar itself, i.e. the sidebar, it spawns the polkit-gnome dialog and all is well. I've built and tested this with gvfs as far back as 1.36.0, which is what I was using with Xfce 4.12; with that setup then, unlocking a crypt device did NOT cause the problem we're seeing here. However, with Xfce-4.14 and gvfs-1.36.0, the problem *does* exist, which makes me think that gvfs isn't the culprit here. It seems that something changed with respect to how the new window is raised/lowered/managed/whatever in Xfce 4.14 - not sure if xfdesktop is somehow to blame, but it seems more likely to be xfwm4.
Hang on! This doesn't happen if I do it from Thunar's Devices list in a thunar window; only if I click on the desktop icon for the locked device. And if I click on the icon a 3rd time the windows all reappear. Note it doesn't happen if I click on a non-locked device icon; that opens fine.
Yep, from inside Thunar itself, the unlock operation doesn't seem to go through gvfs. Either way, this is related to xfwm4. After a bit of testing to narrow down where in 4.13.0-->4.14.0 this went sideways (between 4.13.1 and 4.13.2), I did a git bisect and found this: fa9517eae823e35d0c85276b2d0c31beede5022f is the first bad commit commit fa9517eae823e35d0c85276b2d0c31beede5022f Author: Olivier Fourdan <fourdan@xfce.org> Date: Fri Apr 19 23:16:40 2019 +0200 stacking: Raise all transients together Bug 15303 Xfwm4 would raise the transients of a given window along with the parent window, to keep the transients above their parents, but would not raise the parents along with the transient windows. Rework the stacking code to raise the deepest parent of a transient being raised so that all parents window of a transient get raised along with it. src/client.c | 8 +- src/stacking.c | 373 +++++++++++++++++++++++++++++-------------------------- src/transients.c | 68 ++++++---- 3 files changed, 241 insertions(+), 208 deletions(-)
Well found - the time sounds about right as well.
So the theory is that the passphrase dialog is transient to the destkop window and the desktop window gets raised, hiding all other windows? Can you get an xprop of that window?
xprop of the passphrase dialog: _NET_FRAME_EXTENTS(CARDINAL) = 4, 4, 15, 4 _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MOVE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_STICK WM_STATE(WM_STATE): window state: Normal icon window: 0x248d020 _NET_WM_DESKTOP(CARDINAL) = 4294967295 _NET_WM_STATE(ATOM) = _NET_WM_STATE_STICKY, _NET_WM_STATE_MODAL, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_FOCUSED WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. bitmap id # to use for icon: 0x14006ee bitmap id # of mask for icon: 0x14006f4 window id # of group leader: 0x1400001 _GTK_THEME_VARIANT(UTF8_STRING) = XdndAware(ATOM) = BITMAP _NET_WM_ICON(CARDINAL) = _NET_WM_OPAQUE_REGION(CARDINAL) = 0, 0, 520, 260 WM_TRANSIENT_FOR(WINDOW): window id # 0x1400028 _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 20973292, 20973293 _NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x14006eb WM_CLIENT_LEADER(WINDOW): window id # 0x1400001 _NET_WM_PID(CARDINAL) = 2468 WM_LOCALE_NAME(STRING) = "en_GB.utf8" WM_CLIENT_MACHINE(STRING) = "major.home.treblig.org" WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified location: 0, 0 program specified minimum size: 520 by 260 program specified maximum size: 520 by 260 program specified base size: 0 by 0 window gravity: NorthWest WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST WM_CLASS(STRING) = "xfdesktop", "Xfdesktop" WM_ICON_NAME(STRING) = _NET_WM_ICON_NAME(UTF8_STRING) = WM_NAME(STRING) = _NET_WM_NAME(UTF8_STRING) = xprop of the background window: _NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 0, 0 _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW, _NET_WM_ACTION_FULLSCREEN WM_STATE(WM_STATE): window state: Normal icon window: 0x24734a0 _NET_WM_DESKTOP(CARDINAL) = 4294967295 _NET_WM_STATE(ATOM) = _NET_WM_STATE_STICKY, _NET_WM_STATE_SKIP_PAGER, _NET_WM_STATE_SKIP_TASKBAR WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. window id # of group leader: 0x1400001 _GTK_THEME_VARIANT(UTF8_STRING) = XdndAware(ATOM) = BITMAP _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x0, 0x0, 0x0 _NET_WM_OPAQUE_REGION(CARDINAL) = 8, 0, 5744, 8, 0, 8, 5760, 2152 _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DESKTOP _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 20971562, 20971563 _NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x1400029 WM_CLIENT_LEADER(WINDOW): window id # 0x1400001 _NET_WM_PID(CARDINAL) = 2468 WM_LOCALE_NAME(STRING) = "en_GB.utf8" WM_CLIENT_MACHINE(STRING) = "major.home.treblig.org" WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified location: 0, 0 program specified minimum size: 5760 by 2160 program specified maximum size: 5760 by 2160 program specified base size: 0 by 0 window gravity: NorthWest WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST WM_CLASS(STRING) = "xfdesktop", "Xfdesktop" WM_ICON_NAME(STRING) = "Desktop" _NET_WM_ICON_NAME(UTF8_STRING) = "Desktop" WM_NAME(STRING) = "Desktop" _NET_WM_NAME(UTF8_STRING) = "Desktop"
Thanks! Right, both share the same client leader ID and `0x1400028` is most likely the window ID of the desktop window then. @rworkman, that doesn't sound right, why would that dialog be transient to the desktop window, previously it would have remained hidden underneath all other windows, along with the desktop...
Well, I'm not questioning your expertise with xfwm4 - I know better. :-) However, I've also never seen git bisect incorrectly identify a commit responsible for something. I've seen it fail to identify a commit at all, but never get one wrong (assuming correct input). I also know that xfwm4 right before that commit works fine wrt this bug, and afterward it does not. I have no idea *why* that is outside of it being something about that particular commit. All that said, I'll be *happy* to test any potential patches or even just "change $code to $someothercode and see what happens" - that's easy to do.
No, you misunderstood, I am not saying that bisection was wrong, it is correct, the behavior is related to that feature. Typically, it looks like the dialog is set transient to the desktop window, and when the dialog is raised, it takes the parent with it so xfdesktop ends up being raised as well. This is certainly a case that xfwm4 should handle, but that doesn't make it a less broken case in the first place. My fix for it in xfwm4 would be either to ignore that transient dependency altogether, or force the dialog to be on the same layer as its parent (which is what makes most sense). The latter means that the dialog would be shown underneath all other windows along with its parent (xfdesktop) unless that (broken) transient relationship gets fixed in the client (xfdesktop, thunar, gvs, dunno). tl;dr: I reckon we have two bugs that need fixing
I've poked around in xfdesktop source, and it seems like *maybe* it all starts with xfdesktop_volume_icon_menu_mount() in src/xfdesktop-volume-icon.c, but assuming that's the case (NOT A SAFE ASSUMPTION), I still don't see where the passphrase dialog itself is getting created (but somehow the dialog knows that it was spawned by xfdesktop). Best I can tell, the GIO stuff that's called ends up calling out to gnome-keyring-daemon for the passphrase, and the dialogs are consistent with that. Assuming that's the case, then I end up in the gnome-keyring source at gnome-keyring/daemon/dbus/gkd-secret-prompt.c and from there I'm dead in the water. I know you're busy, Olivier, but any chance of that latter fix (forcing the dialog to be on the same layer as its parent) showing up in git any time soon?
Olivier Fourdan referenced this bugreport in commit 3d6e0472e9a5ec310ff11294ae2c07dfd4a1f538 transients: Do no search for parent in lower layers https://git.xfce.org/xfce/xfwm4/commit?id=3d6e0472e9a5ec310ff11294ae2c07dfd4a1f538
Fix confirmed here; thanks Olivier!
Is a xfwm4 bugfix release planned or should I add just the patch for Fedora for now? Thanks!
Yep, I should do a release soon.
Olivier Fourdan referenced this bugreport in commit 6930e53f143ecb144870eb1f54d8fe5996c51258 transients: Do no search for parent in lower layers https://git.xfce.org/xfce/xfwm4/commit?id=6930e53f143ecb144870eb1f54d8fe5996c51258
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/345. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev