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

Status: RESOLVED INCOMPLETE

(Core :: Graphics: Layers, defect, P3)

Description

[Daniel Holbert [:dholbert]]

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

STR:
 1. Install Stylish add-on.
 2. Install this user-style:
    https://userstyles.org/styles/121703/disable-twitch-tv-will-change-hackaround
(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.

ACTUAL RESULTS:
Various parts of the video are repainted every ~second.

EXPECTED RESULTS:
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

[Daniel Holbert [:dholbert]]

(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.)

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

dholbert, can you make a testcase for this? If not, maybe we should ask Alice?

Comment 3

[Daniel Holbert [:dholbert]]

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.

Comment 4

[Daniel Holbert [:dholbert]]

...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.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: 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.

Comment 6

[Daniel Holbert [:dholbert]]

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">

FACTS:
 * 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

[Daniel Holbert [:dholbert]]

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

Comment 8

[Daniel Holbert [:dholbert]]

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

[Daniel Holbert [:dholbert]]

> 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

[Daniel Holbert [:dholbert]]

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

Comment 11

[Daniel Holbert [:dholbert]]

Actually:
 - 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

[Daniel Holbert [:dholbert]]

(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.

Comment 13

[Daniel Holbert [:dholbert]]

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)

Comment 14

[u597032]

Flash is no longer supported