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

The AudioBufferSourceNode.prototype.buffer setter doesn't handle null correctly #666

Closed
foolip opened this issue Dec 3, 2015 · 4 comments
Assignees

Comments

@foolip
Copy link
Contributor

foolip commented Dec 3, 2015

https://webaudio.github.io/web-audio-api/#AudioBufferSourceNode

"This attribute can only be set once, or a InvalidStateError must be thrown."

This needs clarification. Setting buffer to null when it already null should arguably do nothing, while trying to set buffer to anything when it is not null should throw InvalidStateError. The way it's written, this should throw:

var source = context.createBufferSource();
source.buffer = null;
source.buffer = null;

And that would make no sense.

@foolip
Copy link
Contributor Author

foolip commented Dec 3, 2015

Always throwing when setting to null would also work, and is effectively what Chrome does.

@padenot
Copy link
Member

padenot commented Dec 9, 2015

The intent was that setting a new AudioBuffer throws, setting it back to null does not throw. Setting any other type throws all the time, setting it to null multiple times works. We need to adjust the prose here.

@padenot padenot self-assigned this Dec 9, 2015
@foolip
Copy link
Contributor Author

foolip commented Dec 10, 2015

Can you spell that out as the steps of an algorithm? I can't make sense of "setting it back to null does not throw" because then you can always change from one buffer to another by first setting it to null.

As implemented in Chromium, the setter always throws if the internal buffer member (what the buffer attribute returns) is not null.

Note that you don't need to spell out "Setting any other type throws all the time" in prose because that's ensured by having AudioBuffer? as the type in the WebIDL block.

@padenot
Copy link
Member

padenot commented Dec 10, 2015

Yes, this will be spelled out as an algorithm.

@joeberkovitz joeberkovitz modified the milestone: Uncommitted Jan 27, 2016
padenot added a commit to padenot/web-audio-api that referenced this issue Mar 1, 2016
@rtoy rtoy closed this as completed in #743 Mar 7, 2016
rtoy added a commit that referenced this issue Mar 7, 2016
…-null

Spell out the algorithm to set AudioBufferSourceNode.buffer.

Fix #666.
hoch pushed a commit to hoch/web-audio-api that referenced this issue Jun 29, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants