Closed
Bug 1004377
Opened 11 years ago
Closed 10 years ago
CSS animations with empty keyframes rule should still dispatch events
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
RESOLVED
FIXED
mozilla33
People
(Reporter: birtles, Assigned: birtles)
References
Details
Attachments
(2 files, 3 obsolete files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
dholbert
:
review+
|
Details | Diff | Splinter Review |
In the attached test case there is a CSS animation with a positive duration and empty keyframes rule. It prints any dispatched start/end events---or it would if we actually dispatched them.
The spec is pretty clear we should dispatch events in this case (although it's contradictory when the duration is zero). Chrome, I notice doesn't dispatch events however.
Originally this was discussed in the thread starting here:
http://lists.w3.org/Archives/Public/www-style/2012Dec/0268.html
where the suggestion had been to not dispatch events when the keyframes rule was empty although I followed up with reasons why I thought we should.
This was later revisited here:
http://lists.w3.org/Archives/Public/www-style/2013Jan/0080.html
where it was decided that we should dispatch events in this case.
The spec is also pretty clear about this:
> Any animation for which both a valid keyframe rule and a non-zero duration
> are defined will run and generate events; this includes animations with empty
> keyframe rules.
(http://dev.w3.org/csswg/css-animations/#events)
Bug 1004365 looks at the case where the duration is zero.
Assignee | ||
Comment 1•10 years ago
|
||
Attachment #8434741 -
Flags: review?(dholbert)
Assignee | ||
Comment 2•10 years ago
|
||
The test here seems a little off. Having to call div.clientTop to trigger style computation and hence event dispatch seems a little odd but I've confirmed that without the code changes the tests fail and with them they pass. Also, I checked that with the standalone test (attachment 8415764 [details]) the events are dispatched as expected.
Assignee | ||
Comment 3•10 years ago
|
||
Fix missing keyframes rule in OMTA test
Attachment #8436601 -
Flags: review?(dholbert)
Assignee | ||
Updated•10 years ago
|
Attachment #8434741 -
Attachment is obsolete: true
Attachment #8434741 -
Flags: review?(dholbert)
Assignee | ||
Comment 4•10 years ago
|
||
Add tests for dynamic modifications making a rule empty and fixes
Assignee | ||
Updated•10 years ago
|
Attachment #8436601 -
Attachment is obsolete: true
Attachment #8436601 -
Flags: review?(dholbert)
Assignee | ||
Comment 5•10 years ago
|
||
Sorry about continuing to change this. This is just a minor tweak so that the time-related checks are grouped together.
Attachment #8436739 -
Flags: review?(dholbert)
Assignee | ||
Updated•10 years ago
|
Attachment #8436683 -
Attachment is obsolete: true
Comment 6•10 years ago
|
||
Comment on attachment 8436739 [details] [diff] [review]
Dispatch events for CSS Animations with empty keyframes rules
Review of attachment 8436739 [details] [diff] [review]:
-----------------------------------------------------------------
Looks good! Just some nits. (I think my comments on test_animations.html all apply to similar code in the _omta version, too.)
r=me with nits addressed.
::: layout/style/nsAnimationManager.cpp
@@ +68,5 @@
> for (uint32_t animIdx = mAnimations.Length(); animIdx-- != 0; ) {
> ElementAnimation* anim = mAnimations[animIdx];
>
> if (anim->mProperties.IsEmpty()) {
> + // Empty keyframes rule.
Maybe add '@'? (so, "@keyframes rule")
Looks like we tend to use the '@' in other documentation, but not a big deal.
@@ +143,1 @@
> for (uint32_t propIdx = 0, propEnd = anim->mProperties.Length();
I don't think we need to bother with any empty-mProperties check here.
All we're doing is bypassing a loop over the contents of mProperties, and that loop will already be a no-op if mProperties is empty. So, unless I'm missing something, let's drop the if-check/continue here.
::: layout/style/test/test_animations.html
@@ +1922,5 @@
> + "end of animation with empty keyframes rule");
> +done_div();
> +
> +// Test with a zero-duration animation
> +new_div("margin-right: 200px; animation: empty 0s 1s both");
Add to this comment: "...and an empty @keyframes rule"
(I think you have other tests that are labeled as testing "zero-duration animation", but the thing that distinguishes this one from those is the combination of that *with* empty @keyframes rule.)
@@ +1946,5 @@
> +findKeyframesRule("nearlyempty").deleteRule("to");
> +is(cs.getPropertyValue("margin-left"), "0px",
> + "margin-left for animation with (now) empty keyframes rule");
> +listen();
> +advance_clock(500);
Might be worth moving the listen() to *before* the "deleteRule" call here, so you can make sure that we don't fire any events from that point up until your final result of that deletion (to check for bogus duplicate "start" or "end")
So, I'm imagining that listen() would shift up, and we'd add a new line like...
check_events([], "shouldn't be any triggered by keyframes-rule emptying");
...right before your final advance_clock() call here.
@@ +1970,5 @@
> +div.clientTop; // Trigger events
> +check_events([{ type: 'animationstart', target: div,
> + animationName: 'empty', elapsedTime: 0,
> + pseudoElement: "" }],
> + "events at end of animation updated to use " +
I think this needs s/at end/at start/, right?
::: layout/style/test/test_animations_omta.html
@@ +1937,5 @@
> + check_events([{ type: 'animationstart', target: gDiv,
> + animationName: 'empty', elapsedTime: 0,
> + pseudoElement: "" }],
> + "events during middle of animation with empty keyframes rule");
> + advance_clock(3000); // Skip to end of animation
Shouldn't this be 1000 instead of 3000? (We use 1000 here in the non-OMTA version.)
Attachment #8436739 -
Flags: review?(dholbert) → review+
Comment 7•10 years ago
|
||
Comment on attachment 8436739 [details] [diff] [review]
Dispatch events for CSS Animations with empty keyframes rules
>To fix both these problems, this patch moves the check for an empty keyframes
>rule until after mNeedsRefreshes is set.
(Assuming you agree with my comment about dropping the empty-keyframes check / "continue", this chunk of the commit message will need updating. [since the check it's talking about will be dropped instead of moved])
Assignee | ||
Comment 8•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/3b9ed7396f9a
Pushed with review feedback addressed and commit message updated.
Comment 9•10 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
You need to log in
before you can comment on or make changes to this bug.
Description
•