1629220 - Youtube flickering in Firefox Safe Mode

Status: VERIFIED FIXED

(Core :: Graphics, defect, P3)

Description

[sheelgautam995]

Attachment: Recording.m4v

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

1. Restart Firefox in safe mode.
2. Go to Youtube
3. Youtube link in the video - https://www.youtube.com/watch?v=fYuVzbIu_8o

Actual results:

See attached video

Expected results:

I don't know if its a bug with Youtube or Firefox. This only happens in Safe Mode. This doesn't happen normal mode with all addons disabled or enabled.

Comment 1

[sheelgautam995]

Attachment: about:support

Machine : Macbook Air 2014

Comment 2

[Hani Yacoub, Desktop QA]

Managed to reproduce the issue on MacOS 10.14 on Firefox Release 75.0, Firefox 76.0b4 and on Firefox Nightly 77.0a1 (2020-04-15).

Comment 3

[Bert Peers [:bpeers]]

Asking Jeff for triage ideas since this is MacOS specific. Thanks.

Comment 4

[Jeff Muizelaar [:jrmuizel]]

I can reproduce this. It looks like this only happens for software decoded video. h264 is fine.

Comment 5

[Firefox Bug Husbandry Bot]

Resetting severity to default of --.

Comment 6

[MarjaE]

Getting similar behavior without "safe" mode, and with or without hardware acceleration.

Comment 7

[Jeff Muizelaar [:jrmuizel]]

MarjaE, can you attach the graphics section of your about:support?

Comment 8

[MarjaE]

Attachment: Graphics settings

Comment 9

[MarjaE]

Not listed in the settings above, but running Mojave, rather than Catalina, and using an external monitor. I don't know what the original poster is running or using.

Comment 10

[Jeff Muizelaar [:jrmuizel]]

(In reply to MarjaE from comment #9)

Not listed in the settings above, but running Mojave, rather than Catalina, and using an external monitor. I don't know what the original poster is running or using.

Do you have hardware acceleration disabled?

Comment 11

[MarjaE]

Yes. That stops some other strobing, but it doesn't stop this. I've tried it with and without hardware acceleration and neither helps.

Comment 12

[MarjaE]

Currently working for me, don't know what has changed or whether it's working for the op.

Comment 13

[MarjaE]

P.S. Started again.

Comment 14

[MarjaE]

Tried turning off

dom.animations-api.implicit-keyframes.enabled

dom.animations-api.autoremove.enabled

That didn't work, so fixing bug 1619773 didn't cause this one. Too sick to test any of the other changes after that. Time frame strongly suggests related changes here:

https://github.com/mdn/sprints/issues/2933#issuecomment-610839764

Comment 15

[MarjaE]

Still occurs in "safe" mode.

Comment 16

[MarjaE]

Is anyone using a Mac without encountering this bug?

Comment 17

[MarjaE]

Bibisected to here:

https://phabricator.services.mozilla.com/D51762

which was intended to solve bug 1592150

Comment 18

[MarjaE]

I don't think I have webrender enabled. I get the same bug regardless of switching gfx.webrender.enabled to true or back to false.

Bibisected with auto-update disabled, that runs fine to today's version. This standard installation with auto-update disabled still fails. Nightly with my profile copied over works fine.

Stumped about what else to try.

Considering backing up, starting over, and then copying everything from my current profile,

Comment 19

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)

Comment 21

[numbermaniac]

On a couple of videos I tried, I noticed that the flickering (at least for the bottom bar - haven't tested the captions) disappears when setting the video quality to 480p, but re-appears when watching at 720p or higher. The flickering seemed to get more intense when the quality was increased to 1080p.

Comment 22

[numbermaniac]

Attachment: Flickering of the bottom bar when playing a video

Video used in this recording: https://www.youtube.com/watch?v=TWh1LkFu1QY

Comment 23

[numbermaniac]

Why is this marked as wontfix for Firefox 78? Does that mean 78 ESR users are stuck with this bug forever?

Comment 26

[Markus Stange [:mstange]]

Somehow this bug slipped through the cracks. I'll look at it soon.

Comment 27

[Markus Stange [:mstange]]

Attachment: standalone testcase

Comment 28

[Markus Stange [:mstange]]

This is happening because the "AttemptVideo[ConvertAnd]Scale" functions don't respect the existing clip region on the DrawTarget. The bug happens during composites in which there is no new video frame, so the compositor-side invalid region does not contain the entire video bounds. If the invalid region contains part of the video but not some element that overlaps the video, then we skip drawing that overlapping element. Usually that's fine, but if the video draws outside the invalid region, then it erases the overlapping element.

Comment 29

[Markus Stange [:mstange]]

Attachment: Bug 1629220 - When partially compositing into native layers with BasicCompositor, allow only one invalid rect per layer, and store the invalid rect on the render target instead of pushing a clip to the DrawTarget. r=mattwoodrow

This matches what we do in CompositorOGL.

This avoids having clipping state stored on the render target's DrawTarget.
As a result, we have access to the combined device clip rect in DrawGeometry,
and the video scale fast paths can observe the correct clip even though they
bypass the DrawTarget machinery.

This fixes flickering bugs caused by the video scale fast path in the native
layers configuration, i.e. on macOS only. We probably still have bugs on the
other platforms. It's possible that this bug is less observable on other
platforms due to additional copies of the invalid region, and those copies
ignore the bad content outside the invalid region.

Comment 30

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7d73dff3d673
When partially compositing into native layers with BasicCompositor, allow only one invalid rect per layer, and store the invalid rect on the render target instead of pushing a clip to the DrawTarget. r=mattwoodrow

Comment 31

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/7d73dff3d673

Comment 32

[Markus Stange [:mstange]]

Comment on attachment 9169266 [details]
Bug 1629220 - When partially compositing into native layers with BasicCompositor, allow only one invalid rect per layer, and store the invalid rect on the render target instead of pushing a clip to the DrawTarget. r=mattwoodrow

Beta/Release Uplift Approval Request

• User impact if declined: Flickering elements on video pages in safe mode on macOS
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: In safe mode, check whether the green square in attachment 9169206 [details] flickers.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It makes BasicCompositor (which is mostly untested on macOS) behave more like CompositorOGL, which is extensively tested.
• String changes made/needed:

Comment 33

[Peter Magyari (Desktop QA)]

Reproduced the issue on Firefox Nightly 81.0a1 (20200811091731)
Verified fixed on Firefox Nightly 81.0a1 (20200812214948)

Comment 34

[Julien Cristau [:jcristau]]

Comment on attachment 9169266 [details]
Bug 1629220 - When partially compositing into native layers with BasicCompositor, allow only one invalid rect per layer, and store the invalid rect on the render target instead of pushing a clip to the DrawTarget. r=mattwoodrow

macos gfx fix, verified in nightly, approved for 80.0b8

Comment 35

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/7e33355902e8

Comment 36

[Peter Magyari (Desktop QA)]

Verified fixed on Firefox Beta 80.0b8 (20200813191622)