GNOME Bugzilla – Bug 780485
OR windows input and output stacking might not agree
Last modified: 2018-01-25 10:36:01 UTC
Created attachment 348614 [details] main java class When using the SWT.ON_TOP bit that makes an SWT application or its dialogs Always on Top, the "Always on Top" dialogs can stop receiving all events. When this occurs, the application behind it that has focus will instead receive the events. Steps to repeat: 1. Start Firefox. Ensure it is not maximized but is instead taking up 2/3 of the screen. (screenshot 1) 2. Close Firefox. 3. Run MainDlg.java. 4. Click On Top 1 button. 5. Drag the new dialog 1 into the area where Firefox was. 6. Click On Top 2 button. 7. Drag the new dialog 2 outside of the area where Firefox was. (screenshot 2) 8. Launch Firefox. (screenshot 3) 9. Attempt to drag dialog 1. Click and/or double click on the various parts of dialog 1. Note that dialog 1 is not receiving events but the application behind it that has focus, Firefox, is receiving the events. 10. Drag dialog 2 around, keeping it away from Firefox. Note it is dragging correctly and receiving events. 11. Drag and drop dialog 2 over Firefox. Then try to drag it again, click, and double click on the dialog. Note that it now is no longer receiving events and Firefox is receiving the events. (screenshot 4) Test Environment used: - CentOS 7.2 - mutter-3.14.4-17.el7.x86_64 - xorg-x11-server 1.17.2-10.el7 - gtk2-2.24.28-8.el7.x86_64 - gtk3-3.14.13-16.el7.x86_64 - Eclipse 4.5.1 - Oracle Java 1.8.0_101 Also tested against: - CentOS 7.3 - mutter-3.14.4-31.el7.x86_64 - xorg-x11-server 1.17.2-22.el7 - Eclipse 4.6.1 Eclipse and SWT will default to using gtk3, you can use gtk2 by setting the environment variable SWT_GTK3=0. The issue occurs regardless of gtk2 vs gtk3. The issue does not occur when using Metacity or Muffin.
Created attachment 348615 [details] dialog that is always on top
Created attachment 348616 [details] step 1 in test steps
Created attachment 348617 [details] step 7 in test steps
Created attachment 348618 [details] step 8 in test steps
Created attachment 348619 [details] step 11 in test steps
Created attachment 348620 [details] end state showing Firefox receiving events through on top dialog
This may be related to bug 763246. https://bugzilla.gnome.org/show_bug.cgi?id=763246 It can be triggered with drag and drop as demonstrated in the test steps with dialog 2. But the on top dialogs don't receive any events, mouse or keyboard. Opening a new window appears to be a requirement. You can recover by closing the new window (e.g. Firefox) or restarting the application (e.g. MainDlg.java). I also repeated the problem with just a file browser instead of Firefox.
(In reply to Nate Jensen from comment #7) > This may be related to bug 763246. > https://bugzilla.gnome.org/show_bug.cgi?id=763246 I don't think so; that bug is about the Wayland - X11 drag-n-drop integration causing issues. This is not related to Wayland at all as far as I understand. > > It can be triggered with drag and drop as demonstrated in the test steps > with dialog 2. But the on top dialogs don't receive any events, mouse or > keyboard. > > Opening a new window appears to be a requirement. You can recover by > closing the new window (e.g. Firefox) or restarting the application (e.g. > MainDlg.java). I also repeated the problem with just a file browser instead > of Firefox. FWIW, this is still reproduces in 3.24.0.
One of my coworkers was able to recreate the problem in pure GTK, indicating it is not a problem specific to SWT. The problem occurs for any window that is a GTK_WINDOW_POPUP. I have attached the GTK code that recreates the problem. To see the problem, you must open a new window behind the on top window. My coworker took it a step further and recreated the problem using Xlib directly. Since we are not Xlib experts, we used the example code at http://www.paulgriffiths.net/program/c/hellox.php and then added the following 5 lines to the X Window to recreate the problem: XSetWindowAttributes xattributes; long xattributes_mask = 0; xattributes.override_redirect = True; xattributes_mask |= CWOverrideRedirect; XChangeWindowAttributes(display, win, xattributes_mask, &xattributes); It appears Mutter is not handling the override redirect flag well. In our testing, we have also found a way to recreate the problem regardless of the location of the new window. These new test steps affect Gnome Classic but not Gnome 3. A Gnome Classic way to recreate the problem is: 1. Open the on top window. 2. Open a new window anywhere on the desktop. 3. Minimize the new window. 4. The on top window no longer receives events. Furthermore, you cannot recover from this state in Gnome Classic without killing the process of the on top window.
Created attachment 351648 [details] GTK example to recreate problem
The problem here is a disconnect between the real X11 window stacking, which determines input event delivery, and the compositor level stacking that's visible to the user. Since the fix for bug 633620 landed, mutter puts override-redirect (OR) windows on a layer above all regular windows which is why your window shows up on top but from an input point of view it might actually be below other windows. Usually OR windows in X11 are used along with pointer and keyboard grabs so that the application owning them can't be stopped from getting input events. It seems that in your case you're not grabbing input so the behavior you see is expected. Can you elaborate on your application's use case and why do you use OR windows without input grabs?
The use case is the customer requires an on top notification dialog to be displayed to the user. The user must acknowledge the notifications by using the buttons on the dialog. The application is a Java application using SWT widgets. We don't have access to the lower level APIs to make different calls since we're using SWT. The SWT API hides the underlying widget implementation so that it can provide native widgets on multiple platforms. I contemplated opening an SWT ticket but since the SWT.ON_TOP behavior works with other window managers such as Metacity and Muffin, I'm not sure the SWT team will consider it an issue.
(In reply to Nate Jensen from comment #12) > The use case is the customer requires an on top notification dialog to be > displayed to the user. The user must acknowledge the notifications by using > the buttons on the dialog. If the user must ack your dialog you really should have an input grab. How else do you prevent users from ignoring the dialog and start using the system? > The application is a Java application using SWT > widgets. > > We don't have access to the lower level APIs to make different calls since > we're using SWT. The SWT API hides the underlying widget implementation so > that it can provide native widgets on multiple platforms. I contemplated > opening an SWT ticket but since the SWT.ON_TOP behavior works with other > window managers such as Metacity and Muffin, I'm not sure the SWT team will > consider it an issue. What's the correct behavior that you expect? If you don't take input grabs you might as well use a normal window instead of an OR window.
The customer is upgrading from RHEL 6 to RHEL 7. As part of that they will be using either Gnome Classic or Gnome 3. We noticed the issue and were able to narrow it down since Mutter was being used instead of Metacity. We created simplified test steps to recreate the problem. The customer is using a multi-headed display with three monitors. An example is a user has this notification dialog on top on one monitor, while they are working with another application on another monitor. They don't want the notification dialog to steal focus and input from the application they are currently using. They may drag the notification dialog around to wherever on the three monitors but it is supposed to always be on top and never steal focus. The notification dialog also does not have any dialog trim, so for example the users cannot minimize it. Unfortunately the on top notification dialog can now stop receiving events when/if the user goes to acknowledge the messages. I hope that helps explain the use case and how we got here. Thank you for taking a look at it.
(In reply to Nate Jensen from comment #14) > We noticed the issue and were > able to narrow it down since Mutter was being used instead of Metacity. We > created simplified test steps to recreate the problem. But the same issue exists with other window managers. Using your gtk+ example from comment #10, I can drag any other window over its window and it also stops receiving input. Your example and, I suppose, SWT, are using OR windows incorrectly. OR windows do *not* give you any stacking guarantees by themselves. From your explanation, I can only advise you to use regular windows for your dialogs and use the WM spec[1] to make them NET_WM_STATE_MODAL so that they stay above your main window. If you insist you can also use NET_WM_STATE_ABOVE so that they stay above all other regular windows. [1] https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472615568
> But the same issue exists with other window managers. Using your gtk+ example > from comment #10, I can drag any other window over its window and it also stops > receiving input. What window managers are you testing with? We have tested with Mutter, Metacity, Muffin, and Openbox. Out of those four, the issue is only occurring with Mutter.
(In reply to Nate Jensen from comment #16) > What window managers are you testing with? We have tested with Mutter, > Metacity, Muffin, and Openbox. Out of those four, the issue is only > occurring with Mutter. twm. Launching your gtk+ example and then launching an xterm and positioning it over the gtk+ example results in the example window being hidden.
> twm. Launching your gtk+ example and then launching an xterm and positioning it > over the gtk+ example results in the example window being hidden. I don't agree that twm is a valid use case given it is no longer supported and does not implement Extended Window Manager Hints (EWMH). I tested on twm and you're right, the on top behavior does not work, other windows will appear in front of it. That behavior is at least consistent in that the window displayed on top is getting the input. With mutter the window that is displayed on top is not the window that receives the input. I opened an SWT ticket to see what they think. https://bugs.eclipse.org/bugs/show_bug.cgi?id=516907
Created attachment 352164 [details] [review] stack-tracker: Keep override redirect windows on top Since commit 6b5cf2e, we keep override redirect windows on a layer above regular windows in the clutter actor scene graph. In the X server, and thus for input purposes, these windows might end up being stacked below regular windows though, e.g. because a new regular window is mapped after an OR window. Fix this disconnect by re-stacking OR windows on top when syncing the window stack with the compositor.
(In reply to Nate Jensen from comment #18) > I don't agree that twm is a valid use case given it is no longer supported > and does not implement Extended Window Manager Hints (EWMH). It doesn't matter that it doesn't support EWMH (the wm-spec) because we are talking about plain override redirect windows which is a concept of the core X11 protocol. > I tested on > twm and you're right, the on top behavior does not work, other windows will > appear in front of it. That behavior is at least consistent in that the > window displayed on top is getting the input. With mutter the window that > is displayed on top is not the window that receives the input. Yes, and that is something that I do consider a bug. The patch I attached fixes this and as a side effect ends up "fixing" your use case. > I opened an SWT ticket to see what they think. > https://bugs.eclipse.org/bugs/show_bug.cgi?id=516907 Thanks. Even if the patch I proposed lands and thus fixes your issue I still strongly recommend you (or SWT) to use regular windows and make use of the EWMH as I pointed in comment #15, because, again, there's no protocol guaranteeing that OR windows are stacked on top.
Review of attachment 352164 [details] [review]: The reasoning makes sense to me, and the code seems to do what the commit message says so I'd say this looks good to me. Marking as reviewed, in case anyone with more X11 window management expertise has a different opinion, but looks good to me.
Attachment 352164 [details] pushed as e3d5bc0 - stack-tracker: Keep override redirect windows on top
*** Bug 760506 has been marked as a duplicate of this bug. ***