Skip to content
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

Merged
merged 1 commit into from Apr 13, 2018

Conversation

chromium-wpt-export-bot
Copy link
Collaborator

@chromium-wpt-export-bot chromium-wpt-export-bot commented Apr 10, 2018

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}

Copy link
Collaborator

@wpt-pr-bot wpt-pr-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Already reviewed downstream.

@stephenmcgruer
Copy link
Contributor

@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([
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/createIteratble/createIterable/

Copy link
Contributor

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(), () => {
Copy link
Contributor

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.

Copy link
Contributor

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, () => {
Copy link
Contributor

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/

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@birtles
Copy link
Contributor

birtles commented Apr 11, 2018

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

@birtles
Copy link
Contributor

birtles commented Apr 11, 2018

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:

  1. Initialize Si to the result of converting nextItem to an IDL value of type T.

For converting dictionary types we have:

  1. If Type(V) is not Undefined, Null or Object, then throw a TypeError.

So we should update the Web Animations spec to match this and add a test for this case that we don't throw.

Copy link
Contributor

@stephenmcgruer stephenmcgruer left a 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, () => {
Copy link
Contributor

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([
Copy link
Contributor

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(), () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@birtles
Copy link
Contributor

birtles commented Apr 12, 2018

I've updated the spec now so we can drop the comments from this PR.

w3c/csswg-drafts@42dc347

@@ -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
Copy link
Contributor

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@chromium-wpt-export-bot chromium-wpt-export-bot force-pushed the chromium-export-cl-989261 branch 3 times, most recently from 8b685d0 to 0891c1f Compare April 12, 2018 23:47
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}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants