User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

1. Have an Intel HD Graphics 3000 GPU on a ThinkPad T520
2. WebRender is enabled by default
3. Try to play GIF in this tweet: https://twitter.com/cryptonator1337/status/1269260767913795584

Actual results:

GIF shows a green or black screen when played.

Expected results:

GIF should play correctly. Doesn't happen with every GIF though, this one works: https://twitter.com/Twitter/status/1288540609310056450 Non-Twitter GIFs also work. This user reported the same problem I think: https://old.reddit.com/r/firefox/comments/jwll0r/embed_videos_now_playing_green_or_black_screens/
Tried it with a clean install + profile, same result.
Disabling WebRender via gfx.webrender.force-disabled works.

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

Thanks for the report! Please open about:support, click on "Copy text to clipboard" and paste it here. Thanks!
Does this problem still occur with https://nightly.mozilla.org?

Output from about:support, I used a portable Firefox for this to have a minimal configuration. I hope this is not a problem.

(In reply to Darkspirit from comment #2)

Does this problem still occur with https://nightly.mozilla.org?

Yes, happens on the latest Nightly too

MacOS also had trouble with Intel HD Graphics 3000.

Windows 10 20H2 x64, ThinkPad T420, Firefox 83.0, WebRender enabled, Intel HD 3000

I have the same issue. The problem does not show up if I force the use of a dedicated nvidia NVS 4200M for Firefox and it reappears once I switch back to the HD 3000.

Martravi, does whether it works or not depend on the dimensions of the gif?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #7)

Martravi, does whether it works or not depend on the dimensions of the gif?

It depends on the dimensions, larger "gif"s on twitter work fine. The particular gif pointed out by the Reporter however has the exact same issue.

The drivers here are from 2015 and 2016 respectively. Those are pretty old. People running into this might try searching for updated drivers.

(In reply to Jim Mathies [:jimm] from comment #9)

The drivers here are from 2015 and 2016 respectively. Those are pretty old. People running into this might try searching for updated drivers.

These are the latest drivers available for the HD 3000 on Windows 8.1 or Windows 10, respectively. They are officially supported on these platforms by the manufacturer and Microsoft.

I can reproduce this locally.

It looks like this is triggered by the border-radius that twitter puts around video. If I remove the border-radius the video appears. This means that likelihood of running into this outside of twitter is much lower.

Martravi, are the other gifs/videos you've noticed that are broken?

I can reproduce this with wrench using the yuv-clip.yaml test.

It looks like this only happens when the shader is optimized by the D3D compiler.

Looks like this is the same switch statement problem as with the last gen6 compiler bug.

I accidentally put the fix up for this on bug 1678903.

na

(In reply to Jeff Muizelaar [:jrmuizel] from comment #17)

I accidentally put the fix up for this on bug 1678903.

Jeff meant bug 1678924.

I'm experiencing what seems like this bug (with the Tweet linked in the Steps to Reproduce for this bug) on Firefox 88, but not Firefox 87, on two Early 2011 13" MacBook Pros (Sandy Bridge CPU with Intel HD Graphics 3000) running Windows (one is running Windows 7, the other is running Windows 10 20H2). Before I go further and attach about:support output, etc., I wanted to check whether I should post to this bug or file a new bug. As a user, it looks like the same bug to me, but from a technical POV I don't know if this is actually the same bug or if it's something different.

(My real-world failure actually involves some but not all WebRTC video showing up as big black or green squares instead of actual video, but in my testing, reproducibility of that problem corresponds perfectly, one-to-one, with reproducibility of this bug.)

You are right, it was fixed but now the exact same bug is happening again (or a similar bug with the same outcome). Seems like a regression. I still have the same system as in my report but with Firefox 88 now of course ;) WebRender is enabled according to about:support

I think I was able to narrow things down using mozregression. I am attaching the log output. I think mozregression narrowed it down to a single commit, the commit for bug 1695912, but this is my first time using mozregression, so I would suggest looking at the log file yourself in case I misunderstood it.

I hope this helps.

Thank you so much for finding the regression range, Barry! Please do file a new bug for this so we can track it as a new regression. Add me to the CC list and I can help move it from there.

I have filed the new bug as bug 1708937. Please let me know if there's anything else I need to do.