User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Play this video https://gitlab.gnome.org/GNOME/gtk/uploads/acf519cdd3a35191704bcc7a87e3a11a/Screencast_28.05.2020_01_25_18.webm or play it on the page https://gitlab.gnome.org/GNOME/gtk/-/issues/2794

Actual results:

Black area where video should play. If I play it on the page, it is white instead.

Expected results:

Video picture visible.

My mistake, I use Firefox version 77, not 68. Cannot edit bug now.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Works for me on macOS, with Firefox 78 beta.

Can you reproduce in a clean Firefox profile ( https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles ) ?

I reproduced this on clean profile. The only thing that changed is now that part of window where the video plays was completely tranpsrent - I could see my background image.

BTW, I use linux, sway (wayland).

S3 on the assumption this is related to VA-API.

this is related to VA-API.

this is not. I tried disabling widget.wayland-dmabuf-vaapi.enabled - it didn't matter

• Could you navigate to about:support and copy that information onto this bug?
• Do you experience issues with any other videos in Fx, or is the problem specific to the video in comment 0?

Do you experience issues with any other videos in Fx, or is the problem specific to the video in comment 0?

The problem is just with the video in comment #0

I've poked at the video from comment 0 a bit and don't see anything odd with it. I wondered if this was a bug related to the alpha channel in WebM, but the file doesn't appear to have any alpha channel data. So far I'm unable to reproduce this.

Comment 4 mentions the area being transparent when using a clean profile. Is the area transparent for both the gitlab and the directly linked video?

Can you try using the Firefox Profiler with Firefox Nightly and record a profile of this taking place using the 'Media' preset then share that profile and paste the link here?

Comment 4 mentions the area being transparent when using a clean profile. Is the area transparent for both the gitlab and the directly linked video?

Yes, it's transparent in both cases.

What I found out:

1. The bug is reproduced only with hardware compositing enabled. In the Nightly, which I installed from the mozilla website hardware compositing was disabled and the video played normally. I enabled layers.acceleration.force-enabled in Nightly and reproduced the transparent video.
2. In my OS Firefox is built with layers.acceleration.force-enabled enabled by default, that's why I had hardware compositing enabled even in the clean profile.

Do I still need to record the profile?

(In reply to sorrow from comment #12)
<snip>

Do I still need to record the profile?

No, the information you provided is helpful in indicating this is a compositing issue. I'll change the component as the folks familiar with compositing should be better suited to debug further.

I installed sway, forced wayland, and OpenGL compositing on for Firefox, to match your about:support configuration. Works for me. Same with WebRender. Maybe darkspirit will have more luck reproducing.

With webrender it works for me too. But with opengl the video is transparent (not as css opacity, but wayland compositor level transparency, I can see what's behind the Fx window). Even with latest sway 1.5-rc1.

The only time I have seen similar symptoms is when a surface was incorrectly marked as opaque, and contained transparency. It ended up showing what was underneath like you noted. I wonder if that could be related.