[Wayland][Weston] Mouse clicks don't work in popover windows (menu, extensions, address suggestions)

NEW
Unassigned

Status

()

a year ago
3 months ago

People

(Reporter: greg, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

a year ago
User Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180405150934

Steps to reproduce:

On Wayland, click anything in the main menu, extensions' popover windows, the address suggestions thing, the certificate/permission popover, <select>s on web pages, etc.


Actual results:

Mouse clicks are not handled, they just close the popover without doing anything. Hover works though! (gray backgrounds etc.)


Expected results:

Clicks should work
(Reporter)

Updated

a year ago
Blocks: 635134
OS: Unspecified → All
Hardware: Unspecified → All
Which system / DE / Wayland compositor do you run? And do you run wayland enabled builds or X11 builds?
Flags: needinfo?(greg)
(Reporter)

Comment 2

a year ago
Weston git master. Of course this only happens when running in Wayland native mode, with Xwayland (GDK_BACKEND=x11) clicks work fine.
Flags: needinfo?(greg)
Okay. I'd say the Weston it not a good test environment here as it behaves differently than mutter for instance. I know the popup seat/focus handling is suboptimal for gtk+ and also affects Wayland but we manage to get it working somehow for mutter at least.
Summary: [Wayland] Mouse clicks don't work in popover windows (menu, extensions, address suggestions) → [Wayland][Weston] Mouse clicks don't work in popover windows (menu, extensions, address suggestions)
Component: Graphics → Widget: Gtk
We've also hit this issue Wayland enable build on Debian Stretch 9.4, Weston 1.12.0.
Set `ui.popup.disable_autohide` as true works fine in our environment.
The below is POC patch to fix this bug:

```
diff --git a/layout/xul/nsXULPopupManager.cpp b/layout/xul/nsXULPopupManager.cpp
index 36e0a1cbb47e..6c3ee4c7da86 100644
--- a/layout/xul/nsXULPopupManager.cpp
+++ b/layout/xul/nsXULPopupManager.cpp
@@ -1624,10 +1624,14 @@ nsXULPopupManager::FirePopupHidingEvent(nsIContent* aPopup,
             (!animate.EqualsLiteral("cancel") || aIsCancel)) {
           presShell->FlushPendingNotifications(FlushType::Layout);
 
+        // On Wayland with weston, getting frame again should be disabled.
+        // Otherwise, popup does not handle click events.
+#ifndef MOZ_WAYLAND
           // Get the frame again in case the flush caused it to go away
           popupFrame = do_QueryFrame(aPopup->GetPrimaryFrame());
           if (!popupFrame)
             return;
+#endif
 
           if (nsLayoutUtils::HasCurrentTransitions(popupFrame)) {
             RefPtr<TransitionEnder> ender = new TransitionEnder(aPopup, aDeselectMenu);
```

On Weston, duplicated to obtain popupFrame requests cause always giving up to handle mouse click events.
But, I have no idea how to fix with a right way, though.
(Reporter)

Comment 6

11 months ago
(In reply to Hiroshi Hatake [:cosmo0920] from comment #4)

Thanks for the ui.popup.disable_autohide tip! It does help.

The patch doesn't do anything though (probably because that code is not executed anyway: #ifndef MOZ_WIDGET_GTK)
This is a WIP patch for popup menus on weston.
Ashie and I confirmed that popup UI elements start to work, but we don't understand why this patch can work on weston for now.
(In reply to Hiroshi Hatake [:cosmo0920] from comment #7)
> Created attachment 8984785 [details] [diff] [review]
> WIP-gtk-type-hint-for-weston.patch
> 
> This is a WIP patch for popup menus on weston.
> Ashie and I confirmed that popup UI elements start to work, but we don't
> understand why this patch can work on weston for now.

Also, we specify `ui.popup.disable_autohide` as true.
Attachment #8984785 - Attachment is obsolete: true
I attached an ugly hack for this issue.

Probably the root cause is weston's focus handling (but I'm not sure about it yet).

On Weston, both focus-out & focus-in events are sent on button-press event.
They aren't occurred on other environments such as X11 or GNOME Shell on Wayland.

nsWindow::OnContainerFocusOut() which is called on button-press event will destroy
the popup menu so users can't click items on it because selecting item is handled
on button-release event, bot button-press event.
(In reply to Hiroshi Hatake [:cosmo0920] from comment #7)
> Created attachment 8984785 [details] [diff] [review]
> WIP-gtk-type-hint-for-weston.patch
> 
> This is a WIP patch for popup menus on weston.
> Ashie and I confirmed that popup UI elements start to work, but we don't
> understand why this patch can work on weston for now.

GDK_WINDOW_TYPE_HINT_* is used internally by Gtk to create different popup types.
see gdk_wayland_window_map() at gdkwindow-wayland.c for details.
I think this is related to Bug 1377084 and has the same root cause here. Unless we use gdk_seat_grab() the popup handling will be broken somehow. Or we can create the popup as xdg_shell surfaces which is also troublesome.

Comment 13

9 months ago
mozreview-review
Comment on attachment 8985306 [details]
Bug 1451816 - [Wayland] Avoid closing popup window on button-press on Weston

https://reviewboard.mozilla.org/r/250928/#review257458

::: widget/gtk/nsWindow.cpp:2893
(Diff revision 1)
>  void
>  nsWindow::OnContainerFocusOutEvent(GdkEventFocus *aEvent)
>  {
>      LOGFOCUS(("OnContainerFocusOutEvent [%p]\n", (void *)this));
>  
> +#ifdef MOZ_WAYLAND

That regress on gnome-shell (mutter) at least, I didn't try weston. nsWindow::OnContainerFocusOutEvent() still needs to be handled somehow. 

Try to open a popup (hamburger menu for instance) and then focus-out main firefox window (alt+tab or clik outside the browser). 

The popup should auto close but stays here. Perhaps we need to check mWindowType here and ignore focus-out only when mWindowType == eWindowType_popup.
Attachment #8985306 - Flags: review?(stransky)
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 14

4 months ago
Doing a bit of testing here, this behavior exists with the Flatpak Nightly build under Plasma 5.14's Wayland session, but not on Sway/wlroots git master.  Sway exhibits the slowness bug being tracked in another ticket.
(Reporter)

Comment 15

4 months ago
The patch from attachment 8985306 [details] mostly works well on Weston, thanks :)

One bug is that in webextensions, clicking buttons that open web pages (but not settings) doesn't close the popup. This is very easy to see with https://addons.mozilla.org/en-US/firefox/addon/yet-another-pinboard-extension/ — clicking "Pinboard" opens a new tab with pinboard.in but keeps the extension popover open, while clicking "Options" opens a new tab with about:addons and closes the popover.
(Reporter)

Comment 16

3 months ago
Still using attachment 8985306 [details], the problems I notice:

- webextension installation is impossible, the confirmation button does nothing. (Cancel doesn't do anything either.) The visual click feedback (dark shade on the button) *is* displayed (!!!) but the actual action (confirm/cancel) does not happen.
- in https://addons.mozilla.org/en-US/firefox/addon/yet-another-pinboard-extension/ the keyboard does not work in the "Pin current page" dialog (but does work in the search bar before pressing that button)
You need to log in before you can comment on or make changes to this bug.