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?
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 :)
(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.
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
Resolution: --- → DUPLICATE
Duplicate of bug: 625289
You need to log in before you can comment on or make changes to this bug.