Setting overflow on a node aborts its children's transitions

RESOLVED DUPLICATE of bug 625289

Status

()

defect
RESOLVED DUPLICATE of bug 625289
7 years ago
6 years ago

People

(Reporter: ttaubert, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Posted file Testcase
If we change the parent container's overflow property and start a CSS transition in one of its child nodes the transition is immediately aborted (or maybe not started at all). I don't really have a clue what's going on but I prepared a test case:

box 1) Does not touch the container's overflow property before toggling an opacity transition in the child.

box 2) Changes the container's overflow property and starts a transition.

Results:

(1) is smooth and actually executes a transition whereas (2) just switches opacity immediately.
Hmm.  This is odd.  I thought we stored the props on the node so that transitions would survive reframes... David?
(Reporter)

Updated

7 years ago
No longer blocks: 716538

Comment 2

7 years ago
I'm seeing this bug too. I am sorry I have no new information. Curious if anyone has discovered a workaround until the bug gets fixed.

Thanks :)
Duplicate of this bug: 741546

Comment 4

6 years ago
(In reply to Johnny Benson from comment #2)
> I'm seeing this bug too. I am sorry I have no new information. Curious if
> anyone has discovered a workaround until the bug gets fixed.

A potential workaround would be move those two actions apart via setTimeout.

1. set overflow
2. delay via setTimeout
3. perform the transition

Live demo: http://jsfiddle.net/simevidas/4CF8e/

A 50ms delay seems to work fine. However, a zero-timeout does not work.
Flags: needinfo?(dbaron)

Comment 5

6 years ago
I forgot to mention, the above live demo is based on the testcase attached at the beginning of this thread. I've merely wrapped the second statement inside a setTimeout. Now, the second box also performs a transition.
(In reply to Boris Zbarsky [:bz] from comment #1)
> Hmm.  This is odd.  I thought we stored the props on the node so that
> transitions would survive reframes... David?

That doesn't help if the change that would start the transition is simultaneous with the one that causes the reframe.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Flags: needinfo?(dbaron)
Resolution: --- → DUPLICATE
Duplicate of bug: 625289
You need to log in before you can comment on or make changes to this bug.