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

Steps to reproduce:

1. Try to right click on the back arrow of the address bar to show the context menu with previous URLs.
2. It doesn't work, so try again
3. Now try 1 to 4 times more and it works finally on the say 8th right mouse-click

Alternative:
Do the same, but not over the back address button, but over a page

Actual results:

Context menu doesn't open on the first right mouse-click, usually opens after at least 3 mouse clicks. Sometimes KDE makes the whole Firefox window grey as in not responding - that lasts for about 0.5 to 1 secs, sometimes it doesn't fade to grey at all but the issue still appears.

Sometimes the issue doesn't appear, but in maybe 80% it does.

Expected results:

Right-click context menu should need only 1 mouse-click.

Operating System: Kubuntu 21.04
KDE Plasma Version: 5.21.90
KDE Frameworks Version: 5.82.0
Qt Version: 5.15.2
Kernel Version: 5.11.0-18-lowlatency (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i5-8250U CPU @ 1.60GHz
Memory: 7,6 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 620

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

Tried to get profile: https://share.firefox.dev/2U4r72R

KDE/Wayland issue.

Please re-test with latest nightly.
Thanks.

I think it works in Nightly.

Nope, i think it still applies, though it is less noticeable because you might only need 2 or 3 clicks at max and it seems to happen rarer. Does the profiler from FF 89 give some info? Should i try to take a profile from Nightly? I mean, if the profile from 89 doesn't catch it when it was more serious profile from Nightly might not be good?

Please run on terminal with MOZ_LOG="Widget:5" env variable. Mouse button press/release event should be logged so please check if we're getting events when you press/release a button.
Thanks.

Also MOZ_LOG="WidgetPopup:5" log will tell you if the menu is opened or not (it may not be visible - that's another bug).

https://pastebin.com/cPQJpDQJ
Somewhere in the end i got this invisible context menu

Thanks. To get complete log (popus + widget) please run as:

MOZ_LOG="Widget:5 WidgetPopup:5"

Also can you try mutter compositor? We'll need to check if that's KDE bug only:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Testing_different_Wayland_compositor
Thanks.

https://pastebin.com/eKpjwBNT

I couldnt get it on gnome.
And here is another log, i saw a half rendered context menu when right clicking a link
https://pastebin.com/bfxNPpAp

Thanks for the logs - I see only one 'button 3' press event there - it means we're getting only one mouse event and we open the popup for it.

Can you run Firefox with:

WAYLAND_DEBUG=1 MOZ_LOG="Widget:5 WidgetPopup:5"

evn variables? You should find something like this in the log:

[2097022.439] wl_pointer@10.button(1113, 1001476, 273, 1)
[2097022.456] wl_pointer@10.frame()
[Parent 10365: Main Thread]: D/Widget Button 3 press on 7f8e4d124000

i.e. Wayland wl_pointer button event is transformed to Firefox Widget Button event call.

Oof, i can't reproduce now on Nightly. I think it would be the best to wait till Firefox 93 reaches stable and then see if issue is fixed. Meanwhile i'm attaching a log of the issue from Firefox 91, just to be here.

[1746877,422] wl_pointer@17.button(3757, 14476139, 273, 1)
[1746877,454] wl_pointer@17.frame()
[Parent 18493: Main Thread]: D/Widget Button 3 press on 7f00e4e6b800

i see this
https://pastebin.com/y0pE3wAK

I tried to try Firefox on Mutter but Mutter on launch says (without crashing):
Failed to set environment variable WAYLAND_DISPLAY for gnome-session: GDBus.Error:org.freedesktop.DBus.Error.Name

Blue window shows, then i launch Firefox and Firefox says (without crashing):
could not connect to wayland socket

Firefox runs but not inside this blue window and it runs on XWayland, also webgl creating failed.

(In reply to Lyubomir from comment #17)

Created attachment 9237638 [details]
When the button stuck on Firefox 91

Oof, i can't reproduce now on Nightly. I think it would be the best to wait till Firefox 93 reaches stable and then see if issue is fixed. Meanwhile i'm attaching a log of the issue from Firefox 91, just to be here.

Yes, I see wayland button events which are not translated to Gtk ones. I wonder why 93 works and 91 fails...

@Martin, i'm with Firefox 93 now on stable and i believe i can reproduce this issue. But there is something which i'm not sure about.
I kind of feel like these two bugs (this one and Bug 1718851) might be interrelated, but i'm not sure if back then i was experiencing such freezes apart from the back button and context menus.

Here is a performance profile: https://share.firefox.dev/2YxAIRF. The performance profile in the other bug is a different one.

I don't see anything wrong in the profile. It's possible that we're not getting wayland events in time.
WAYLAND_DEBUG=1 MOZ_LOG="Widget:5 WidgetPopup:5" log should tell you so.

I reproduced it now on Firefox 93.0 and Kubuntu 21.10/KDE Plasma 5.23. I'm attaching the log.

Oops, it's only WAYLAND_DEBUG log, will reproduce again with both this and Widget/WidgetPopup. Very sorry.

Here is a log with WAYLAND_DEBUG=1 MOZ_LOG="Widget:5 WidgetPopup:5"

Operating System: Kubuntu 21.10
KDE Plasma Version: 5.23.0
KDE Frameworks Version: 5.87.0
Qt Version: 5.15.2
Kernel Version: 5.13.0-19-lowlatency (64-bit)
Graphics Platform: Wayland

So i've noticed that when the menu does not open the chrome of the browser stops responding to mouse movement (cursor doesn't highlight what's under it). However, if i move it to/over the page the links <a> elements of the page are underlined promptly, cursor changes its type when over text. If i return the cursor back over the chrome of the browser (say the browser tabs) they are still not highlighted. I have to click over some tab once for it to detect the cursor and highlight. I then have to click again to change to the tab.

FWIW I've changed my system:
Operating System: Arch Linux
KDE Plasma Version: 5.23.4
KDE Frameworks Version: 5.88.0
Qt Version: 5.15.2
Kernel Version: 5.15.6-zen2-1-zen (64-bit)
Graphics Platform: Wayland
Graphics Processor: Mesa Intel® UHD Graphics 620

... Clicking inside the webpage also seems to cause the chrome to start responding to mouseover.

I have noticed that sometimes clicking in the area where the popup is supposed to show up goes back to the first page (which is usually the new tab page with the Firefox logo) - however this doesn't seem to happen always.

For example once it goes back and afterwards i manage to open the popup it shows this.

Since Plasma 5.24 i think this issue doesn't happen with Firefox 97.