search

void-linux / void-packages

The Void source packages collection
https://voidlinux.org
Other
2.5k stars 2.11k forks source link

Firefox 129.0.2 (musl) freezing while loading about:support page without working Pipewire daemon #51726

Open flushedface opened 1 month ago

flushedface commented 1 month ago

Is this a new report?

Yes

System Info

Void 6.6.43_1 x86_64-musl GenuineIntel notuptodate hold rrnFFF

Package(s) Affected

firefox-129.0_1

Does a report exist for this bug with the project's home (upstream) and/or another distro?

I dont know, but i found nothing on the problem

Expected behaviour

Show the about:support page.

Actual behaviour

Freezes the Firefox process (no cpu activity visibile via btop after crash) and prints:

JavaScript warning: resource://gre/modules/Troubleshoot.sys.mjs, line 766: WebGL context was lost.

to the stdout

Steps to reproduce

Open the browser (settings dosent matter still freezes when creating new .mozilla direcotry) Navigate to about:support Firefox freezes

flushedface commented 1 month ago

Still crashes

biopsin commented 1 month ago

Hi, does webgl work? test examples here https://github.com/WebGLSamples/WebGLSamples.github.io scroll down to video thumbnails. On what hardware?

flushedface commented 3 weeks ago

Ok i managed to fix it by fixing my Pipewire audio setup (The daemon wasnt running correctly), the about:support page tries to detect the audio server but fails and then crashes (wich is still not good)

voidbert commented 3 weeks ago

I was experiencing the same problem and some other crashes. For example, opening a context menu by right clicking a page would crash Firefox as well. I am running sway 1.9 on an Intel HD Graphics 4400 (Mesa 24.1.5). I was able to fix the problem, and here are the steps I followed. However, I do not know what caused the issue in the first place, as am unable to recreate it after trying to revert my changes one by one.

# Intel only, maybe firefox tries to use Vulkan?
xbps-install mesa-vulkan-intel

# Remove all xdg-desktop-portal* packages, could portals be the issue?
xbps-remove xdg-desktop-portal xdg-desktop-portal-gtk ...

# For me, this removed some old libav versions. Maybe hardware video decoding affects what firefox
# tries to do on about:support?
xbps-remove -Oo

reboot

Later, I was able to uninstall mesa-vulkan-intel and install back all xdg-desktop-portal packages, so I think those were not causing the issue in the first place. Though, I still find it suspicious for the crashes to be caused by old libav versions.

I also tried to tinker with about:config, enabling and disabling WebRender, both with and without hardware acceleration. Firefox crashed either way.

Sorry if this is not very scientific, but I at least wanted to report exactly what I did. Try to run xbps-remove -Oo && reboot and share how it went.

flushedface commented 3 weeks ago

I was experiencing the same problem and some other crashes. For example, opening a context menu by right clicking a page would crash Firefox as well. I am running sway 1.9 on an Intel HD Graphics 4400 (Mesa 24.1.5). I was able to fix the problem, and here are the steps I followed. However, I do not know what caused the issue in the first place, as am unable to recreate it after trying to revert my changes one by one.

# Intel only, maybe firefox tries to use Vulkan?
xbps-install mesa-vulkan-intel

# Remove all xdg-desktop-portal* packages, could portals be the issue?
xbps-remove xdg-desktop-portal xdg-desktop-portal-gtk ...

# For me, this removed some old libav versions. Maybe hardware video decoding affects what firefox
# tries to do on about:support?
xbps-remove -Oo

reboot

Later, I was able to uninstall mesa-vulkan-intel and install back all xdg-desktop-portal packages, so I think those were not causing the issue in the first place. Though, I still find it suspicious for the crashes to be caused by old libav versions.

I also tried to tinker with about:config, enabling and disabling WebRender, both with and without hardware acceleration. Firefox crashed either way.

Sorry if this is not very scientific, but I at least wanted to report exactly what I did. Try to run xbps-remove -Oo && reboot and share how it went.

I tried the same by uninstalling/installing Video drivers, and that did nothing for me. Firefox should add more debugging messages because i didnt now that Pipewire was causing this (audio is not always needed thats why i didnt noticed it, i dont watch stuff on that machine)

flushedface commented 3 weeks ago

I will do more testing on this

flushedface commented 2 weeks ago

Hi, does webgl work? test examples here https://github.com/WebGLSamples/WebGLSamples.github.io scroll down to video thumbnails. On what hardware?

WebGL worked, the issue was that firefox has no error handling if no audio server is available

voidbert commented 2 weeks ago

Hi, does webgl work? test examples here https://github.com/WebGLSamples/WebGLSamples.github.io scroll down to video thumbnails. On what hardware?

WebGL worked, the issue was that firefox has no error handling if no audio server is available

I was able to replicate the issue after the steps I listed. I had pipewire and pipewire-pulse running (the processes were visible in htop), and restarting them (along with wireplumber) fixed the issue. Maybe they were getting into a weird state that firefox didn't like. The step that likely fixed it for me before was rebooting, as that restarted pipewire.

Nonetheless, I switched to ALSA with dmix and the issue is now less common, but it still happened once in the last few days. However, restarting the browser after the crash worked.

I still find it very weird for the audio stuff to be causing firefox to crash, especially since for me, the about:support issue always happens in tandem with the browser also crashing when right clicking something and opening a context menu, even if that has nothing to with audio (or so I think).