encrypted passphrase: all windows disappear

Dr. David Alan Gilbert said:

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.

Robby Workman said:

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.

Dr. David Alan Gilbert said:

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.

Robby Workman said:

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: fa9517ea is the first bad commit commit fa9517ea Author: Olivier Fourdan fourdan@xfce.org Date: Fri Apr 19 23:16:40 2019 +0200
  stacking: Raise all transients together
  
  [Bug 15303](https://bugzilla.xfce.org/show_bug.cgi?id=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(-)

Dr. David Alan Gilbert said:

Well found - the time sounds about right as well.

Olivier Fourdan @olivier said:

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?

Dr. David Alan Gilbert said:

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"

Olivier Fourdan @olivier said:

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

Robby Workman said:

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.

Olivier Fourdan @olivier said:

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

Robby Workman said:

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?

GitBot @GitBot said:

Olivier Fourdan referenced this bugreport in commit 3d6e0472

transients: Do no search for parent in lower layers

https://git.xfce.org/xfce/xfwm4/commit?id=3d6e0472e9a5ec310ff11294ae2c07dfd4a1f538

Robby Workman said:

Fix confirmed here; thanks Olivier!

Mukundan Ragavan said:

Is a xfwm4 bugfix release planned or should I add just the patch for Fedora for now? Thanks!

Olivier Fourdan @olivier said:

Yep, I should do a release soon.

GitBot @GitBot said:

Olivier Fourdan referenced this bugreport in commit 6930e53f

transients: Do no search for parent in lower layers

https://git.xfce.org/xfce/xfwm4/commit?id=6930e53f143ecb144870eb1f54d8fe5996c51258

As far as I'm concerned, this one is fixed - all seems well in latest xfwm4 release.

closed

encrypted passphrase: all windows disappear

Submitted by Dr. David Alan Gilbert

Description

Designs

Child items 0

Activity

encrypted passphrase: *all* windows disappear

Submitted by Dr. David Alan Gilbert

Description

Activity

encrypted passphrase: all windows disappear