1427968 - Flickering playing media.ccc.de videos in fullscreen on macOS

Status: RESOLVED FIXED

(Core :: Web Painting, defect, P2)

Description

[Samael Wang [:freesamael] (away for now)]

Attachment: Screen recording of the flickering

STR:
1. Play https://media.ccc.de/v/34c3-8941-console_security_-_switch/#video&t=9 (or any other videos on that website) on macOS.
2. Click the fullscreen icon.

Actual Result:
Flickering at the top and bottom of the video. Looks like web content overlaps the video. Screen recording attached.

There weren't enough macOS builds for mozregression to narrow down:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0843e4e6cb1d6e32a35ce4d7014bd250c24f74fa&tochange=1a76c0899bc68acd6b77dd1796870eac3fb0f112

git-bisect from there eventually points me to 

Bug 1344971 - Part 5: Share DisplayItemData lookups when we can in FrameLayerBuilder. r=mstange

Comment 1

[Matt Woodrow (:mattwoodrow)]

Attachment: Don't check for the force descend flag when returning the OOFDisplayData

Previously we stored the OutOutFlowDisplayData for all visible frames, regardless of whether they were contained in the dirty rect or not.

In the current state, we only return OutOfFlowDisplayData to callers if we have the force descend into flag, which is true for frames that were both visible and dirty.

The callers behave differently when we don't return the display data (even when the dirty rect on it is empty), so this takes us back to always returning it when we can.

Comment 2

[Miko Mynttinen]

Comment on attachment 8940546 [details] [diff] [review]
Don't check for the force descend flag when returning the OOFDisplayData

Review of attachment 8940546 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/9fc13d9e3092
Don't check for the force descend flag when checking for the presence of OutOfFlowDisplayData. r=miko

Comment 4

[Eliza Balazs [:ebalazs_]]

https://hg.mozilla.org/mozilla-central/rev/9fc13d9e3092

Comment 6

[Catalin Sasca, Desktop Test Engineering [:csasca]]

I tried reproducing this issue on Firefox Nightly 59.0a1 (2018-01-03) under macOS 10.12.6, using the steps from Comment 0, but that webpage uses another video player, on which the issue is not reproducible.

Samael Wang, have you reproduced the issue on a specific version of macOS? Are there any pref changes involved?

Please let me know if you are still able to reproduce the issue.