GNOME Bugzilla – Bug 782786
Selecting shutdown/logout of Gnome session, all QT windows are closed
Last modified: 2017-05-22 19:44:31 UTC
Selecting Logout from Gnome Shell causes a Logout dialog to appear. *When this dialog is rendered,* many Qt-based application windows will disappear immediately. If the user then cancels out of the dialog, those applications are still gone even though no actual action to log out has been taken. Inspecting the running processes shows that some may still be running, so it's possible they aren't killed immediately, just unmapped by X. The Shutdown/Restart dialog has the same problem behavior. Other Gnome Shell modal popups (e.g. the command line available from Alt+F2) do not. Expected behavior: User can cancel out of a Logout or Shutdown dialog without degrading the state of currently running applications; applications should only be killed when Logout or Shutdown operation is confirmed. Where are you experiencing the behavior? What environment? Red Hat 7 (7.2 and 7.3 tested) with custom applications written in Qt 4.8.5. (Some of these are launched in /etc/xdg/autostart to provide domain-specific menus and controls on the desktop.) Can be replicated using only stock software from the RHEL7.2 Server DVD. For example: 1. Install RHEL7.2 Server using the "Server with GUI" preset. 2. Install the qt-x11 and qt-devel packages from the DVD. 3. Launch Qt Designer (designer-qt4 from the command line). 4. Select Logout or Shutdown from the Gnome top-right menu. (Alternative: invoke gnome-session-quit from the terminal.) 5. Designer window will disappear immediately. 6. Cancel out of the dialog. 7. Note that the Designer window is still missing. Same behavior occurs in both Gnome Classic sessions and the "modern-style" Gnome sessions. When does the behavior occur? Frequently? Repeatedly? At certain times? Consistently reproducible for certain specific application; seems to affect some Qt-based applications but not others. Consistently (100%) reproducible with Qt Designer. For details on what is happening see, https://access.redhat.com/solutions/2855451 The main issue is that Gnome decides to have all windows save themselves as soon as the user requests the confirmation dialog to shutdown. Instead, the saveyourself signal should not be sent until the user actually confirms they wish to shutdown/logout. Clearly, there is also a bug in Qt, that shouldn't close itself when asked to saveitself and there are coding workarounds you can use in Qt to prevent the behavior when you have access to the source.
Unfortunately, I don't think there's anything we can do on the gnome-session side here. As per the protocol, we ask the applications, "Please save your state, and let us know if you need user interaction", and the Qt applications are responding by dying right away. If we didn't ask the applications to save their state, and let us know if they need user interaction, then we wouldn't be able to present a list of applications that need user interaction to the user. We wouldn't be able to show the logout dialog as currently designed. So I don't see any way to fix this aside from fixing the applications that are dying when being asked to save to instead save when asked to save, and die when asked to die. I don't think there's anything we can do on the gnome-session side, unfortunately.
The suggestion we have made is to change the flow slightly. Pop up the Log out Confirmation Dialog User Presses No = > Do Nothing User Presses Yes => Send save yourself. Inform the user of applications that are preventing logout that need saving. Once complete, log out. This would mimic the log out flow of other operating systems like Windows, with the exception Windows doesn't have the confirmation dialog. This would then allow applications like Qt that don't handle the save yourself signal properly to not be affected. Long term solution, Qt should also be patched. But Redhat generally claims ownership of Gnome and more willing to change that SW verse Qt SW. I don't really care where it is fixed, but just don't want to change 100s of Qt applications to work around this issue that is not present in the other window managers.
Upstream GNOME is not likely to change the logout process to require the user to confirm twice after they explicitly picked log out from the menu. That would mean the user has to tell the computer three times that he/she really wants to log out (once to initiate log out, once to get past the newly introduced dialog, and third time to get passed the dialog presented after SaveYourself). And it wouldn't actually solve the problem, right? The user could still cancel logout after SaveYourself, I mean. To be clear, as I understand it, this isn't just a problem with GNOME. What happens, in KDE, if 1) a user has KDevelop open, and Kate with an unsaved document. 2) user clicks log out 3) user decides to cancel logout from Kate instead of save changes As I understand it, KDevelop will have exited prematurely in this case. So, assuming I'm understanding the situation correctly, this is broken in KDE, too. Which makes sense, because my understanding of the situation is the bug is in Qt/the applications. It's possible Red Hat may be able to come up with some workaround in Qt4 for RHEL, but that should be tracked in Customer Portal and Red Hat bugzilla (which I think you've already done, thanks!). I appreciate your diligence on this issue, and I hope Red Hat is able to come to a satisfactory resolution. I don't think there's much we can do from the upstream GNOME perspective, though.
I honestly didn't try it on KDE, that is just what the Redhat people said that it worked there. Sounds like you probably have more information then they did. I agree, having three "are you sure's?" is definitely too many. I would suggest if a change was made, to have it just work like Windows, and abandon the first popup and just have the initiation of the button send the saveyourself signal . Isn't the user already presented with three confirmations as is 1) Initiate log out 2) Dialog for SaveYourself 3) Confirmation Dialog We would just be flipping #2 and #3. Thanks for your feedback. I'm glad as this is now in the bug tracker just so people can hopefully find it and figure out what the issue is. We wasted 100's of hours tracking this down and have simply modified Gnome javascript to call our custom confirmation dialog that does it in the order that it used to in RHEL6 so our Qt applications do not need modification. It's hacky, but works for the short term until Qt fixes the bug (which I think they did somewhere in Qt5). Thanks for all the help. Cheers.