Closed Bug 1714132 Opened 2 months ago Closed 15 days 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)

Firefox 91
defect

Tracking

()

RESOLVED MOVED

People

(Reporter: xarblu, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(4 files)

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.

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: 15 days ago
Resolution: --- → MOVED
Duplicate of this bug: 1715055
Duplicate of this bug: 1722074
You need to log in before you can comment on or make changes to this bug.