Closed Bug 1326793 Opened 6 years ago Closed 6 years ago

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


(Core :: CSS Parsing and Computation, defect)

Not set





(Reporter: arni2033, Unassigned)



(1 file)

>>>   My Info:   Win7_64, Nightly 49, 32bit, ID 20160526082509
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:
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)
No longer blocks: 1277113
Component: Untriaged → CSS Parsing and Computation
Product: Firefox → Core
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:


(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. = 1;
  // 2. Make the browser recalculate style for that property

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

(Also, I should add that I can reproduce this without e10s)
Not seeing any objections, I'm marking this as invalid. Please reopen if you disagree.
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.