Closed Bug 1714132 Opened 3 years ago Closed 3 years ago

[KDE] Firefox Nightly has unresponsive Allow/Block buttons in permission popups when running with MOZ_ENABLE_WAYLAND=1

Categories

(Core :: Widget: Gtk, defect, P1)

Product:
Core
Component:
Widget: Gtk
Version:
Firefox 91
Type:
defect

Tracking

()

Status:
RESOLVED MOVED

People

(Reporter: xarblu, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(6 files)

With MOZ_LOG="WidgetPopup:5"
12.08 KB, text/plain
Details
With the MOZ_LOG="WidgetPopup:5"
12.08 KB, text/plain
Details
Clicking Allow/Block in the popup
266.67 KB, video/mp4
Details
Clicking Allow/Block in the popup (WebM Version)
176.07 KB, video/webm
Details
66
6.44 KB, text/plain
Details
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: nsWindow::Show state 0 frame Frame(7f6220f6d078) panel [Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: nsWindow::NativeShow hide [Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]:
6.44 KB, text/plain
Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

  1. Launch Firefox Nightly with the MOZ_ENABLE_WAYLAND=1 environment variable.
  2. Visit a website that asks for permission like microphone, camera etc. (eg. https://mozilla.github.io/webrtc-landing/gum_test.html)
  3. Try clicking Allow/Block Buttons in the popup.

Actual results:

The Allow/Block buttons don't do anything when clicked but still show the "clicked" animation. This also applies to other popups like the the ones from installing addons or even when interacting with extensions in the overflow menu (the extension window closes when anything in it gets clicked).

Expected results:

The buttons should properly perform their actions and extensions in the overflow menu shouldn't close on click even when running with the MOZ_ENABLE_WAYLAND=1 environment variable.

The Bugbug bot thinks this bug should belong to the 'Firefox::Site Permissions' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Site Permissions

I'm not sure where this belongs exactly but it's not specific to SitePermissions.

Component: Site Permissions → Widget: Gtk
Product: Firefox → Core

Can you please run Firefox with MOZ_LOG="WidgetPopup:5" env variable set on terminal, try to reproduce it and attach the output here?
Thanks.

Blocks: wayland-popup
Flags: needinfo?(xarblu)
Priority: -- → P1

This may be related to Bug 1712680. Does keyboard input work on the popup? Can you create a screencast [1] of it?
Thanks.
[1] https://help.gnome.org/users/gnome-help/stable/screen-shot-record.html

(In reply to Martin Stránský [:stransky] (ni? me) from comment #3)
> Can you please run Firefox with MOZ_LOG="WidgetPopup:5" env variable set on terminal, try to reproduce it and attach the output here?
> Thanks.
(In reply to Martin Stránský [:stransky] (ni? me) from comment #3)
> Can you please run Firefox with MOZ_LOG="WidgetPopup:5" env variable set on terminal, try to reproduce it and attach the output here?
> Thanks.

(In reply to Martin Stránský [:stransky] (ni? me) from comment #4)

This may be related to Bug 1712680. Does keyboard input work on the popup? Can you create a screencast [1] of it?
Thanks.
[1] https://help.gnome.org/users/gnome-help/stable/screen-shot-record.html

Keyboard input doesn't seem to do anything in those popups.

Flags: needinfo?(xarblu)

Recording of the popup buttons being clicked (Sorry for not having a mouse cursor. OBS didn't want to record it)

Reencoded WebM version of the video because the MP4 isn't playable for some reason

Summary: FIrefox Nightly has unresponsive Allow/Block buttons in permission popups when running with MOZ_ENABLE_WAYLAND=1 → Firefox Nightly has unresponsive Allow/Block buttons in permission popups when running with MOZ_ENABLE_WAYLAND=1

I'm unable to reproduce on Fedora 34/Gnome. Do I understand correctly that you use KDE? Which version is that?

Flags: needinfo?(xarblu)

Yes using KDE Plasma on the Live/Git version on my desktop (5.22.80 with Frameworks v5.83.0 according to info centre) and 5.21.5 with Frameworks v5.82.0 on my laptop. Both have this issue.

Flags: needinfo?(xarblu)

Please re-test with new nightly as it gets another popup fixes.
Thanks.

As it's KDE specific please report it at https://bugs.kde.org/.
Thanks.

Blocks: wayland-kde
No longer blocks: wayland-popup

As it's KDE specific please report it at https://bugs.kde.org/.

Popups work as expected in Firefox 89. kwin sends both button press and release events to Firefox. Please make sure that it's not a firefox regression.

(In reply to Vlad Zahorodnii [:zzag] from comment #14)

As it's KDE specific please report it at https://bugs.kde.org/.

Popups work as expected in Firefox 89. kwin sends both button press and release events to Firefox. Please make sure that it's not a firefox regression.

Please try latest nightly. We use two ways how the popups are opened - xdg_popup (auto-hide popups) and subsurface (pernament popups). I suspect this is an issue with subsurface popups.

Thanks.

I can reproduce on Fedora 34/KDE/latest nightly. Looks like we get the button events but does not process the clicks. Will look at it.

Summary: Firefox Nightly has unresponsive Allow/Block buttons in permission popups when running with MOZ_ENABLE_WAYLAND=1 → [KDE] Firefox Nightly has unresponsive Allow/Block buttons in permission popups when running with MOZ_ENABLE_WAYLAND=1

I've also tested it with Nightly. KWin still sends press and release events to firefox. For what it's worth, I can also reproduce this issue while running nightly with weston.

Wayland debug when running Firefox with kwin

[1957703.590] wl_pointer@22.button(431, 8148618, 272, 1)
[1957703.658] wl_pointer@22.frame()
[1957705.012]  -> wl_surface@49.frame(new id wl_callback@98)
[1957705.054]  -> wl_surface@49.commit()
[1957711.530] wl_display@1.delete_id(98)
[1957711.575] wl_callback@98.done(8145202)
[1957711.600]  -> wl_surface@49.frame(new id wl_callback@98)
[1957711.626]  -> wl_surface@49.commit()
[1957711.996]  -> wl_surface@56.damage_buffer(0, 0, 2147483647, 2147483647)
[1957712.054]  -> wl_surface@56.frame(new id wl_callback@94)
[1957712.080]  -> wl_surface@56.attach(wl_buffer@91, 0, 0)
[1957712.120]  -> wl_surface@56.commit()
[1957712.269]  -> wl_display@1.sync(new id wl_callback@89)
[1957712.551] wl_display@1.delete_id(89)
[1957712.578] wl_callback@89.done(431)
[1957727.211] wl_buffer@87.release()
[1957728.835] wl_display@1.delete_id(98)
[1957728.874] wl_display@1.delete_id(94)
[1957728.888] wl_callback@98.done(8148636)
[1957728.906] wl_callback@94.done(8148636)
[1963735.673] wl_pointer@22.button(432, 8154643, 272, 0)
[1963735.742] wl_pointer@22.frame()
[1963736.216]  -> wl_surface@49.frame(new id wl_callback@94)
[1963736.253]  -> wl_surface@49.commit()
[1963738.667] wl_display@1.delete_id(94)
[1963738.710] wl_callback@94.done(8148719)
[1963738.735]  -> wl_surface@49.frame(new id wl_callback@94)
[1963738.764]  -> wl_surface@49.commit()
[1963744.298]  -> wl_surface@56.damage_buffer(0, 0, 2147483647, 2147483647)
[1963744.368]  -> wl_surface@56.frame(new id wl_callback@98)
[1963744.390]  -> wl_surface@56.attach(wl_buffer@87, 0, 0)
[1963744.424]  -> wl_surface@56.commit()
[1963744.567]  -> wl_display@1.sync(new id wl_callback@89)
[1963744.888] wl_display@1.delete_id(89)
[1963744.923] wl_callback@89.done(432)
[1963760.909] wl_buffer@91.release()
[1963761.906] wl_display@1.delete_id(94)
[1963761.913] wl_display@1.delete_id(98)
[1963761.916] wl_callback@94.done(8154669)
[1963761.920] wl_callback@98.done(8154669)

It's blocked here:
https://searchfox.org/mozilla-central/rev/308ea44d0d60b391b031ccee695920bd543f7d2f/toolkit/modules/PopupNotifications.jsm#1878

There's a different focus handling on KWin which confuses Firefox widget code.

Also this happens for popups created as wl_subsurfaces, xdg_popups are ok.

There's a different focus handling on KWin which confuses Firefox widget code.

If a pointer button is pressed in a sub-surface, kwin will also try to move the keyboard focus to that sub-surface. Could that be the culprit?

If a pointer button is pressed in a sub-surface, kwin will also try to move the keyboard focus to that sub-surface

I think that we could make kwin stop doing that, but on the other hand, it's strange that Firefox makes assumptions about what surface has keyboard focus when it receives a button press event.

(In reply to Vlad Zahorodnii [:zzag] from comment #21)

There's a different focus handling on KWin which confuses Firefox widget code.

If a pointer button is pressed in a sub-surface, kwin will also try to move the keyboard focus to that sub-surface. Could that be the culprit?

Yes, seems to. The toplevel window it also wl_subsurface and and the popup is a child of it (it's a permanent popup created with "utility/pannel" hint).

I think that we could make kwin stop doing that, but on the other hand, it's strange that Firefox makes assumptions about what surface has keyboard focus when it receives a button press event.

I don't quite understand why the check is here. It may be a part of some security hardening to make sure the mouse click goes to the visible/active window as it's about allow/disable web page permissions.

https://invent.kde.org/plasma/kwayland-server/-/merge_requests/253 should help a little bit, it's not the "fix" per se though.

Martin, !253 was merged, it will be shipped with 5.22.3.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → MOVED

Have similar problem:
firefox cnt draw popup with allow/deny buttons for devices or share screan more than one time per session (after restart it draws once and then don't)
Log on error with MOZ_LOG="WidgetPopup:5"

[Parent 5706: Main Thread]: D/WidgetPopup [7f61fa499800]:   mBounds: x:0 y:0 w:0 h:0
[Parent 5706: Main Thread]: D/WidgetPopup [7f61fa499800]: nsWindow::Create() Popup
[Parent 5706: Main Thread]: D/WidgetPopup [7f61fa499800]:     set parent window [7f623458a000] browser
[Parent 5706: Main Thread]: D/WidgetPopup [7f61fa499800]: nsWindow type 3
[Parent 5706: Main Thread]: D/WidgetPopup [7f61fa499800]: 	mShell 7f61fc542660 mContainer 7f620320fa10 mGdkWindow 0 XID 0x0
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: nsWindow::SetWindowMouseTransparent(1)
[Parent 5706: Main Thread]: D/WidgetPopup [7f61fa499800]: nsWindow::SetWindowMouseTransparent(1)
[Parent 5706: Main Thread]: D/WidgetPopup [7f61fa499800]: nsWindow::GetCompositorWidgetInitData
[Parent 5706: Main Thread]: D/WidgetPopup GtkCompositorWidget::GtkCompositorWidget() [7f61fa499800] mXWindow 0 mIsRenderingSuspended 1
[Parent 5706: Main Thread]: D/WidgetPopup [7f61fa499800]: nsWindow::SetCompositorWidgetDelegate 7f61f97624a0
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: nsWindow::Move to 321 74
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]:   bounds 74 74
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: nsWindow::NativeMoveResize move 1 resize 0 to 321,74 -> 466 x 209
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: nsWindow::NativeMoveResizeWaylandPopup 321,74 -> 466 x 209
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: nsWindow::WaylandPopupSetDirectPosition 321,74 -> 466 x 209
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]:   set position [321, 74]
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]:   set size [466, 209]
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: nsWindow::Show state 1 frame Frame(7f6220f6d078) panel
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: nsWindow::SetHasMappedToplevel() state 0
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: nsWindow::NativeShow show
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: nsWindow::ShowWaylandWindow: [7f6218618400]
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]:   popup is not tracked in popup hierarchy, show it now
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: nsWindow::OnMap
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: nsWindow::ConfigureGdkWindow() [7f6218618400]
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: nsWindow::SetWindowMouseTransparent(0)
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: nsWindow::EnableRenderingToWindow()
[Parent 5706: Main Thread]: D/WidgetPopup GtkCompositorWidget::EnableRendering() [7f6218618400]
[Parent 5706: Main Thread]: D/WidgetPopup   quit, mIsRenderingSuspended = false
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]:   finished, new GdkWindow 7f621bcc6900 XID 0x0
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: nsWindow::OnWindowStateEvent for 7f621bc98060 changed 0x1 new_window_state 0x80
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: 	early return because no interesting bits changed
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: nsWindow::OnWindowStateEvent for 7f6219edabd0 changed 0x1 new_window_state 0x80
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: nsWindow::SetHasMappedToplevel() state 1
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: 	quick return because IS_MOZ_CONTAINER(aWidget) is true
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: nsWindow::SetWindowMouseTransparent(1)
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: moz_container_wayland initial create ResumeCompositorHiddenWindow()
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: nsWindow::ResumeCompositorHiddenWindow
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]:   resume
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: received expose event 7f621bcc6900 0x0 (rects follow):
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: nsWindow::SetWindowMouseTransparent(0)
[Parent 5706: Main Thread]: D/WidgetPopup [7f61fa499800]: nsWindow::SetWindowMouseTransparent(0)
[Parent 5706: Main Thread]: D/WidgetPopup [7f6218618400]: received expose event 7f621bcc6900 0x0 (rects follow):
Attached file 66 — 
Have similar problem:
firefox can't draw allow/deny popup for devices or screen share more than once for start (after restarting firefox it draws once and than need to restart one more...). but it works on alt+a pess.
Using Linux my-hostname 5.16.5-arch1-1 #1 SMP PREEMPT Tue, 01 Feb 2022 21:42:50 +0000 x86_64 GNU/Linux
with wayland 1.20.0-1
firefox Mozilla Firefox 96.0.3 20220127150057 20220127150057

Log with MOZ_LOG="WidgetPopup:5"
```

```
Have similar problem:
firefox can't draw allow/deny popup for devices or screen share more than once for start (after restarting firefox it draws once and than need to restart one more...). but it works on alt+a pess.
Using Linux my-hostname 5.16.5-arch1-1 #1 SMP PREEMPT Tue, 01 Feb 2022 21:42:50 +0000 x86_64 GNU/Linux
with wayland 1.20.0-1
firefox Mozilla Firefox 96.0.3 20220127150057 20220127150057

Log with MOZ_LOG="WidgetPopup:5"
```

```
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: