Bug 92591 – Transitions and animations do not apply to CSS ::before and ::after pseudo-elements

• Status: RESOLVED
• Resolution: FIXED
• Component: CSS

Created attachment 155165 [details]
Testcase of transitioning opacity and transform scale of ::after content url() on mouse hover/active tap

Bug 23209 has become a meta bug so this one is just for ::before and ::after pseudo-elements, marked as blocking that bug.

[Elliott Sprehn]

This is resolved by the patch on WKBug 95117

[Simon Fraser (smfr)]

If you had written bug 95117 bugzilla would have linkified it.

[Elliott Sprehn]

Now that Bug 104462 has been landed we can support these by removing the guard logic in AnimationController.cpp

[Elliott Sprehn]

Created attachment 179781 [details]
Patch

[WebKit Review Bot]

Comment on attachment 179781 [details]
Patch

Attachment 179781 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/15377832

New failing tests:
fast/css-generated-content/pseudo-animation.html

[Elliott Sprehn]

(In reply to comment #5)
> (From update of attachment 179781 [details])
> Attachment 179781 [details] did not pass chromium-ews (chromium-xvfb):
> Output: http://queues.webkit.org/results/15377832
> 
> New failing tests:
> fast/css-generated-content/pseudo-animation.html

Hmm, that's weird. I wonder why the test would timeout since it does setTimeout with notifyDone() inside it.

[Elliott Sprehn]

(In reply to comment #6)
> (In reply to comment #5)
> > (From update of attachment 179781 [details] [details])
> > Attachment 179781 [details] [details] did not pass chromium-ews (chromium-xvfb):
> > Output: http://queues.webkit.org/results/15377832
> > 
> > New failing tests:
> > fast/css-generated-content/pseudo-animation.html
> 
> Hmm, that's weird. I wonder why the test would timeout since it does setTimeout with notifyDone() inside it.

Err, woops. I broke the test right before I uploaded. Lets try this again...

[Elliott Sprehn]

Created attachment 179799 [details]
Patch

[Eric Seidel (no email)]

Comment on attachment 179799 [details]
Patch

Great!

[WebKit Review Bot]

Comment on attachment 179799 [details]
Patch

Attachment 179799 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/15361940

New failing tests:
fast/css-generated-content/pseudo-animation.html

[Elliott Sprehn]

Created attachment 179824 [details]
Patch

[Build Bot]

Comment on attachment 179824 [details]
Patch

Attachment 179824 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/15360985

New failing tests:
fast/css-generated-content/pseudo-transition.html
fast/css-generated-content/pseudo-animation.html

[Elliott Sprehn]

(In reply to comment #12)
> (From update of attachment 179824 [details])
> Attachment 179824 [details] did not pass mac-ews (mac):
> Output: http://queues.webkit.org/results/15360985
> 
> New failing tests:
> fast/css-generated-content/pseudo-transition.html
> fast/css-generated-content/pseudo-animation.html

Hmm, it seems this approach to testing the feature isn't going to work because it's too racy in DRT. I think we're going to need to expose the PseudoElement's through Internals and write regular animation style tests.

[Elliott Sprehn]

Created attachment 180456 [details]
Patch

[Elliott Sprehn]

Created attachment 180466 [details]
Patch

[Elliott Sprehn]

Created attachment 180471 [details]
Patch

[Eric Seidel (no email)]

Comment on attachment 180471 [details]
Patch

I'm not sure why an animation and a transition are different, but OK. :)  You might want to ping dino, but LGTM.

[Elliott Sprehn]

(In reply to comment #17)
> (From update of attachment 180471 [details])
> I'm not sure why an animation and a transition are different, but OK. :)  You might want to ping dino, but LGTM.

They're effectively the same thing, but internally they are represented as different things: ImplicitAnimation vs KeyframeAnimation. It doesn't seem there's any reason one should be different than the other for pseudo elements, but it's nice to have tests just in case someone refactors the animation code to try walking around in the DOM or something in the future where PseudoElement's missing nextSibling and previousSibling might matter.

[Elliott Sprehn]

Created attachment 181041 [details]
Patch

[WebKit Review Bot]

Comment on attachment 181041 [details]
Patch

Clearing flags on attachment: 181041

Committed r138632: <http://trac.webkit.org/changeset/138632>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Jussi Kukkonen (jku)]

The tests are failing on EFL, Qt and GTK.

At least on EFL it's because the mid-way (1.0 sec) value is just slightly off: offsetWidth jumps from 20px to 19px at t=0.996 already. This is 100% reproducable.

So the questions are:
 * is the current test correct? I don't have a bezier calculator at hand to
   check what the ease value should be at t=1.0, nor do I know the exact rules of
   rounding...
 * are these just rounding issues we shouldn't care about _in this test_? Can we
   pick a time value that gives the same result for everyone, or use platform
   expected results?

For reference, webkit-efl thinks 20px is the correct value for t=[0.948-0.995]

[Simon Fraser (smfr)]

Are the tests not using the pause API that was added?

[Elliott Sprehn]

(In reply to comment #23)
> Are the tests not using the pause API that was added?

They are, but I check the value for exact equality. On closer inspection of the other animation tests they all use a tolerance. See runAnimationTest or runTransitionTest usage. I think we just need to change the tests to use shouldBeCloseTo and provide a tolerance of 1.

[Simon Fraser (smfr)]

Hm, with the pause API there should be no need for fuzzy equality checking.

[Jussi Kukkonen (jku)]

(In reply to comment #23)
> Are the tests not using the pause API that was added?

Just to make it clear: the results are not flaky. I get exactly the same px value  when testing multiple times with the same time value (even if the results is right at the edge of almost getting rounded to the next pixel).

[Elliott Sprehn]

(In reply to comment #26)
> (In reply to comment #23)
> > Are the tests not using the pause API that was added?
> 
> Just to make it clear: the results are not flaky. I get exactly the same px value  when testing multiple times with the same time value (even if the results is right at the edge of almost getting rounded to the next pixel).

Yeah, this seems like it's subpixel. Perhaps someone who can build EFL/GTK/QT can pick different stop points and change the test so it doesn't land on a subpixel boundary?