Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#69457 - [firefox 85.0] display crash at launch

Attached to Project: Arch Linux
Opened by Alexandre ZANNI (noraj) - Thursday, 28 January 2021, 09:58 GMT
Task Type Bug Report
Category Packages: Extra
Status Unconfirmed
Assigned To No-one
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 5
Private No



- Launching firefox in normal mode create a visual glitch where the firefox windows displays the content of the window behind instead of the actual content, and when you want to right click on the task manager and close firefox it will tell the firefox process is not responding
- launching in safe mode works
- it's tempting to think it's due to a plugin or a bad settings, but launching in normal mode with all plugin disables doesn't work and I changed nothing in about:config only ultra classic stuff like the download folder
- sometimes after killing the process or by launching in safe mode firefox suggest to make a "refresh" that will keep your data and plugins but will reset firefox settings, after the refresh firefox works for the current boot, you can close and relaunch the process, but at next boot it will start to crash again so I need to make a firefox "refresh" at each boot
- it started to happen with the 85.0 the 2021-01-26 so I hope it's due to the new version
- it happens wathever the kernel is (vanilla, zen, lts)

Additional info:
* package version(s) 85.0
Operating System: Arch Linux
KDE Plasma Version: 5.20.5
KDE Frameworks Version: 5.78.0
Qt Version: 5.15.2
Kernel Version: 5.4.92-1-lts
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-10510U CPU @ 1.80GHz
Memory: 15,3 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics

Steps to reproduce:
- just launch firefox (but maybe due to a specific environment so it may not be reproducible for everyone)
This task depends upon

2021-01-28: A task closure has been requested. Reason for request: cf comment
Comment by Alexandre ZANNI (noraj) - Thursday, 28 January 2021, 22:34 GMT
See it may be related to this plugin:

Which is weird because FF 85 release note says.

> Changes for add-on developers
> No changes.


So what changed between FF 84 & 85 that broke the browser? I'll request a closure since it's possibly due to the plugin.
Comment by Felix Silvestris (Catus) - Thursday, 28 January 2021, 22:40 GMT
I have the same problem (AMDGPU / Ryzen 3600 / Latest Linux-zen)
Using safe mode doesn't solve the problem for me. And i don't have firefox-extension-arch-search.
Trying without or with webrender same problem.
If i kill the window and relaunch, sometimes, like 1/40 ~ it work... very weird.
Comment by Rosie Sweet (Irradium) - Friday, 29 January 2021, 07:07 GMT
I've had the same issue, not using the aforementioned extension. I was able to get FF minimally working by clearing my profile and re-syncing, but after re-opening Firefox after a sync I encountered the same issue. It might be an about:config issue... I changed layout.frame_rate to 144, and the "2h2020" bookmark option to false.

Seems to be an issue running on both XWayland and Wayland (AMDGPU, RX 5500XT).

Comment by NicoHood (NicoHood) - Friday, 29 January 2021, 12:45 GMT
I have the same issue, firefox does not start anymore, even if safe mode.
Comment by Alexandre ZANNI (noraj) - Friday, 29 January 2021, 20:02 GMT
I don't have the issue when I disable the extension. But it may not be specific to this particular extension but of a feature used by it and so several extensions can make it crash.
Comment by Wretched Banana (wretchedbanana) - Saturday, 30 January 2021, 18:23 GMT
Indeed it's certain extensions. From what I have installed I can reproduce this with ublock origin, and reliably solve the issue by disabling that extension only.
Comment by Wretched Banana (wretchedbanana) - Saturday, 30 January 2021, 18:34 GMT
Btw. this should not be closed on the basis that add-ons are at fault. In the modern Firefox extension architecture add-ons do not (well, should not) have the capacity to interfere with the main browser process in this way. This is either a browser bug, or something related to it's core functionality e.g., display drivers, windowing system etc.

I see multiple hang/freeze/crash bugs submitted upstream under the Untriaged category, which may be related. If anyone has access to a problem machine please chime in or submit a bug there -- unfortunately I can't be online to actively track this until next week.
Comment by NicoHood (NicoHood) - Saturday, 30 January 2021, 20:48 GMT
As a workaround I am still able to start Firefox by opening a link from an email or chat messenger (firefox is my default browser).
Comment by loqs (loqs) - Saturday, 30 January 2021, 21:19 GMT
Can the issue be reproduced using firefox-bin updated to 85.0 to see if it is a packaging issue if so is firefox-nightly [2] also affected?
If it is an upstream issue there is also Mozregression [3] to locate the regression range.

Comment by Rosie Sweet (Irradium) - Saturday, 30 January 2021, 22:16 GMT
firefox-bin is fine, though that's currently on 84.0.2 at the moment
firefox-nightly is working fine also

Not sure whether those imply an upstream or packaging issue however
Comment by loqs (loqs) - Saturday, 30 January 2021, 22:41 GMT
Attached PKGBUILD for firefox-bin updated to 85.0.
   PKGBUILD (2.3 KiB)
Comment by Alexandre ZANNI (noraj) - Sunday, 31 January 2021, 16:09 GMT
The issue occurred on my Laptop, but my desktop using the exact same DE + FF version + same extensions doesn't have the issue. So it start wondering if it could be more tricky or hardware/driver related.
Comment by David Wong (TimelyPeach) - Monday, 01 February 2021, 16:25 GMT
Chiming in, in case this helps! This issue is also happening for me - system details below. Starting up using firefox -P works but it is frustrating doing this every time. I don't have the firefox-extension-arch-search package either so it's probably not related to this.

Firefox version 85.0-1
Operating System: Arch Linux
KDE Plasma Version: 5.20.5
KDE Frameworks Version: 5.78.0
Qt Version: 5.15.2
Kernel Version: 5.10.11-arch1-1
OS Type: 64-bit
Processors: 12 × AMD Ryzen 5 2600 Six-Core Processor
Memory: 15.6 GiB of RAM
Graphics Processor: GeForce RTX 2060/PCIe/SSE2

EDIT: Doing firefox -P and creating a completely new profile (rather than switching to another existing one) seems to be a lasting (touch wood) workaround.
Comment by Radoslav Nenchovski (rado84) - Tuesday, 02 February 2021, 10:43 GMT
This "Launching firefox in normal mode create a visual glitch where the firefox windows displays the content of the window behind instead of the actual content" is related to layers.acceleration.force-enabled (true). This option (about:config) must be set to false. The said option is broken for about 2 years starting with Firefox 63.
Comment by Natrio (natrio) - Tuesday, 02 February 2021, 12:30 GMT
"windows displays the content of the window behind instead of the actual content" actually means simply non-cleaned garbage in non-refreshed window, because the crashed process can't resresh it.
No, it isn't related to layers.acceleration.force-enabled for me.
Comment by David Wong (TimelyPeach) - Tuesday, 02 February 2021, 12:37 GMT
layers.acceleration.force-enabled is set to false for me too by default so must be another issue.
Comment by Wretched Banana (wretchedbanana) - Friday, 05 February 2021, 20:59 GMT
Here's the main bug ticket everything else's getting merged into:
Comment by loqs (loqs) - Saturday, 06 February 2021, 09:16 GMT
diff applying the patch from [1] which is referenced from [2] as a possible fix.

Comment by Wretched Banana (wretchedbanana) - Wednesday, 10 February 2021, 02:21 GMT
85.0.2 solves the issue as noted in the upstream bug entry.