This is a weird one.

I’m running Arch Linux ARM on a Raspberry Pi 4 with Sway if any of that matters. (I’ve also got fcitx enabled if that helps any.)

The issue I’m running into is that randomly Firefox will freeze while I’m typing. Like, while I’ve got the address bar or some text area in the page focused and I’m typing something into it. This frequently happens multiple times a day even with the coping strategy I use. (See below.)

It never freezes that I’ve noticed when I’m doing something other than typing into a text input or textbox or address bar. (I don’t recall ever seeing it freeze while I was typing into a password input, but I wouldn’t say that’s reason to think the issue is limited to not password boxes.)

It will usually freeze in the middle of a word somewhere. I type pretty fast. But it’ll freeze for instance 3 letters into a 7 letter word which is the third word I’ve typed into the box or some such. (Or sometimes it’ll freeze on the first letter. Or sometimes it’ll freeze two paragraphs in.)

When it freezes, I usually open a shell and ps aux | grep firefox to get the PID of the parent Firefox process and then kill $pid to kill Firefox. I don’t usually have to use -9 or anything. But just closing the window (with a super+shift+q) doesn’t do the trick.

Mostly how I deal with this is to vi /tmp/t, type a post, and then wl-copy < /tmp/t so I can paste the post into Lemmy or whatever. When typing a url, I usually just risk a freeze since it usually doesn’t take a lot of keystrokes to load the url I’m going for. (“lemmy.wo”, and then enter to accept the type-ahead suggestion, for instance.) I think basically every keystroke has a small-ish chance of causing a freeze, so something that only takes 10 keystrokes is low-enough risk to go for it. But a post like what I’m posting here would be almost guaranteed to freeze before I finished composing it.

I’m posting here in the Firefox community because I haven’t seen this happen with any application other than Firefox. (Though to be fair, I rarely use any graphical applications on this Raspberry Pi other than Firefox, st, and OpenSCAD on this Raspberry Pi 4. I used to use Cura occasionally on this machine occasionally as well. Chromium is way too resource hungry to try to use as a daily driver on a Raspberry Pi 4. I’m not sure I even have it installed right now.) I suppose this could be more of a GTK issue or Sway issue than a Firefox issue, but again it seems like it only happens with Firefox.

And I realize this is a weird enough issue that it might be pretty difficult to diagnose.

I’ve tried running Firefox from a terminal emulator and reproducing the issue to see if there’s any outut to STDOUT/STDERR when it reproduces the issue, but ther’es no useful output. I thought to try strace-ing Firefox, but strac-ing Firefox gives a veritable Niagara Falls of output when nothing’s happening, so it seems pretty untenable to try to comb through that to get anything useful.

Any ideas a) what the issue might possibly be or b) how I might go about trying to get a diagnosis? This has been an issue on this particular machine (and only this particular machine, though I haven’t tried Firefox on other Raspberry Pis) for probably over a year now. I’ve been alternately trying to debug it and just ignoring it. I figured maybe it’s finally time to see if anyone else has any ideas.

Thanks in advance!

    • @TootSweetOP
      link
      English
      21 year ago

      I don’t think it’s just the power of the Raspberry Pi I’m using. The 4 is a lot more powerful than the 2. I do avoid really resource-heavy websites (though I see that as a feature, not a bug. Lol.)

      But if it was just that there wasn’t sufficient power to run Firefox, you’d probably expect Firefox to either crash outright (with an OOM or something) or unfreeze after a bit. But I haven’t seen either of those happen. Maybe I’ll leave it “frozen” overnight some time just to make sure it doesn’t recover eventually on its own.

      And when it’s not frozen, it’s pretty responsive. It doesn’t grind to a halt over time. One second it’s responsive, the next it’s frozen.

      And thanks for that killall command. That’ll at least make recovering quicker.