1888052 - Video content shifts position/quality when mousing to different windows or monitors

Status: NEW

(Core :: Graphics, defect, P2)

Description

[Aetheora]

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

Steps to reproduce:

• Opened Firefox by clicking the desktop icon
• Accessed a website with video formatted content (not GIFs), ex. YouTube, Imgur, Facebook, etc, in a new browser window and/or tab

Actual results:

• Video content shifts position by several pixels within the media viewing window when mousing to other windows or monitors
• Video content stays in the new position until a shift occurs again, which brings it to its original position
• In some cases (YouTube), video content shows quality loss during this shift

Expected results:

• No change in video quality or shift in video position should have occurred when mousing to other windows or monitors

Note: Bug does not occur in other browsers (Tested on Safari)

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Win32' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Aetheora]

Attachment: Video file.mov

Comment 3

[Aetheora]

Further details:

• Issue occurred after updating from Firefox version 123.01 to version 124.01. Version 124.01 and beta build 125.Beta4 continue to show the issue

• Deactivation of any and all extensions does not resolve the issue

• Build ID 20240325091408

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

Comment 4

[Aetheora]

Update:

• Version 125.0b5 does not resolve the issue

• More testing shows a different way to reproduce the issue.
  When the content's position shifts and quality lowers, clicking on the part of the window the video content is in and leaving the mouse for 1-2 seconds will refocus it to a higher visual quality (without changing resolution). Moving the mouse afterwards will bring it back to the lower visual quality.
  This also occurs when moving the mouse to other programs outside of the browser on the same screen, showing that the issue is not necessarily tied to moving the mouse to other monitors

Comment 5

[Karl Tomlinson (:karlt)]

Thank you for the report.
Would you be able to use https://mozilla.github.io/mozregression/, please, to narrow down what triggered the change in behavior, please?

Comment 6

[Aetheora]

(In reply to Karl Tomlinson (:karlt) from comment #5)

Thank you for the report.
Would you be able to use https://mozilla.github.io/mozregression/, please, to narrow down what triggered the change in behavior, please?

After a ton of build testing with Mozregression, the bisection ended with this build range and comment attached.

2024-03-28T10:43:40.925000: INFO : Narrowed integration regression window from [26f5a6fb, 5da1e842] (3 builds) to [dd2a416c, 5da1e842] (2 builds) (~1 steps left)
2024-03-28T10:43:40.935000: DEBUG : Starting merge handling...
2024-03-28T10:43:40.935000: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=5da1e842ef70c74d8ed72128e460f75b633fae95&full=1
2024-03-28T10:43:40.935000: DEBUG : redo: attempt 1/3
2024-03-28T10:43:40.936000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/integration/autoland/json-pushes?changeset=5da1e842ef70c74d8ed72128e460f75b633fae95&full=1',), kwargs: {}, attempt #1
2024-03-28T10:43:40.962000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org
2024-03-28T10:43:43.132000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=5da1e842ef70c74d8ed72128e460f75b633fae95&full=1 HTTP/1.1" 200 None
2024-03-28T10:43:43.316000: DEBUG : Found commit message:
Bug 1839425: Use AVSampleBufferDisplayLayer for windowed video. r=mstange

Prior to this patch, windowed video was presented in
a AVSampleBufferDisplayLayer only when it was detected to be HDR or DRM
video. This patch allows the use of that specialized video layer for
windowed video as long as the gfx.core-animation.specialize-video pref
is set. This might slightly increase the power consumption of windowed
video, though likely not enough to affect user experience.

Differential Revision: https://phabricator.services.mozilla.com/D199286

Comment 7

[Aetheora]

Now that I had a chance to mess about with things, I went into the about:config and turned the gfx.core-animation.specialize-video preference to False. After some light testing, it seems to have resolved the issue, so this patch mentioned above in what was changed is likely the cause of the problem.
I'll post again if anything changes regarding this

Comment 8

[Karl Tomlinson (:karlt)]

That's very helpful, thank you.

Comment 9

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

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

:bradwerth, since you are the author of the regressor, bug 1839425, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 10

[Brad Werth [:bradwerth]]

Thanks for filing. This is correctly attributed to Bug 1839425 -- the switch to use AVSampleBufferDisplayLayer for all video surfaces -- but it is also due to WebRender choosing to flatten video content into tiles in some circumstances. The effect we are seeing is when WR has flattened video (generally reducing quality a bit) and then is allowing the video to be in its own layer (increasing quality). And somehow this also involves a subpixel shift. So the fix will be getting WebRender to consistently allow the video to remain on its own layer.

Comment 11

[Donal Meehan [:dmeehan]]

Setting Fx125 and Fx126 to Fixed since the regressor Bug 1839425 was backed out of central and beta