Closed Bug 526784 Opened 10 years ago Closed 9 years ago
a transition that reverses a currently running transition happens too quickly
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.3a1pre) Gecko/20091105 Minefield/3.7a1pre Build Identifier: While experimenting a bit with CSS transitions in Webkit and Firefox 3.7 I found that the transition seems to be dropped too quickly on :active elements. The testcase, if you run it in both browsers, will probably explain it better. Make a fast click on a menu button and compare the times it takes for it to fade back. Of course, it could be Webkit that does it wrong and they should fix the time. I don't know, but the same behavior in both browsers is important. Reproducible: Always Steps to Reproduce: 1. Open the testcase at http://www.zirro.se/code/testcase/testcase2.html 2. Press a menu button in both Webkit and Firefox 3.7, just a quick click. 3. Does it take the same time for them to restore?
I intentionally made the reversing of transitions that were just partway through happen faster, since otherwise reversing a transition that was only a small portion of the way through would have a very slow transition. I'm not sure the way I did it is optimal, but the behavior seems better to me.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Transitions on :active elements does not last long enough → a transition that reverses a currently running transition happens too quickly
I probably need to bring this up on www-style.
blocking2.0: --- → beta1
You should. WebKit doesn't have special reversing behavior, but we've discussed it.
So, it's been quite a while since this was brought up, has the discussion come to any conclusion (or is it "dead"?)?
There's been ongoing discussion on www-style.
Bumping this to beta2 per beta re-triage with dbaron. If this should indeed block beta1, please re-nom.
blocking2.0: beta1+ → beta2+
Assignee: nobody → dbaron
Note that if I stick with ComputeDistance here I should have tests that really exercise it (and would catch bug 576761, for example).
Moving to betaN, will need to be pulled into one of the beta milestones. David: any estimate of when the spec issue will be resolved in the mailing lists?
blocking2.0: beta2+ → betaN+
I've had this in my tree for ages; I think we should probably just do it.
Comment on attachment 488949 [details] [diff] [review] patch Er, sorry, meant to put this on bug 582379 (though it's related to this as well).
Has the working group made a decision? I'd like to throw in that the current behavior seem intuitive to me and is exactly what we want for the -moz-transition uses in the Firefox UI...
The working group hasn't made a decision. The patch I attached in bug 582379 is intended to preserve the current behavior in a way that's a little more reliable mathematically (and doesn't cause the weird effects in that bug due to accumulation of rounding error), but that only applies to things that are exact reversals (rather than transitions to a different value).
Bug 582379 switched to what I hope will be our final behavior here. In any case, I think this bug, as reported, is invalid, since we do want to shorten reverse transitions.
Status: NEW → RESOLVED
Closed: 9 years ago
Priority: -- → P2
Resolution: --- → INVALID
Target Milestone: --- → mozilla2.0b8
You need to log in before you can comment on or make changes to this bug.