1041292 - no transition, when simultaneously setting display away from "none" and changing a transitioned property

Status: RESOLVED DUPLICATE of bug 537143

(Core :: CSS Parsing and Computation, defect)

Description

[noitidart]

Attachment: transition bug.htm

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release)
Build ID: 20140716183446

Steps to reproduce:

I created a modal div, on top of everything, i gave it `transition: opacity 1s`. Initially i have set its style to display:none (in style sheet in header). Then when i want to show it, i set the display to flex, then set the opacity. But opacity just jumps to final without following transition rule.

I had to hack around it, by after setting the display to flex, i had to use settimeout and then use a waitime of 100. In my website, i have lots of elements so i have to use a waittime of 900ms at the minimum! this is too much!



Expected results:

transition rule should be followed

Comment 1

[noitidart]

test case is attached

Comment 2

[noitidart]

for now, my work around is to keep the modal div display at flex, but when opacity is 0 i set pointer-events to none. and when i set opacity to 1 i set pointer-events to auto. pointer-events doesnt seem to have this lag as display in the topic post.

Comment 3

[Daniel Holbert [:dholbert]]

(Note: this is not flex-dependent; this happens when converting from "display:none" to any non-"none" value.)

I'm pretty sure this is the same basic issue as bug 1034220. Basically, since the element is "display:none", the browser doesn't bother computing style of other properties (beyond "display").

Then, the first time we do compute the style (during a style flush after the "display" changes), the opacity has already been set to 1, so there's no reason to start a transition.

You can work around this in a more targeted way by forcibly flushing the element's style, between the display change and the opacity change, as noted at the end of bug 1034220 comment 4.  Basically, just add this before you tweak the opacity:
  window.getComputedStyle(container, "").opacity;

Comment 4

[noitidart]

Hi Daniel thanks doing that getComputedStyle before it works great.

Do you think they'll fix this? Or will the mark it invalid? Because I do lots of documentation on MDN and it's going to be hard for me to explain this in a standards compliant way. I think that even if it takes a 20ms for the display to actually show, then the opacity should pick up from where it should have been at the 20ms mark.

Comment 5

[noitidart]

I read bug 1034220 and it makes sense that it was marked as invalid. As the guy was trying to set the width before the DOM loaded so it was as if he was setting the initial height (so no change detected to do a transition on). I think the average web developer could figure that one out from plain logic.

But this bug, I don't think even an experienced web developer will figure out the solution is to do a `window.getComputedStyle`. I'm sure the experienced guy will figure out that the div is taking some time to render in the DOM though. Which will lead him to the `setTimeout`. But then the issue of how much timeout to use, because on my computer (2004 pentium 4), it takes 900ms, but on someone elses computer that is fast (AMD A10-7850K or Intel i7 4960K) it takes 5ms.

Comment 6

[Boris Zbarsky [:bzbarsky]]

The right answer here is probably to stop abusing transitions for things they were not designed for once http://dev.w3.org/fxtf/web-animations/ is finalized...

Comment 7

[noitidart]

I don't mean to argue I just want help understanding transition abuse so I can avoid it.

What I was trying to acheive was to make my divs (dialogs) appear in the same way the default panels of firefox show. Like when you click the tri-stripe menu button at top right in australis. It has a beutiufl fade in and slide down transition.

I'll definitely read that article, that probably explains how to use transitions right.

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to noitidart from comment #5)
> I read bug 1034220 and it makes sense that it was marked as invalid.
[...]
> But this bug, I don't think [etc]

Right, I think the validness/invalidness of this bug is independent from bug 1034220. I just brought up that bug because I ran across it a few days ago, and I think the same sort of thing is going on under the hood. (we don't have style information computed, at the point where you'd expect a transition to start)  And as a result, the same workaround applies.

This is really a duplicate of bug 537143. (See e.g. bug 601190 which was also marked as a dupe of that one)

> Do you think they'll fix this?

Per the first comment on bug 537143, it sounds like dbaron thinks we should fix it (or thought so in 2009 at least), but it may not be high-priority.

Comment 9

[noitidart]

Thanks man nice find on dbarons topic!