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!
Maybe a problem with the “autosuggestions” as you say it doesnt happen when putting passwords in which should likely be protected from autosuggestions
Firefox is a huge software, so it might be hard to run on a raspi (As a former raspi 2 user, I’m not sure how performant is rpi4).
…and here’s a command recommendation you didn’t ask for
killall firefox
or
pkill firefox
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.
Maybe start Firefox from terminal using firefox *command, then you possibly get some error messages when it crashes.
Or manage to check some crash logs somehow
Obligatory question: does it happen on a fresh profile? You can run the profile manager with
-ProfileManager
.If it does, first thing I’d do is run a thorough memtest. Firefox is sort of infamous for being sensitive like this to memory issues.