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

REOPENED
Unassigned

Status

()

P3
normal
Rank:
50
REOPENED
3 years ago
a year ago

People

(Reporter: dholbert, Unassigned)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(platform-rel +, firefox45 affected)

Details

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

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
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.
(Reporter)

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

Updated

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]
(Reporter)

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.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(dholbert)
Resolution: --- → INCOMPLETE
(Reporter)

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.
Status: RESOLVED → REOPENED
Flags: needinfo?(dholbert)
Resolution: INCOMPLETE → ---
(Reporter)

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

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

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

Comment 7

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

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

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])
(Reporter)

Comment 10

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

Comment 11

3 years ago
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.
(Reporter)

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

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]

Updated

2 years ago
platform-rel: ? → +

Updated

2 years ago
Rank: 50
You need to log in before you can comment on or make changes to this bug.