Bug 92591

This is resolved by the patch on WKBug 95117

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

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

Created attachment 179781 [details] Patch

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

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

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

Created attachment 179799 [details] Patch

Comment on attachment 179799 [details] Patch Great!

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

Created attachment 179824 [details] Patch

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

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

Created attachment 180456 [details] Patch

Created attachment 180466 [details] Patch

Created attachment 180471 [details] Patch

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.

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

Created attachment 181041 [details] Patch

Comment on attachment 181041 [details] Patch Clearing flags on attachment: 181041 Committed r138632: <http://trac.webkit.org/changeset/138632>

All reviewed patches have been landed. Closing bug.

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]

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

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

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

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

(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?