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

Status: UNCONFIRMED

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

Description

[Wyatt Childers]

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.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 2

[Wyatt Childers]

Attachment: gdb-backtrace.log

Comment 3

[Wyatt Childers]

Attachment: lldb-backtrace.log

Comment 4

[Wyatt Childers]

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).

Comment 5

[Martin Stránský [:stransky] (ni? me)]

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

Comment 6

[Wyatt Childers]

(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+.

Comment 7

[Martin Stránský [:stransky] (ni? me)]

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

Comment 8

[Martin Stránský [:stransky] (ni? me)]

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.

Comment 10

[Martin Stránský [:stransky] (ni? me)]

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

Comment 11

[Martin Stránský [:stransky] (ni? me)]

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

Comment 12

[Martin Stránský [:stransky] (ni? me)]

Attachment: 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.

Comment 13

[Vlad Zahorodnii [:zzag]]

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

Comment 15

[keydieyeah]

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