It looks like you're actually on Firefox 74 which is not a stable release. Maybe you should try rolling it back to the current stable release.

Other than that, you can try to remove video hardware acceleration by disabling media.hardware-video-decoding.enabled in about:config.

Hey. Thank you for your reply. I posted that question from the firefox developer edition as I wanted to see if it worked there, but it didn't either. I tried disabling hardware video decoding but it sadly didn't work either. Thank you for your help though.

Does Widevine work here ?

• https://shaka-player-demo.appspot.com/demo/

cor-el said

Does Widevine work here ?

• https://shaka-player-demo.appspot.com/demo/

Sadly it still crashes immediately

Hi Quirinbrunner:

I believe this is fixed in Firefox 73.0.1 which was released today. Please give it a try.

Cheers!

...Roland

Sadly it still crashes :/

Is there any information I could give that could help?

So I now downgraded glibc and lib32-glibc which fixed the problem. Thank you all for your help! Have a lovely day :)

If anyone is running into this and is willing to test, it would be useful to know if running with the environment variable `MOZ_DISABLE_GMP_SANDBOX=1` set impacts the crash. That env var can be used to disable the sandbox Widevine runs in. You can unset the var once you've tested.

We've seen new versions of glibc run into the sandbox because they change the syscalls some functions use. So if setting that fixes the problem, that would be helpful to know. If it does fix the problem, running with the env var `MOZ_SANDBOX_LOGGING=1` set should log to the terminal what call is blocked. If Mozilla can get that info we can use it to adjust the sandbox as needed.

bvandyk said

If anyone is running into this and is willing to test, it would be useful to know if running with the environment variable `MOZ_DISABLE_GMP_SANDBOX=1` set impacts the crash. That env var can be used to disable the sandbox Widevine runs in. You can unset the var once you've tested. We've seen new versions of glibc run into the sandbox because they change the syscalls some functions use. So if setting that fixes the problem, that would be helpful to know. If it does fix the problem, running with the env var `MOZ_SANDBOX_LOGGING=1` set should log to the terminal what call is blocked. If Mozilla can get that info we can use it to adjust the sandbox as needed.

I would love to help but even with the glib and lib32-versions at the versions they were before it doesn't crash anymore.