New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Web Animations: Fix bugs in procedure to process a keyframes argument #10399
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Already reviewed downstream.
d022009
to
a63ba84
Compare
@birtles FYI this is an upstream (Chromium) change, but wanted your input on the test changes I am making. |
const test_error = { name: 'test' }; | ||
const bad_keyframe = { get left() { throw test_error; } }; | ||
assert_throws(bad_keyframe, () => { | ||
new KeyframeEffect(null, createIteratble([ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/createIteratble/createIterable/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
return 42; // Not an object. | ||
}, | ||
}; | ||
assert_throws(new TypeError(), () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this case be just { name: 'TypeError' }
right? For consistency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
test(() => { | ||
const test_error = { name: 'test' }; | ||
const bad_keyframe = { get left() { throw test_error; } }; | ||
assert_throws(bad_keyframe, () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/bad_keyframe/test_error/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
I'm not sure if we should throw when the iterator returns null or undefined. As the spec currently reads we should, but it might be more consistent with regular WebIDL behavior to treat null or undefined as the default {} dictionary value. That's what Firefox does. @heycam Do you happen to know if, from a WebIDL point of view, if we're iterating over a sequence of dictionary objects and the iterator returns null / undefined we should treat it as the default {} dictionary? (I think you wrote this code and I later moved it.) |
Yeah, it looks like we shouldn't throw on null / undefined. In WebIDL when we create a sequence from an iterable we have the step:
For converting dictionary types we have:
So we should update the Web Animations spec to match this and add a test for this case that we don't throw. |
a63ba84
to
5ded871
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ack, filed w3c/csswg-drafts#2533.
test(() => { | ||
const test_error = { name: 'test' }; | ||
const bad_keyframe = { get left() { throw test_error; } }; | ||
assert_throws(bad_keyframe, () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
const test_error = { name: 'test' }; | ||
const bad_keyframe = { get left() { throw test_error; } }; | ||
assert_throws(bad_keyframe, () => { | ||
new KeyframeEffect(null, createIteratble([ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
return 42; // Not an object. | ||
}, | ||
}; | ||
assert_throws(new TypeError(), () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
5ded871
to
04e1278
Compare
I've updated the spec now so we can drop the comments from this PR. |
@@ -319,6 +333,39 @@ | |||
}, 'Reading from a custom iterator that returns a non-object keyframe' | |||
+ ' should throw'); | |||
|
|||
// The following two tests are currently against spec, but instead match what | |||
// we intend the spec to be; see https://github.com/w3c/csswg-drafts/issues/2533 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Specifically, this comment is no longer needed since that issue has been addressed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
8b685d0
to
0891c1f
Compare
There were three minor bugs left in the implementation: - We threw on lists-in-custom-iterators instead of just ignoring them. - We returned all properties on the keyframe rather than just those defined on the keyframe itself (e.g. we would include prototype properties, against spec). - We didn't access the properties in ascending unicode order. Bug: 827573 Change-Id: I213ae5b24e1f35d7f28d16625025122950a6ba88 Reviewed-on: https://chromium-review.googlesource.com/989261 Reviewed-by: Kentaro Hara <haraken@chromium.org> Reviewed-by: Yuki Shiino <yukishiino@chromium.org> Reviewed-by: Robert Flack <flackr@chromium.org> Commit-Queue: Stephen McGruer <smcgruer@chromium.org> Cr-Commit-Position: refs/heads/master@{#550641}
0891c1f
to
f048355
Compare
There were three minor bugs left in the implementation:
defined on the keyframe itself (e.g. we would include prototype
properties, against spec).
Bug: 827573
Change-Id: I213ae5b24e1f35d7f28d16625025122950a6ba88
Reviewed-on: https://chromium-review.googlesource.com/989261
Reviewed-by: Kentaro Hara haraken@chromium.org
Reviewed-by: Yuki Shiino yukishiino@chromium.org
Reviewed-by: Robert Flack flackr@chromium.org
Commit-Queue: Stephen McGruer smcgruer@chromium.org
Cr-Commit-Position: refs/heads/master@{#550641}