1843541 - Firefox window freezes occasionally on Linux [@ ibus_im_context_filter_keypress()]

Status: UNCONFIRMED

(Core :: Widget: Gtk, defect)

Description

[supersingularisogeny]

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

Steps to reproduce:

setup: Fedora Linux 64-bit, Nvidia GPU, Xfce desktop environment

I have had this issue since at least Firefox 112 (probably earlier too) and it is driving me crazy. The issue is not consistently reproducible and appears at random, usually after extended periods of use (usually multiple hours), but has sometimes occurred relatively quickly as well.

The issue seems to happen most often while I am doing some kind of input, usually keyboard input (e.g. I'm typing something into the address bar or an open web page). I've tried debugging this with gdb, but the thread seems to get stuck in random locations, although more often in ibus related code than not.

Things i have tried that have not fixed the issue:

• Beta/development builds
• Disabling hardware acceleration
• Disabling all plugins
• Testing with a completely clean profile

Actual results:

Browser freezes. The UI thread seems to be frozen, but other tasks keep going. If a YouTube video is playing for example, it keeps playing for about a minute before it buffers indefinitely. Keyboard and mouse have no impact on Firefox windows. All windows on the instance are frozen. Sometimes the windows still render correctly, but other times they do not.

I'm not sure if this is related, but at times the browser does not freeze, but every keyboard input instead starts being received 20-30 seconds late except for certain hotkeys, like Ctrl+T to open new tabs. This may be related if the bug is somewhere in input handling, which is entirely possible.

Expected results:

Browser should not freeze occasionally while I am using it.

Comment 1

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

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

Comment 2

[Darkspirit]

Thanks for the report!
Can this be fixed by setting nglayout.enable_drag_images to false on about:config and restarting FIrefox? (bug 1796960)

Comment 3

[supersingularisogeny]

(In reply to Darkspirit from comment #2)

Thanks for the report!
Can this be fixed by setting nglayout.enable_drag_images to false on about:config and restarting FIrefox? (bug 1796960)

I have encountered this bug as well. However, I think this is different; it doesn't happen due to dragging tabs and I cannot unfreeze the browser by trying to drag them again. I've also found that keyboard shortcuts still work if that bug happens, but they don't with the one I am referring to. I'll still try it to see if that fixes it, just in case.

Comment 4

[supersingularisogeny]

No, I still got a freeze even with that setting adjusted.

Comment 5

[supersingularisogeny]

I'll attach a thread dump from a frozen FF process that I got by attaching gdb and using "thread apply all bt"

Comment 6

[supersingularisogeny]

Attachment: 1843541 gdb thread dump.txt

Comment 7

[supersingularisogeny]

Okay, the main thread being stuck in key event code in libxul seems to be a consistent factor. My guess is that there is a race condition somewhere in the IME key event handler.

Comment 8

[supersingularisogeny]

I'm not sure if this is related, but at times the browser does not freeze, but every keyboard input instead starts being received 20-30 seconds late except for certain hotkeys, like Ctrl+T to open new tabs. This may be related if the bug is somewhere in input handling, which is entirely possible.

I know now that this "input lag" is definitely related. It has the exact same onset - I'm typing something into a search bar, on a form, etc. and all of a sudden it just happens. It seems to be random whether the browser freezes completely or still keeps running, but all keyboard inputs start being late.

I am all but certain that there is some kind of race condition somewhere in the key input handling code, since the effects are random. The chance must be tiny - something on the order of one every several thousand keystrokes for the bug to kick in. And it is very frustrating, since the browser has to be restarted in order for me to keep working.

Comment 9

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

It's freeze in ibus_im_context_filter_keypress() and DBus call. So it's a freeze in system library, not related to Firefox itself.

Comment 10

[supersingularisogeny]

Attachment: 1843541 ibus_im_context_button_press_event_cb.txt

Perhaps related too - I got a similar freeze now from mouse input (clicking). This freeze also happens in an ibus callback. Another note is that FIrefox is the only application where I've been suffering from this problem, but that could simply be because I don't do as much keyboard and mouse input to other applications, so it's possible I have just gotten lucky.