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

Status: RESOLVED DUPLICATE of bug 1423598

(Core :: Widget: Gtk, defect)

Description

[Val Packett]

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

Comment 1

[Martin Stránský [:stransky] (ni? me)]

Which system / DE / Wayland compositor do you run? And do you run wayland enabled builds or X11 builds?

Comment 2

[Val Packett]

Weston git master. Of course this only happens when running in Wayland native mode, with Xwayland (GDK_BACKEND=x11) clicks work fine.

Comment 3

[Martin Stránský [:stransky] (ni? me)]

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.

Comment 4

[Hiroshi Hatake [:cosmo0920]]

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.

Comment 5

[Hiroshi Hatake [:cosmo0920]]

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.

Comment 6

[Val Packett]

(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)

Comment 7

[Hiroshi Hatake [:cosmo0920]]

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

Comment 8

[Hiroshi Hatake [:cosmo0920]]

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

Comment 9

[Takuro Ashie [:ashie]]

Attachment: Bug 1451816 - [Wayland] Avoid closing popup window on button-press on Weston

Review commit: https://reviewboard.mozilla.org/r/250928/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/250928/

Comment 10

[Takuro Ashie [:ashie]]

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.

Comment 11

[Martin Stránský [:stransky] (ni? me)]

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

Comment 12

[Martin Stránský [:stransky] (ni? me)]

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

[Martin Stránský [:stransky] (ni? me)]

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.

Comment 14

[jon]

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.

Comment 15

[Val Packett]

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.

Comment 16

[Val Packett]

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)

Comment 17

[Takuro Ashie [:ashie]]

The bug is no longer reproduced on GTK+-3.24 (bug1423598, bug1532643).
On GTK+-3.22, it's still reproduced since a new API of GTK+ is required to enable above changes.

Comment 18

[Martin Stránský [:stransky] (ni? me)]

Good to know, Thanks! I don't think we have any fix for Gtk < 3.24. Closing as dupe of Bug 1423598 then.