Open Bug 1794266 Opened 2 years ago Updated 9 months ago

[Xwayland][nsRetrievalContextX11::WaitForClipboardData] After locking and unlocking the screen firefox will hang when opening a new tab with middleclick, or when the side bar is interacted with

Categories

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

Firefox 106
defect

Tracking

()

UNCONFIRMED

People

(Reporter: QuirinBrunner, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

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

Steps to reproduce:

Kde on Arch Linux->lock screen with Firefox open->unlock screen->middle click on link to open it in new tab->firefox hangs

I have tested this for both Firefox-developer-edition version 106.0b9 and Firefox version 105.0.3-1. It hung every time I tried it.

Actual results:

Firefox freezes for a few seconds before opening the website in a new tab and becomes unresponsive until it does. Other items can still be clicked and will be opened as soon as Firefox stops freezing.
After a few minutes Firefox usually works as expected again.

Expected results:

The tab should open just like it normally would and Firefox should not hang.

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

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

I have tested it with Xorg and Wayland now and it seems to only happen on Wayland.

Blocks: wayland
Priority: -- → P3
Summary: After locking and unlocking the screen firefox will hang when opening a new tab with middleclick, or when the side bar is interacted with → [Wayland] After locking and unlocking the screen firefox will hang when opening a new tab with middleclick, or when the side bar is interacted with

Does this problem still occur?

Flags: needinfo?(QuirinBrunner)

EndeavourOS (Linux 6.2.9-arch1-1), KDE Plasma 5.27, Wayland
Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/111.0

Can confirm the issue still occurs as described.

Additional recent reports from other users:
https://www.reddit.com/r/firefox/comments/10eqsxu/recent_update_broke_middleclicksevere_lag_when/
https://www.reddit.com/r/kde/comments/11bsgla/firefox_is_hangingfreezing_for_a_few_seconds_when/

Suggested workaround of setting accessibility.force_disabled to 1 did not fix the issue.

Flags: needinfo?(yamplum)
Attached file about:support

The issue does not occur on version 112 if run with MOZ_ENABLE_WAYLAND=1. The freeze also sometimes clears early when I switch focus to another window. Seems like some kind of XWayland issue?

Flags: needinfo?(yamplum)

(In reply to yamplum from comment #8)

Not sure if I did it right, but https://crash-stats.mozilla.org/report/index/b8c82613-40a3-4e2b-a6e5-4ce680230413

That looks correctly but I don't see any hang here - Firefox just waits to get system events.

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

(In reply to yamplum from comment #8)

Not sure if I did it right, but https://crash-stats.mozilla.org/report/index/b8c82613-40a3-4e2b-a6e5-4ce680230413

That looks correctly but I don't see any hang here - Firefox just waits to get system events.

I tried capturing another one during the freeze itself. I see clipboard mentioned in the backtrace, perhaps something to do with middle-click to paste? Will try to investigate further.

https://crash-stats.mozilla.org/report/index/60b416b6-c974-4621-8847-ed81a0230413

Confirmed, after setting middlemouse.paste to false in about:config the issue no longer occurs under XWayland.

(In reply to Martin Stránský [:stransky])
Can middlemouse.paste become disabled by default (bug 1747207) and general.autoScroll become enabled by default (bug 1747208) to get the same default settings as on MacOS and Windows?

bug 1515783
https://github.com/brave/brave-browser/issues/22864
https://bugs.kde.org/show_bug.cgi?id=441668
https://www.reddit.com/r/Ubuntu/comments/unviho/disabling_middle_click_paste/
https://www.reddit.com/r/linux_gaming/comments/w27h1o/linux_enable_middle_mouse_button_scrolling_on/

No longer blocks: wayland
Summary: [Wayland] After locking and unlocking the screen firefox will hang when opening a new tab with middleclick, or when the side bar is interacted with → [Xwayland] After locking and unlocking the screen firefox will hang when opening a new tab with middleclick, or when the side bar is interacted with
Blocks: gtkclipboard
Summary: [Xwayland] After locking and unlocking the screen firefox will hang when opening a new tab with middleclick, or when the side bar is interacted with → [Xwayland][nsRetrievalContextX11::WaitForClipboardData] After locking and unlocking the screen firefox will hang when opening a new tab with middleclick, or when the side bar is interacted with

Redirect a needinfo that is pending on an inactive user to the triage owner.
:stransky, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(QuirinBrunner) → needinfo?(stransky)
Flags: needinfo?(stransky)

This still happens to me sometimes after waking up from sleep on current Kubuntu 23.04 - Wayland with Firefox 118.0.2 Flatpak.
Setting middlemouse.paste to false seems to fix it.

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

Attachment

General

Creator:
Created:
Updated:
Size: