Firefox 78.0 Released - Also Serves As The Newest ESR Version

[i-rinat]

Guest
Just use the VAAPI-vdpau bridge (libva-vdpau-driver) if you must use VDPAU.

They way VA-API is used in Firefox make it not compatible with libva-vdpau-driver. It won't work since libva-vdpau-driver can't support dmabuf-related bits because VDPAU doesn't support dmabuf-related APIs. It's just how VDPAU is.

[i-rinat]

To reiterate: video in a browser engine is different from a simple player. You want to decode the video in a sandboxed process, isolated from the one doing the rendering. So you need a way to share memory on the GPU. That's what DMABUF is for. X11 pixmaps apparently can also be used - but that's apparently much more bug prone than EGL+DMABUF, which is how things on Wayland and modern X11 is done. That's you answer.

Edit: a good video player would do the same IMO. Videos are often from untrusted sources - decoding them without proper isolation, well, see https://www.vice.com/en_us/article/v...ster-hernandez

To reiterate: you are spreading fear, uncertainty, and doubt.
X11 Pixmaps are not more "bug prone". They worked before just fine, so there is no reason for them to stop working now.
You can't really sandbox HARDWARE decoding. It's on hardware level. Though you may want sandbox demuxing which is in software. Demuxing is where all video-related vulnerabilities were exploited.

[i-rinat]

Not a matter of will, it's a matter of resources. At Mozilla we're stretched thin as it is; we keep improving the Linux port but there's only so much time available to do stuff. That being said patches are always welcome, I hang out on our #introduction channel and I'm glad to help new contributors.

It's more complicated than that. I've published patches which support hardware decoding for XRender compositor, but they were declined by a module owner.
As far as I understand, Basic compositor is now treated as a fallback and they want to keep it away from any hardware acceleration.

Still don't understand how support for XRender compositor will compromise all-software fallback, but I guess I have to accept that. Hope that issues with EGL/X11/VA-API will be fixed soon.

[crystall]

It's more complicated than that. I've published patches which support hardware decoding for XRender compositor, but they were declined by a module owner. As far as I understand, Basic compositor is now treated as a fallback and they want to keep it away from any hardware acceleration.

Still don't understand how support for XRender compositor will compromise all-software fallback, but I guess I have to accept that. Hope that issues with EGL/X11/VA-API will be fixed soon.

I'm not up to speed on the details but it might be for stability reasons. The basic compositor is a last-resort fallback so we might want to keep it away from any issue that could arise from the drivers - especially old ones. Still, can you point me to the bug? I'm curious about the reasoning behind it.

[down1]

Let it be marked on the calendar 03/07/2020 I got firefox running in wayland (initially released in 2008) with basic video hardware acceleration working with no noticeable problems!

[i-rinat]

The basic compositor is a last-resort fallback so we might want to keep it away from any issue that could arise from the drivers - especially old ones.

Yeah, but there are two basic compositors. One is all-software, and the other is the XRender-enhanced one. I required XRender, so it wasn't like it could break an all-software fallback.

Still, can you point me to the bug? I'm curious about the reasoning behind it.

Sure. 1644610.

[phuclv]

Too bad the IT guys decided to configure Firefox in such a way that it doesn't open any page in under 5 seconds anymore. The work computer is the only one that cares about ESRs, everywhere else I'm using the beta channel.

That's exactly what the IT guys in my previous company did. They even disable page caching, DNS caching and many other things to make things worse. And when I enable those features manually, the flag will be immediately reverted by some auditing software. They make Firefox the default browser but too bad, most people in the company have never used FF before and now they think that FF is that slow and hence will never use FF again in their personal PCs. Chrome is forbidden so people do various workarounds to use Chrome instead

[bug77]

That's exactly what the IT guys in my previous company did. They even disable page caching, DNS caching and many other things to make things worse. And when I enable those features manually, the flag will be immediately reverted by some auditing software. They make Firefox the default browser but too bad, most people in the company have never used FF before and now they think that FF is that slow and hence will never use FF again in their personal PCs. Chrome is forbidden so people do various workarounds to use Chrome instead

We still have internal stuff that requires IE

[treba]

To reiterate: you are spreading fear, uncertainty, and doubt.
X11 Pixmaps are not more "bug prone". They worked before just fine, so there is no reason for them to stop working now.
You can't really sandbox HARDWARE decoding. It's on hardware level. Though you may want sandbox demuxing which is in software. Demuxing is where all video-related vulnerabilities were exploited.

I was referring to the fact that pixmap sharing was disabled by default in FF for years now due to at least one bug with the nvidia driver. Maybe that could have been fixed in FF or the driver - that's why I put the word "apparently" into the sentence. Also, the xrender backend AFAIK has never been enabled by default - I don't know why, but I'd suspect all kinds of bugs being the cause.

Concerning isolation: AFAIK the browser vendors all have been trying to move the decoding etc. work to isolated processes, including hardware decoding. If I understand you correctly, you claim that that's not necessary - or do I get you wrong? Why are you saying then I'd be spreading fear?

[i-rinat]

I was referring to the fact that pixmap sharing was disabled by default in FF for years now due to at least one bug with the nvidia driver. Maybe that could have been fixed in FF or the driver - that's why I put the word "apparently" into the sentence. Also, the xrender backend AFAIK has never been enabled by default - I don't know why, but I'd suspect all kinds of bugs being the cause.

I couldn't find a reason why pixmap sharing was disabled. Discussion in 1193015 mentions some requirements in the spec, with an idea how to make changes that conform to the spec. Then after two weeks there is a patch that just disables the feature altogether. Perhaps, it was just an easier solution — revert to software-only code.

XRender was also used for years, maybe even from the almost beginning of Linux support, since it was the only way to get a decent graphics performance. Remember how we could see how windows are updated top to bottom when VESA fallback driver was in use? That's how it was without XRender. Which was, and still is a X11 API for 2d acceleration.
XRender is often blamed for issues, but if you are using GTK applications on X.Org, you are using XRender, at least for text glyph caching. So it's not an obscure tech, it's widely used for years.

Concerning isolation: AFAIK the browser vendors all have been trying to move the decoding etc. work to isolated processes, including hardware decoding. If I understand you correctly, you claim that that's not necessary - or do I get you wrong?

No, I'm saying that sandboxing is a bit harder topic. It can't be reduced to "technology A — good, technology B — bad".
For example, dma-buf vs. X11 Pixmaps. The X11 protocol is inherently non-secure, since from every connection one can spy on other windows. But if one uses a DRM connection, they may create a GL context, allocate textures and read them back into main memory. Most of drivers do not clear texture memory, so that's how malicious code may steal previous images. I can't see why DRM is more secure than X11 in that case. It's good idea to move code that requires access to hardware to a separate process, to reduce attack surface. But even with this code moved to a separate process, hardware access is still a security hole.

Why are you saying then I'd be spreading fear?

Your words implicitly convey fear of older X11 APIs. People read that and assume they are all extremely buggy. That also imply newly-added APIs being a solution for everything. That is also wrong. Almost every technology contains bugs. The more recent technology is, the more bugs there are.

I'm not against newer APIs. They were created for a reason, and allow some nicer things. I just prefer to have working features with older technology, and only occasionally testing newer tech, which may break my workflow. Testing new tech is fun, but if any bug prevents me from simple web surfing, my sadness grows.