I have not been able to reliably find a way to trigger this issue but the latest update to www/firefox will randomly become non-responsive to user events for 30 or more seconds. I have yet to determine any pattern to this behavior the only clue I can give is that removing the custom mapping for my up arrow key (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244290) all apps locked up during these lockups.
(In reply to aryeh.friedman from comment #0)
oops before removing the custom mapping it locked apps up
Needs more affected users to track down the cause and/or upstream input.
- Can you reproduce after restarting with dom.ipc.processCount=1 or MOZ_FORCE_DISABLE_E10S=1 ?
- Does bug 245422 patch help? I plan to land it today, so it should be in packages around 2020-04-29.
(In reply to Jan Beich from comment #2)
I have zero experience with FF under the hood so I have no idea how to either those settings and/or where to get a (non-publicly available?) patch.
(In reply to aryeh.friedman from comment #3)
Never mind figured out how to do both... Will try both and if no problem after a day or so will put processCount back at 8
When testing make sure dom.ipc.processCount matches "Remote Processes" in about:support. A few releases ago Firefox introduced Performance menu in preferences, so one has to unset "Use recommended performance settings" (aka browser.preferences.defaultPerformanceSettings.enabled) to unlock dom.ipc.processCount.
(In reply to Jan Beich from comment #5)
Setting processCount to 1 works fine in both pre-pathched and patched but setting it to the default of 8 in both versions leads to the same random freezeups
(In reply to aryeh.friedman from comment #6)
I was wrong it still freezes on processCount=1 (post patch) but less frequently. I am switching back to 8 because it is way to slow to load complex pages on 1 (any recommendations for an intermediate setting?)