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

AudioWorkletNode options serialization is underdefined #1971

Closed
bzbarsky opened this issue Jul 5, 2019 · 6 comments · Fixed by #1996
Closed

AudioWorkletNode options serialization is underdefined #1971

bzbarsky opened this issue Jul 5, 2019 · 6 comments · Fixed by #1996
Assignees
Projects

Comments

@bzbarsky
Copy link

bzbarsky commented Jul 5, 2019

https://webaudio.github.io/web-audio-api/#instantiation-of-AudioWorkletNode-and-AudioWorkletProcessor step 7 says:

Let optionsSerialization be the result of StructuredSerialize(options).

But at this point options is an IDL dictionary (in particular an AudioWorkletNodeOptions), while StructuredSerialize takes as input an IDL value, not an ES value. It's not 100% clear where this ES value should come from. Possible options are:

  1. The original ES object the AudioWorkletNodeOptions was created from. This is not generally available from a dictionary, though.
  2. A new ES object derived by calling https://heycam.github.io/webidl/#dictionary-to-es in the current global.
  3. A new ES object derived by calling https://heycam.github.io/webidl/#dictionary-to-es in a clean new global.

These are all observably different from each other when proxies and getters on Object.prototype are involved.

The spec should really define what happens here, and there should be tests for the behavior.

@karlt

@hoch hoch added this to Untriaged in V1 Jul 11, 2019
@hoch hoch self-assigned this Jul 11, 2019
@hoch
Copy link
Member

hoch commented Jul 12, 2019

What's the difference between the option 2 and 3? How do you specify the target global in the algorithm?

@bzbarsky
Copy link
Author

What's the difference between the option 2 and 3?

Hmm. I guess what we are doing with the resulting object is structured cloning it, not converting it back to a dictionary, so maybe there is no difference in practice, because structured cloning is never affected by the prototype, right? (This claim needs to be carefully double-checked!)

If that's correct, then we can just use https://heycam.github.io/webidl/#dictionary-to-es as-is; it picks up the global from the ambient "current Realm" state, which should be fine here.

@hoch
Copy link
Member

hoch commented Jul 12, 2019

not converting it back to a dictionary

Yes. It's just an intermediate step for the post-messaging.

@hoch hoch moved this from Untriaged to Ready for Editing in V1 Jul 12, 2019
@bzbarsky
Copy link
Author

Note that someone still needs to:

  1. Carefully double-check that structured cloning ignores prototypes.
  2. Add a test where there are relevant properties on Object.prototype, an Object.create(null) is passed as the dictionary, and the test checks that those properties don't pop out on the far end.

@padenot
Copy link
Member

padenot commented Jul 17, 2019

@hoch
Copy link
Member

hoch commented Jul 17, 2019

Thanks for the verification @padenot! Per last 2 comments above, I think we can merge #1996.

V1 automation moved this from Ready for Editing to Done Jul 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
V1
  
Done
Development

Successfully merging a pull request may close this issue.

3 participants