Unnecessary repaints with invisible (opacity:0) HTML controls over Twitch.tv flash video (if you disable their will-change hackaround)




3 years ago
a year ago


(Reporter: dholbert, Unassigned)


Dependency tree / graph

Firefox Tracking Flags

(platform-rel +, firefox45 affected)


(Whiteboard: [gfx-noted][platform-rel-Amazon][platform-rel-Twitch], URL)


(1 attachment)



3 years ago
I'm spinning this off of bug 1210899, for the issue that we suggested they hack around with "will-change".

 1. Install Stylish add-on.
 2. Install this user-style:
(ALTERNATELY, if you prefer: just use devtools to find & disable the "will-change" rule on .player-hover at the twitch.tv site below.)

 3. Enable paint flashing. ( nglayout.debug.paint_flashing )

 4. Visit http://www.twitch.tv/summonersinnlive/v/18635199

 5. After the ad plays, watch for repaints on the video area.

Various parts of the video are repainted every ~second.

No such repainting.

The repaints are caused by the video controls, which are inside of an "opacity:0" subtree, which makes it very odd that changes there are triggering repaints...

I previously spun off bug 1211654 with a reduced testcase taken from Twitch, but it seems there's something more going on here, because the fix there (which fixed my testcase) didn't fix this issue on Twitch.

Comment 1

3 years ago
(To be clear, this issue should no longer be an issue for our users, on this site, because the "will-change" hackaround seems to be effective.  I'm filing this bug to cover our underlying bug here, though, so we don't lose track of that.)


3 years ago
Depends on: 1210899
dholbert, can you make a testcase for this? If not, maybe we should ask Alice?
Flags: needinfo?(dholbert)
Whiteboard: [gfx-noted]

Comment 3

3 years ago
Looks like I may have waited too long to circle back to this -- now, I'm seeing continuous invalidation on the whole video area at twitch.tv (regardless of "will-change" / the stylish addon). This is in Nightly 46 & also in release (43), so this behavior-change isn't a recent regression on our end -- they must've changed something on the site.

I'll file a new bug for the new issue, and I guess we can resolve this as INCOMPLETE (since we don't have the ability to reproduce it anymore), with hopes of reopening if we can reproduce again in the future.
Last Resolved: 3 years ago
Flags: needinfo?(dholbert)
Resolution: --- → INCOMPLETE

Comment 4

3 years ago
...odd, now (after a few browser-restarts) I can reproduce the behavior described in comment 0 again, in Nightly at least. (but I'm still seeing the continuous repaints in Release)

Maybe they're A/B testing some different version of the site which is what I hit in comment 3. Anyway, I'll reopen.
Flags: needinfo?(dholbert)
Resolution: INCOMPLETE → ---

Comment 5

3 years ago
Created attachment 8704332 [details]
screencast of this bug

Here's a screencast of this bug, for posterity.

Partway through, I turn off the stylish rule (i.e. I reallow the "will-change" hackaround that Twitch added at our suggestion), and you can see the repaint bug goes away.
Flags: needinfo?(dholbert)

Comment 6

3 years ago
So the two key elements that are interacting here are:
(1) The flash <object> which provides the video content:
<object style="opacity:0" data="http://player.twitch.tv/vendor/TwitchPlayer.e7dec407.swf" type="application/x-shockwave-flash" id="swfobject-0" align="middle" height="100%" width="100%">

(2) The controls div, which has some grandchildren that get their sizes/contents dynamically updated via JS (to update the current time "clock" & slider-position):
<div class="player-hover player-controls-bottom js-controls-bottom">

 * The controls div has "opacity:0", i.e. it's hidden -- and yet, dynamic changes inside of it trigger repaints (most obviously in the clock area at the left, as you can see in the screencast near the blue word "BANS")
 * If I delete the <object> from the DOM using devtools, the paints go away. (and the bug returns if I Ctrl+Z to bring the <object> back.)  (And when the <object> is removed, I can confirm that the controls are still being updated, if I hover the area where the video should be to make them show up.)

Comment 7

3 years ago
(I spun off bug 1237083 for the extremely-rapid repaints in comment 3, fwiw)

Comment 8

3 years ago
OK, here are some simpler (albeit hacky) STR for this bug here:
 1. visit http://homestarrunner.com/
 2. Run the following in console (ctrl+shift+k):

var myDiv = document.createElement("div")
myDiv.setAttribute("id", "editMe");
myDiv.style.opacity = 0;
myDiv.style.height = "30px";
document.body.insertBefore(myDiv, document.body.firstChild);

 3. Now, run the following repeatedly in console:
myDiv.style.background = "gray"

 4. Repeat with other colors if you like.

This background-color-change triggers a repaint of the top strip of the page, despite the fact that myDiv has "opacity:0".

This only seems to happen on pages that have flash content. (I've only tested Twitch & homestarrunner so far; and the issue goes away if I delete their <object>/<embed> elements that reference flash content.)

Comment 9

3 years ago
> 3. Now, run the following repeatedly in console:

(Sorry, ignore "repeatedly" there. That was from an earlier draft of these STR where I was adjusting textContent instead of background [which also triggers the bug])

Comment 10

3 years ago
(my STR in comment 8 assume that you have paint flashing enabled, too, of course)

Comment 11

3 years ago
 - Changes to myDiv.style.background seem to trigger a repaint, regardless of whether flash content exists on the page.
 - Changes to myDiv.innerText *only* trigger a repaint if flash content exists on the page.

Comment 12

3 years ago
(In reply to Daniel Holbert [:dholbert] from comment #11)
>  - Changes to myDiv.style.background seem to trigger a repaint, regardless of whether flash content exists on the page.

I filed bug 1237097 with a reduced testcase for this.

>  - Changes to myDiv.innerText *only* trigger a repaint if flash content exists on the page.

I filed bug 1237102 with a reduced testcase for this.

I'm marking both bugs as dependencies, but I'm pretty sure the latter bug (the plugin-dependent one, with innerText) is the one that we're actually triggering on Twitch in this bug here (when the 'will-change' layerization hackaround is disabled). With any luck, we'll be able to resolve this as FIXED by bug 1237102, or just as a dupe of that bug, once we've got a fix & can confirm that it actually helps here.
Depends on: 1237102, 1237097

Comment 13

2 years ago
Note: the STR in comment 8 still reproduce the bug for me. Also, I think the paint flashing mentioned in bug 1265553 is due to this bug. (see bug 1265553 comment 44)
Blocks: 1265553
platform-rel: --- → ?
Whiteboard: [gfx-noted] → [gfx-noted][platform-rel-Amazon][platform-rel-Twitch]
platform-rel: ? → +
Rank: 50
You need to log in before you can comment on or make changes to this bug.