1326793 - [e10s] CSS transition set by JavaScript in background tab starts only when I switch to that tab

Status: RESOLVED INVALID

(Core :: CSS Parsing and Computation, defect)

Description

[arni2033]

>>>   My Info:   Win7_64, Nightly 49, 32bit, ID 20160526082509
STR_1:
1. Extract attached "testcase 1" <>to a folder with short full name
2. Open the .xht file in a new tab.   If checkbox (selector "#tpToggle") is checked, uncheck it
3. Open devtools -> console, resize devtools to make sure the checkbox is visible. Execute in console:
    tpToggle=document.getElementById("tpToggle");
    setTimeout(function(){tpToggle.checked=true},3000);
4. In less than 3 seconds open new tab.
5. Wait 5 seconds, then switch to the tab opened in Step 2.

AR:  Animation starts only after Step 5
ER:  Animation should be already finished, because it only takes 4 seconds (3s delay, 1s animation)

Comment 1

[arni2033]

Attachment: testcase 1 - bug 1326793.zip

Comment 2

[Brian Birtles (:birtles)]

So what happens is that the script runs after 3s but we don't resolve style for the content in the background tab until it is visible. This is per spec in as far as CSS transitions doesn't define when style changes happen (see [1]) only what happens when they do occur.

I've tested Chrome and Edge and they behave in the same way, i.e. the transition does not run until you make the background tab the foreground tab again. (Edge was hard to test since it resets scroll when you change tabs, but I managed to verify it does the same.)

If you want to force the transition to be generated immediately, you'll need to force a style update. For example, in the code above simply call:

  setTimeout(function(){tpToggle.checked=true;getComputedStyle(tpButton).left},3000);

(I'm exploiting the fact that the button has an ID of tpButton and so is available in the global scope as a variable of that name.)

In general, if you need to ensure transitions are triggered immediately, you need to do:

  // 1. Make change, e.g.
  elem.style.opacity = 1;
  // 2. Make the browser recalculate style for that property
  getComputedStyle(elem).opacity;

(Although in most browsers calling getComputedStyle on any element and then accessing any property, or even just accessing something like elem.clientTop is likely to recalculate all style, the above is probably more robust.)

This is a long-standing issue with transitions with no obvious solutions (except adding an API for triggering specific transitions, but that wouldn't help in this case, I think).

Let me know if you disagree, otherwise I will close this as invalid.

[1] https://drafts.csswg.org/css-transitions/#starting

Comment 3

[Brian Birtles (:birtles)]

(Also, I should add that I can reproduce this without e10s)

Comment 4

[Brian Birtles (:birtles)]

Not seeing any objections, I'm marking this as invalid. Please reopen if you disagree.