526784 - a transition that reverses a currently running transition happens too quickly

Status: RESOLVED INVALID

(Core :: CSS Parsing and Computation, defect, P2)

Description

[d]

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?

Comment 1

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

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.

Comment 2

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I probably need to bring this up on www-style.

Comment 3

[Simon Fraser [no longer active]]

You should. WebKit doesn't have special reversing behavior, but we've discussed it.

Comment 4

[d]

So, it's been quite a while since this was brought up, has the discussion come to any conclusion (or is it "dead"?)?

Comment 5

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

There's been ongoing discussion on www-style.

Comment 6

[Damon Sicore (:damons)]

Bumping this to beta2 per beta re-triage with dbaron.  If this should indeed block beta1, please re-nom.

Comment 7

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Note that if I stick with ComputeDistance here I should have tests that really exercise it (and would catch bug 576761, for example).

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

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?

Comment 9

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: patch

I've had this in my tree for ages; I think we should probably just do it.

Comment 10

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

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

Comment 11

[Dão Gottwald [:dao]]

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

Comment 12

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

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

Comment 13

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

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.