Open Bug 1788247 Opened 7 months ago Updated 4 months ago

[KDE] Firefox deadlocks on right click in BitWarden popover - waiting for free wl_buffer

Categories

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

Firefox 104
defect

Tracking

()

UNCONFIRMED

People

(Reporter: mozilla.bxw46, Assigned: stransky, NeedInfo)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(3 files)

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

Steps to reproduce:

  1. Open BitWarden in a popover
  2. Go to the password generator
  3. Generate a password a few times
  4. Try and copy it a few times by selecting the text and right clicking

Actual results:

Firefox crashes (most of the time after the first or second right click; this isn't specific to the password generator, just in general right clicking or interacting with the bitwarden popover is dangerous)

Expected results:

The right click menu appears.

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
Attached file gdb-backtrace.log
Attached file lldb-backtrace.log

I'm still bumping into this with Firefox 105, after doing more testing it requires "MOZ_ENABLE_WAYLAND=1" to occur, and it affects any text box. For instance "User-Agent Switcher and Manager" can be used, just:

  1. Start Firefox with MOZ_ENABLE_WAYLAND=1
  2. Spam right click the "userAgent" string text field

I've attached a gdb and lldb all thread backtrace taken after the bug is triggered and the browser is frozen. Curiously gdb was unable to generate an all thread backtrace freezing in the process of doing so (hence the additional lldb log).

Is that a new crash or have you seen that before?
Thanks.

Flags: needinfo?(mozilla.bxw46)
Priority: -- → P3

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

Is that a new crash or have you seen that before?
Thanks.

So just to clarify, it doesn't actually close/"crash" and the reporter never triggers -- I suspect it's a deadlock or livelock of some sort that requires the user to SIGKILL Firefox.

That said, I've been seeing for a while, it's taken a while to figure out the exact circumstances. I first reported it with 104 (it's probably dating back into the Firefox 90s that I first observed it -- depending on what you're doing it can be extremely infrequent or extremely frequent), but it existed before then and seemingly continues to exist with 105+.

Flags: needinfo?(mozilla.bxw46)

Thanks. It was amplified by Bug 1645677 which exposes underlying issue with main/rendering thread race. I can reproduce it reliably now.

Marking Bug 1645677 as 'Regressed by' for tracking purpose. This bug is here since beginning but was partially hidden by SendResumeAsync() call which causes random behavior. With change to SendResume() we explicitly wait to render/main thread sync and we can hit the deadlock more reliably.

Regressed by: 1645677
See Also: → 1645677
Summary: Firefox crashes on right click in BitWarden popover → Firefox deadlocks on right click in BitWarden popover
Assignee: nobody → stransky
Priority: P3 → P2

It's interesting I can reproduce that on KDE only.

This is a bug in KDE compositor - it does not release attached wl_buffers so Mesa fails to get a new one and freezes.

Blocks: wayland-kde
Summary: Firefox deadlocks on right click in BitWarden popover → [KDE] Firefox deadlocks on right click in BitWarden popover
Attached file buffers.txt

Vlad, it looks like a bug in KDE compositor. Look for wl_surface@60 - we keep to attach buffers to it but they're not released. That comes from Mesa EGL code.

Flags: needinfo?(vlad.zahorodnii)

I added it to my todo list, I'll check it.

No longer blocks: wayland-popup
Summary: [KDE] Firefox deadlocks on right click in BitWarden popover → [KDE] Firefox deadlocks on right click in BitWarden popover - waiting for free wl_buffer
Duplicate of this bug: 1795819

Any progress? I think this is a very important issue.

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