Animation.timeline setting miss checking for the type of the param if is AnimationTimeline
Categories
(Core :: DOM: Animation, defect)
Tracking
()
People
(Reporter: zyscoder, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36
Steps to reproduce:
(1) Open a tab and navigate to http://youronlinechoices.com/
(2) Run the following code in the Console of Devtools:
a = new Animation();
a.timeline = {any: "object"};
(3) Then this code would be evaluated successfully without throwing any exception.
Actual results:
This code is evaluated successfully without throwing any exception.
Expected results:
Since {any: "object"} does not match the type of AnimationTimeline, an exception should be thrown as a warning for developers, just like what Chrome and Webkit do.
For Chrome, it throws: VM317:2 Uncaught TypeError: Failed to set the 'timeline' property on 'Animation': Failed to convert value to 'AnimationTimeline'
For Webkit, it throws: TypeError: The Animation.timeline attribute must be an instance of AnimationTimeline
|
||
Comment 1•5 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'DevTools::Console' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Updated•5 years ago
|
|
||
Updated•5 years ago
|
|
||
Comment 2•5 years ago
|
||
Works for me in Firefox 90. I get:
Uncaught TypeError: Animation.timeline setter: Value being assigned does not implement interface AnimationTimeline.
If this is broken in Firefox 88 it's likely an issue with our WebIDL bindings. I don't think we do anything special for timelines.
There shoudn't be any need to navigate to http://youronlinechoices.com/. Opening DevTools in any tab should work. At a glance that page doesn't appear to be doing anything that would affect this.
|
|
||
Comment 4•5 years ago
|
||
Oh, hang on, we haven't enabled the Animation.timeline setter in channels other than Nightly. I don't remember exactly what the situation is but I believe we were waiting for the ScrollTimeline spec to stabilize first in case we needed to change the behavior there. I thought the other vendors agreed on that.
As a result, in non-Nightly channels the timeline attribute is marked readonly and WebIDL seems to suggest that setting a readonly attribute should fail silently (spec ref).
So I think this is best resolved as invalid, since it is doing the right thing as far as I can tell.
|
|
||
Comment 5•5 years ago
|
||
Marking invalid for now. Please re-open if you disagree.
Description
•