1751363 - VA-API: creating video snapshot fails due to RDD sandbox + Since bug 1724385 (98), VAAPI fails in general due to RDD sandbox

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, defect, P1)

Description

[Martin Stránský [:stransky] (ni? me)]

We can't create GL context in RDD process which leads to missing video snapshots. It generally brings back Bug 1712588.

What's broken:

• we can't take video snapshots (context menu -> take snapshot)
• bookmarked page with video context is black
• D&D of tabs with video playback is black

Comment 1

[Martin Stránský [:stransky] (ni? me)]

Some details were provided to Bug 1724385 which also depends on this one.

Run with MOZ_SANDBOX_LOGGING=1 gives me:

Sandbox: Failed errno -2 op stat flags 00 path /tmp/Temp-d7ba8966-a234-4d30-9fb1-41087569e0c9/mesa_shader_cache
Sandbox: Failed errno -2 op open flags 02000000 path /home/komat/Programy/firefox-nightly/libEGL.so
Sandbox: Failed errno -2 op open flags 02000000 path /home/komat/Programy/firefox-nightly/libGLdispatch.so.0
Sandbox: Failed errno -2 op open flags 02000000 path /home/komat/Programy/firefox-nightly/libGL.so
Sandbox: Failed errno -2 op open flags 02000000 path /home/komat/Programy/firefox-nightly/libGLX.so.0
Sandbox: SandboxBroker: denied op=open rflags=2204000 perms=0 path=/etc/glvnd/egl_vendor.d for pid=40950
Sandbox: Failed errno -13 op open flags 02204000 path /etc/glvnd/egl_vendor.d
Sandbox: SandboxBroker: denied op=open rflags=2204000 perms=0 path=/usr/share/glvnd/egl_vendor.d for pid=40950
Sandbox: Failed errno -13 op open flags 02204000 path /usr/share/glvnd/egl_vendor.d
[GFX1]: Failed to create snapshot GLContext.

Reproduction steps are fairly easy, play a video clip on a page and try to bookmark it or move by D&D.

Comment 2

[Robert Mader [:rmader]]

Dupe of bug 1749623?

Comment 4

[Darkspirit]

Gnome Wayland, Debian Testing, Intel

bug 1752282 comment 16: Since bug 1724385, VAAPI seems to require GL context in RDD, otherwise won't work anymore.
Workaround is MOZ_DISABLE_RDD_SANDBOX=1.

Expected: sudo intel_gpu_top has hw video decoding workload.
Actual: It doesn't have.
STR (for X11/Xwayland with Mesa >=21 or Wayland):
MOZ_SANDBOX_LOGGING=1 MESA_GLSL_CACHE_DISABLE=1 mozregression --repo autoland --launch d87eb81f8495 --pref media.ffmpeg.vaapi.enabled:true -a https://bug1619882.bmoattachments.org/attachment.cgi?id=9149605 -P stdout

0:32.28 INFO: b'libva info: va_openDriver() returns 0'
0:32.28 INFO: b'Sandbox: SandboxBroker: denied op=open rflags=0 perms=0 path=/dev/graphics/fb0 for pid=17557'
0:32.28 INFO: b'Sandbox: Failed errno -13 op open flags 00 path /dev/graphics/fb0'
0:32.28 INFO: b'Sandbox: Failed errno -2 op open flags 02000000 path /tmp/tmpcfk2evpu/firefox/libEGL.so'
0:32.28 INFO: b'Sandbox: Failed errno -2 op open flags 02000000 path /tmp/tmpcfk2evpu/firefox/libGLdispatch.so.0'
0:32.28 INFO: b'Sandbox: Failed errno -2 op open flags 02000000 path /tmp/tmpcfk2evpu/firefox/libGL.so'
0:32.28 INFO: b'Sandbox: Failed errno -2 op open flags 02000000 path /tmp/tmpcfk2evpu/firefox/libGLX.so.0'
0:32.28 INFO: b'Sandbox: SandboxBroker: denied op=open rflags=2204000 perms=0 path=/etc/glvnd/egl_vendor.d for pid=17557'
0:32.28 INFO: b'Sandbox: Failed errno -13 op open flags 02204000 path /etc/glvnd/egl_vendor.d'
0:32.28 INFO: b'Sandbox: SandboxBroker: denied op=open rflags=2204000 perms=0 path=/usr/share/glvnd/egl_vendor.d for pid=17557'
0:32.28 INFO: b'Sandbox: Failed errno -13 op open flags 02204000 path /usr/share/glvnd/egl_vendor.d'

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1724385

Comment 11

[[e-mail]]

Can confirm this on Manjaro Linux: I believe I was updated to Firefox 98 yesterday, ever since I'm unable to play video on any website, sometimes it works briefly but playback lags and stops to the point where it's unplayable. The issue goes away after disabling "media.ffmpeg.vaapi.enabled" in "about:config", might try disabling the sandbox feature as a workaround to keep video acceleration.

Comment 13

[Tom S [:evilpie]]

Workaround: Start Firefox with MOZ_DISABLE_RDD_SANDBOX=1. (This decreases security)

Comment 14

[[e-mail]]

I'm using that workaround now: If I start FF with "export MOZ_DISABLE_RDD_SANDBOX=1;kstart5 firefox" from a console, I can keep video acceleration enabled and everything plays back fine again. You can also put that export in your ~/.profile file so it's applied system wide, wouldn't recommend that though as you're likely to forget about it and I understand this may translate into less security.

Comment 15

[Mel]

(In reply to Tom Schuster [:evilpie] from comment #13)

Workaround: Start Firefox with MOZ_DISABLE_RDD_SANDBOX=1. (This decreases security)

Why not recommend a downgrade to 97.0.2 instead where everything just worked without compromising security?

Comment 16

[Peng Shao]

(In reply to Mel from comment #15)

Why not recommend a downgrade to 97.0.2 instead where everything just worked without compromising security?

It asks to create a new profile and it may be inconvenient for some users

Comment 17

[Darkspirit]

Don't downgrade because security bugs have been fixed.
The workaround only disables the sandbox for a process that contains fuzzed media decoders, javascript is still sandboxed in its content process.
Personally I don't use the workaround and just wait for this bug to be fixed.

Comment 18

[Daimar Stein]

Can confirm this on Manjaro Linux: I believe I was updated to Firefox 98 yesterday, ever since I'm unable to play video on any website, sometimes it works briefly but playback lags and stops to the point where it's unplayable. The issue goes away after disabling "media.ffmpeg.vaapi.enabled" in "about:config", might try disabling the sandbox feature as a workaround to keep video acceleration.

Can confirm this happening, specially with Twitch, as it constantly keeps crashing with Error #3000. Other sites work normally on my experience and disabling media.ffmpeg.vaapi.enabled does solve the problem, but yeah, no luck with VA-API in the current state.

MOZ_DISABLE_RDD_SANDBOX=1 does not solve the issue for me, at least using the Flatpak version of Firefox on Wayland.

Using MOZ_LOG="PlatformDecoderModule:5" I get:
[Child 336: Main Thread]: D/PlatformDecoderModule FFMPEG: VA-API FFmpeg is disabled by platform

But when I try to play a video the logs seem to treat like VA-API is working correctly in the beginning:

[RDD 490: MediaPDecoder #2]: D/PlatformDecoderModule FFVPX: Initialising VA-API FFmpeg decoder
[RDD 490: MediaPDecoder #2]: D/PlatformDecoderModule FFVPX:   Format vp9 is accelerated
[RDD 490: MediaPDecoder #2]: D/PlatformDecoderModule FFVPX:   codec vp9 : Google VP9
[Child 410: MediaPDecoder #1]: V/PlatformDecoderModule AudioTrimmer[7f8448a792e0] ::PrepareTrimmers: sample[0,21000] no trimming information
[RDD 490: MediaPDecoder #1]: D/PlatformDecoderModule OpusDataDecoder[7fbcd8a88800] ::Decode: Opus decoder skipping 312 of 960 frames
libva info: VA-API version 1.12.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
[Child 410: MediaPDecoder #2]: V/PlatformDecoderModule AudioTrimmer[7f8448a792e0] ::HandleDecodedResult: sample[0,21000] (decoded[0,13500] no trimming needed
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/intel-vaapi-driver/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_12
libva info: va_openDriver() returns 0

But I eventually get this error:
[RDD 490: MediaPDecoder #1]: D/PlatformDecoderModule failed to create texture over DMABuf memory!

Which leads to these messages and after that it falls back to regular FFmpeg decoder:

[RDD 490: MediaPDecoder #1]: D/PlatformDecoderModule VideoFrameSurfaceVAAPI: deleting dmabuf surface UID = 1
[RDD 490: MediaPDecoder #1]: D/PlatformDecoderModule VideoFrameSurfaceVAAPI: VAAPI releasing dmabuf surface UID = 1

Comment 19

[walmartguy]

It doesn't even work with MOZ_DISABLE_RDD_SANDBOX=1 for me with 99.b1 (works with 98).

Comment 21

[ajtbecool]

What are the exact security implications of the aforementioned workaround? I want a secure browser, but I also don't want my lap to burn while watching YouTube videos xD.

Comment 22

[Ivan Garcia]

Can confirm issue on Fedora 35. I just updated to Firefox 98 and VA-API HW acceleration is not working. It was working fine on Firefox 97.

Comment 23

[Tom S [:evilpie]]

Comment 18 (Daimar Stein) and comment 19 (walmartguy) please open new bugs or check if there is an existing similar bug, this bug is only about VAAPI not working because of sandboxing.

What are the exact security implications of the aforementioned workaround? I want a secure browser, but I also don't want my lap to burn while watching YouTube videos xD.

It's hard to quantify. Thanks to VA-API decoding now happening in its own RDD process exploitation gets hard of course. But having no sandbox at all obviously makes it trivial to take over everything if an exploit is found.

Comment 26

[JORGETECH]

I can confirm this issue affects me in Firefox 98.0.1 (Kubuntu 21.10, AMD Ryzen iGPU with Mesa 22.0.0).

Playing a YouTube video makes the browser crash or not load the video and I get this on the console output:

libva info: VA-API version 1.14.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_14
ATTENTION: default value of option mesa_glthread overridden by environment.
/usr/share/libdrm/amdgpu.ids: Permission denied

I had to set the media.rdd-process.enabled flag to false to fix it, this was after updating Firefox, it didn't do this before.

I'm surprised this change landed in an stable release.

Comment 27

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 9 duplicates, 13 votes and 78 CCs.
:gcp, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 28

[Gian-Carlo Pascutto [:gcp]]

I'm surprised this change landed in an stable release.

The feature is marked as disabled in Firefox 98.

Comment 29

[Gian-Carlo Pascutto [:gcp]]

The feature is marked as disabled in Firefox 98.

And indeed it is: https://searchfox.org/mozilla-central/source/modules/libpref/init/StaticPrefList.yaml#8915

So to answer the question: nothing "landed in a stable release", this configuration was never supported nor released yet because of bugs like this one.

Comment 30

[iamtrazy]

please consider increasing the severity of this bug , this still happens on both amd and intel on firefox 98.0.2 , hardware accelerations worked perfectly fine before 98 update without disabling rdd sandbox.

Comment 31

[[e-mail]]

I agree. I'm surprised there isn't any progress on an issue this obvious and severe yet. On both my and my mother's computer we have to open Firefox with a console command before this is fixed based on when we need to watch videos.

Comment 32

[Julian Sikorski]

(In reply to [e-mail] from comment #31)

I agree. I'm surprised there isn't any progress on an issue this obvious and severe yet. On both my and my mother's computer we have to open Firefox with a console command before this is fixed based on when we need to watch videos.

Just disable VAAPI and you will be able to watch videos just fine. On my machine (Ryzen 4500U) the difference in CPU load when watching youtube is minimal anyway. Please keep in mind that hardware acceleration was never officially enabled in release builds so please adjust your expectations accordingly.

Comment 33

[russianneuromancer]

Just disable VAAPI and you will be able to watch videos just fine.

Some hardware cannot handle anything above 480p on YouTube unless hardware acceleration is enabled and works.

Comment 34

[Jay Chu]

(In reply to [e-mail] from comment #31)

I agree. I'm surprised there isn't any progress on an issue this obvious and severe yet. On both my and my mother's computer we have to open Firefox with a console command before this is fixed based on when we need to watch videos.

For now, set the media.rdd-process.enabled flag to false, or set the environment variable in proper files.

Comment 35

[EvilMav]

(In reply to Jay Chu from comment #34)

(In reply to [e-mail] from comment #31)

I agree. I'm surprised there isn't any progress on an issue this obvious and severe yet. On both my and my mother's computer we have to open Firefox with a console command before this is fixed based on when we need to watch videos.

For now, set the media.rdd-process.enabled flag to false, or set the environment variable in proper files.

This is helpful, thank you. Nevertheless, most "normal" users will never find this topic, neither the config page. Firefox won't work for everyday use for them (consider the popularity of video streaming) and they will be switching to a browser that works. With AMD and intel GPUs common nowadays, we are talking a significant exodus of firefox users towards alternatives. Current P3 priority absolutely does not cut it.

Comment 36

[Paul Menzel]

@EvilMav, nobody disagrees, but it’s unrelated to the bug report. Firefox is FLOSS, so you can fix it or pay somebody. As long as users don’t support Firefox financially (donate or buy commercial GNU/Linux distribution licenses like RHEL desktop) so more developers can be paid to work on Firefox under GNU/Linux in full-time, the current state won’t change. But as written, it’s off-topic.

Comment 37

[Gian-Carlo Pascutto [:gcp]]

I'm updating the flags just to make it clear we are in fact already working on this, see also https://bugzilla.mozilla.org/show_bug.cgi?id=1743926#c3.

Comment 41

[kaypa]

updated to v99 on arch and MOZ_DISABLE_RDD_SANDBOX=1 workaround is not valid anymore

Comment 42

[Lucas Rizzini]

Same behavior here. https://www.reddit.com/r/linuxquestions/comments/tx7zou/firefox_99_crashing_with_hardware_decoding_using/

Full system specs.

Comment 43

[kaypa]

(In reply to kaypa from comment #41)

updated to v99 on arch and MOZ_DISABLE_RDD_SANDBOX=1 workaround is not valid anymore

looks like it's working again in nightly and has been fixed by https://bugzilla.mozilla.org/show_bug.cgi?id=1758610

not sure though

(don't know how to edit my comment sorry)

Comment 44

[Irxil]

Still having issues with the latest nightly on my end. Running 101.0a1 (2022-04-05) and I see a small increase in video decode usage (using Intel GPU Top) when the Big Buck Bunny video loads (using 4k vp9 which is supported by my Tiger Lake laptop) but then it goes back to zero immediately and there's no further acceleration.

In the console, the following lines repeat themselves multiple times when the Youtube page is loaded:

libva info: VA-API version 1.13.0
libva info: User environment variable requested driver 'iHD'
libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_13
libva info: va_openDriver() returns 0

Looks like it is loading Vaapi properly but still not getting processed by the GPU.

Comment 45

[Irxil]

When I run Firefox Nightly with MOZ_SANDBOX_LOGGING=1 I get the following:

Sandbox: SandboxBroker: denied op=open rflags=0 perms=0 path=/dev/graphics/fb0 for pid=11438
Sandbox: Failed errno -13 op open flags 00 path /dev/graphics/fb0
Sandbox: Failed errno -2 op open flags 02000000 path <path to Firefox>/firefox-nightly/firefox/libEGL.so
Sandbox: Failed errno -2 op open flags 02000000 path <path to Firefox>/firefox-nightly/firefox/libGLdispatch.so.0
Sandbox: Failed errno -2 op open flags 02000000 path <path to Firefox>/firefox-nightly/firefox/libGL.so
Sandbox: Failed errno -2 op open flags 02000000 path <path to Firefox>/firefox-nightly/firefox/libGLX.so.0
Sandbox: SandboxBroker: denied op=open rflags=2204000 perms=0 path=/etc/glvnd/egl_vendor.d for pid=11438
Sandbox: Failed errno -13 op open flags 02204000 path /etc/glvnd/egl_vendor.d
Sandbox: SandboxBroker: denied op=open rflags=2204000 perms=0 path=/usr/share/glvnd/egl_vendor.d for pid=11438
Sandbox: Failed errno -13 op open flags 02204000 path /usr/share/glvnd/egl_vendor.d
Sandbox: SandboxBroker: denied op=open rflags=1102 perms=0 path=/etc/igfx_user_feature.txt for pid=11438
Sandbox: Failed errno -13 op open flags 01102 path /etc/igfx_user_feature.txt

Comment 46

[lxsq131]

Seems like it's working on Firefox Nightly 101.0a1 (2022-04-06).
MOZ_DISABLE_RDD_SANDBOX=0 firefox-trunk ATTENTION: default value of option mesa_glthread overridden by environment. libva info: VA-API version 1.8.0 libva info: Trying to open /opt/amdgpu/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_1_8 ATTENTION: default value of option mesa_glthread overridden by environment. libva info: va_openDriver() returns 0 ATTENTION: default value of option mesa_glthread overridden by environment. ATTENTION: default value of option mesa_glthread overridden by environment. ATTENTION: default value of option mesa_glthread overridden by environment. libva info: VA-API version 1.8.0 libva info: Trying to open /opt/amdgpu/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_1_8 ATTENTION: default value of option mesa_glthread overridden by environment. libva info: va_openDriver() returns 0

cat /sys/kernel/debug/dri/0/amdgpu_pm_info return VCN:Enabled. That indicates Hardware decoding are working.

Comment 47

[[e-mail]]

Wasn't the whole thing fixed in Firefox 100 as a previous comment suggested? Was hoping so but I see the bug is still open.

Comment 48

[lxsq131]

(In reply to lxsq131 from comment #46)

Seems like it's working on Firefox Nightly 101.0a1 (2022-04-06).
MOZ_DISABLE_RDD_SANDBOX=0 firefox-trunk ATTENTION: default value of option mesa_glthread overridden by environment. libva info: VA-API version 1.8.0 libva info: Trying to open /opt/amdgpu/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_1_8 ATTENTION: default value of option mesa_glthread overridden by environment. libva info: va_openDriver() returns 0 ATTENTION: default value of option mesa_glthread overridden by environment. ATTENTION: default value of option mesa_glthread overridden by environment. ATTENTION: default value of option mesa_glthread overridden by environment. libva info: VA-API version 1.8.0 libva info: Trying to open /opt/amdgpu/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_1_8 ATTENTION: default value of option mesa_glthread overridden by environment. libva info: va_openDriver() returns 0

cat /sys/kernel/debug/dri/0/amdgpu_pm_info return VCN:Enabled. That indicates Hardware decoding are working.

No. I tried again and the error was back. Still needs to disable RDD sandbox. Firefox Nightly 101.0a1 (2022-04-06).

libva info: VA-API version 1.8.0
libva info: Trying to open /opt/amdgpu/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_8
ATTENTION: default value of option mesa_glthread overridden by environment.
/usr/share/libdrm/amdgpu.ids: Permission denied
libva info: va_openDriver() returns 0

Comment 51

[Mel]

Can you please clarify what does fix-optional status for firefox 100 mean for this bug?

Comment 52

[Darkspirit]

I assume this bug will be fixed once video decoding has been moved to a utility process (bug 1722051).
Until then, MOZ_DISABLE_RDD_SANDBOX=1 environment variable is required to try out experimental VAAPI.

Comment 54

[walmartguy]

(In reply to Darkspirit from comment #52)

I assume this bug will be fixed once video decoding has been moved to a utility process (bug 1722051).
Until then, MOZ_DISABLE_RDD_SANDBOX=1 environment variable is required to try out experimental VAAPI.

It doesn't work reliably regardless, as also some other reports here indicate: intel_gpu_top shows that hardware decoding initially is used for a brief moment, but then Firefox falls back to CPU decoding with intel_gpu_top reporting 0% hardware video decoding load. For whatever weird reason, it very rarely can continue to show hardware decoding load, but then breaks upon next Firefox launch too. VAAPI is completely unusable since Firefox 99 with at least Intel, also with MOZ_DISABLE_RDD_SANDBOX=1. Reports that claim it to be working without making sure it really does so via intel_gpu_top over an extended period of usage (i.e. days) are unfortunately not reliable.

I think I'll just go back to 98 and perhaps set up some 3rd party sandboxing in case there are open CVEs. Hardware decoding is not a bonus on slow CPUs, it's a must. Really annoying that, despite of still being experimental, it has been broken so hard.

Comment 55

[[e-mail]]

In my case I use an AMD card on Manjaro Linux (default free amdgpu driver). I can say that with Firefox 99.0.1 video on Youtube usually plays but tries going back to a lower resolution at first, also any extra system load like other tabs will cause playback to freeze and you have to restart the video. MOZ_DISABLE_RDD_SANDBOX=1 still works fine for me thank goodness, using that it all functions as intended. Hope Firefox 100 at least doesn't break this workaround, in case the final fix isn't going to make it in time which would obviously be ideal.

Comment 56

[Martin Stránský [:stransky] (ni? me)]

(In reply to walmartguy from comment #54)

(In reply to Darkspirit from comment #52)

I assume this bug will be fixed once video decoding has been moved to a utility process (bug 1722051).
Until then, MOZ_DISABLE_RDD_SANDBOX=1 environment variable is required to try out experimental VAAPI.

It doesn't work reliably regardless, as also some other reports here indicate: intel_gpu_top shows that hardware decoding initially is used for a brief moment, but then Firefox falls back to CPU decoding with intel_gpu_top reporting 0% hardware video decoding load.

That indicates a bud in decoding itself and not a sandbox issue. Please file that as a new bug.

Comment 57

[temptempor]

Attachment: firefox100_crash.log

Hello. Just to add in that this issue at least for my setup (Arch Linux, Firefox 100) is still current.

The previous comment suggest the problem might lie with the decoder but no other software on my machine has problem decoding through vaapi at the moment and the problems began right when RDD sandboxing was made default.

Firefox regularly fails and generate loads of crash log on my system each time it comes across a video since ~v98/99. The videos often crash, try to revert to low quality. It's particularly evident on sites like IMGUR. This was working fine before (and it took a long time to get it working) yet it was broken since 2 releases ago and is still in this state... It's quite sad Linux users are the second-class citizens on these features all over again.

---

Version: Firefox 100
OS: Arch Linux
FFMPEG: 5.0-7
vainfo: VA-API version: 1.14 (libva 2.14.0)

---

MOZ_DISABLE_RDD_SANDBOX=1 does not stop this failure on my machine.
Nor does MOZ_ENABLE_WAYLAND=1 individually, or combined.

---

Cf. Logs.

Comment 58

[albertogomezmarin]

for me at least the workaround is working as expected .. But I think it's something that has to be fixed as soon as possible.. the no use of vaapi gets a browser that is not smooth and freezes with almost every playback or preview...
firefox is a lot worse since 98 version in my opinion for that.
So I think the RDD sandbox has to be disabled until this is addressed. The day to day use is very bad

Comment 59

[Martin Stránský [:stransky] (ni? me)]

I think we can fix that by moving GL code out of RDD process. IIUC we need to implement DMABuf based gfx::SourceSurface which can be serialized over IPC bridge to parent/content process where GL can be used and we'll map dmabuf surface only when we're asked for surface data.

Comment 60

[Martin Stránský [:stransky] (ni? me)]

Another option may be EGL_MESA_platform_gbm extension which creates GL context over GBM device (the one we use for dmabuf). That may solve this problem too so investigating.

Comment 61

[Gian-Carlo Pascutto [:gcp]]

Can you please clarify what does fix-optional status for firefox 100 mean for this bug?

It means that if there is a simple fix for the issue, release management would've considered taking that fix into Firefox 100. As is hopefully rather obvious, there isn't going to be a simple fix for this. It needs a ton of work - that has progressed well, thankfully.

I assume this bug will be fixed once video decoding has been moved to a utility process (bug 1722051).

The utility process makes it easier to move things in a separate processes each with a custom sandbox, but the plan is to fix the current RDD process for VA-API support before we consider that. The difficulty is adding support for exactly those features VA-API needs - multiplied by each video driver having slightly different requirements. Once the sandboxing code supports that we can look if there'd be a meaningful security benefit in moving things around.

Comment 62

[temptempor]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #61)

Can you please clarify what does fix-optional status for firefox 100 mean for this bug?

It means that if there is a simple fix for the issue, release management would've considered taking that fix into Firefox 100. As is hopefully rather obvious, there isn't going to be a simple fix for this. It needs a ton of work - that has progressed well, thankfully.

I assume this bug will be fixed once video decoding has been moved to a utility process (bug 1722051).

The utility process makes it easier to move things in a separate processes each with a custom sandbox, but the plan is to fix the current RDD process for VA-API support before we consider that. The difficulty is adding support for exactly those features VA-API needs - multiplied by each video driver having slightly different requirements. Once the sandboxing code supports that we can look if there'd be a meaningful security benefit in moving things around.

Is there an official way of working around this in the meantime? Since disabling RDD sandbox isn't enough anymore on Firefox 100?

Comment 63

[klubella]

(In reply to temptempor from comment #62)

(In reply to Gian-Carlo Pascutto [:gcp] from comment #61)

Can you please clarify what does fix-optional status for firefox 100 mean for this bug?

It means that if there is a simple fix for the issue, release management would've considered taking that fix into Firefox 100. As is hopefully rather obvious, there isn't going to be a simple fix for this. It needs a ton of work - that has progressed well, thankfully.

I assume this bug will be fixed once video decoding has been moved to a utility process (bug 1722051).

The utility process makes it easier to move things in a separate processes each with a custom sandbox, but the plan is to fix the current RDD process for VA-API support before we consider that. The difficulty is adding support for exactly those features VA-API needs - multiplied by each video driver having slightly different requirements. Once the sandboxing code supports that we can look if there'd be a meaningful security benefit in moving things around.

Is there an official way of working around this in the meantime? Since disabling RDD sandbox isn't enough anymore on Firefox 100?

For me, it still works with disabling sandbox even on Firefox 100.0. But I still hope this gets fixed soon. :)

Comment 64

[Miren Radia]

For me, it still works with disabling sandbox even on Firefox 100.0. But I still hope this gets fixed soon. :)

What's your system configuration (e.g. OS, GPU, VAAPI library) and what flags have you manually changed in about:config? FWIW, mine is

OS: Ubuntu 20.04
GPU: Intel HD Graphics 630 (Kaby Lake)
VAAPI library: Tried iHD and i965

and have tried modifying numerous flags (always setting media.ffmpeg.vaapi.enabled to true) with the environment variable MOZ_DISABLE_RDD_SANDBOX=1.

Comment 65

[Martin Stránský [:stransky] (ni? me)]

If MOZ_DISABLE_RDD_SANDBOX does not work please file another bug - it's not a sandbox issue then. This bug is about sandbox so please don't add off topics comments here.
Thanks.

Comment 67

[Darkspirit]

As of bug 1770407, MOZ_DISABLE_RDD_SANDBOX=1 is no longer needed for Mesa users.

Comment 69

[urjryyhbnolzlvtrry]

Attachment: firefox log

firefox does not use VAAPI (choppy video playback)
I also get choppy video playback in the beginning of playing a video (only for 1-2 sec) even with VAAPI disabled
Name Firefox
Version 102.0
Build ID 20220623063721
Distribution ID mozilla-flatpak

Comment 70

[urjryyhbnolzlvtrry]

(In reply to urjryyhbnolzlvtrry from comment #69)

Created attachment 9283237 [details]
firefox log

firefox does not use VAAPI (choppy video playback)
I also get choppy video playback in the beginning of playing a video (only for 1-2 sec) even with VAAPI disabled
Name Firefox
Version 102.0
Build ID 20220623063721
Distribution ID mozilla-flatpak

Wayland enabled with MOZ_ENABLE_WAYLAND=1

Comment 71

[Gian-Carlo Pascutto [:gcp]]

This bug is closed because it was fixed, so you're seeing a different problem. Please file a new bug. Flatpak could be a factor here, note above there is another bug linked were specific fixes were needed for Snap too.

Edit: Your log shows VA-API successfully initializing, so this looks unrelated to RDD/sandboxing and may be a completely unrelated performance thing. Again, file a new bug specific to your problem.