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

Add tests for ArrayBuffer detaching that throws and account for it in prose #1861

Closed
annevk opened this issue May 10, 2019 · 7 comments
Closed
Assignees
Projects
Milestone

Comments

@annevk
Copy link

annevk commented May 10, 2019

As per whatwg/html#4601 DetachArrayBuffer can throw. There should be tests that this is handled adequately for all affected APIs (seem to be at least two from super quick skimming) and prose might need to be adjusted to indicate this is a thing. You might want to look at HTML for how this is handled.

Or perhaps IDL should be updated to handle this better somehow, not sure, but if so, comment at whatwg/webidl#724.

@padenot
Copy link
Member

padenot commented Jun 13, 2019

I've done related work in the past, taking this.

@rtoy
Copy link
Member

rtoy commented Jun 25, 2019

Text needs to be updated for v1. Setting milestone to v1 for that.

@rtoy rtoy added this to the Web Audio V1 milestone Jun 25, 2019
@mdjp mdjp added this to Untriaged in V1 via automation Jun 25, 2019
@mdjp mdjp moved this from Untriaged to In WG Discussion in V1 Jun 25, 2019
@hoch
Copy link
Member

hoch commented Jun 25, 2019

For example, the step 2 of the algorithm for decodeAudioData(audioData, successCallback, errorCallback) we can capture the internal exception for an undetachable array and throw an error in the step 3.

@hoch
Copy link
Member

hoch commented Jun 25, 2019

For the acquiring the content procedure, we don't need to do anything because AudioBuffer's back-end ArrayBuffer is guaranteed to be detachable.

@annevk
Copy link
Author

annevk commented Jun 26, 2019

Guaranteed not to be detachable I take it?

@padenot
Copy link
Member

padenot commented Jun 26, 2019

No, this was correct:

  • an AudioBuffer can only be instantiated using new AudioBuffer(...); or AudioContext.createBuffer(...);, this always allocate a normal ArrayBuffer ;
  • This means that detaching cannot throw: either it's been detached already, and the operation returns false, or it worked, and it returns true.

@padenot
Copy link
Member

padenot commented Jun 28, 2019

Fixed by #1961.

@padenot padenot closed this as completed Jun 28, 2019
V1 automation moved this from In WG Discussion to Done Jun 28, 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

No branches or pull requests

4 participants