Get rid of custom bindings for AudioBufferSourceNode.buffer setter

Get rid of custom bindings for AudioBufferSourceNode.buffer setter

Get rid of custom bindings for AudioBufferSourceNode.buffer setter by
leveraging [StrictTypeChecking] IDL extended attribute and updating
the implementation to throw if the input buffer is NULL or if the
number of channels is too big.

There is no web-exposed behavior change.

R=haraken, kbr
BUG=

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=159490

[Ken Russell (switch to Gerrit), 2013-10-10 22:10:06]

LGTM but please wait for rtoy's review as well.

[Raymond Toy (Google), 2013-10-10 22:40:56]

LGTM with a nit

https://codereview.chromium.org/26883005/diff/1/Source/modules/webaudio/Audio...
File Source/modules/webaudio/AudioBufferSourceNode.cpp (right):

https://codereview.chromium.org/26883005/diff/1/Source/modules/webaudio/Audio...
Source/modules/webaudio/AudioBufferSourceNode.cpp:360:
es.throwTypeError("AudioBuffer unsupported number of channels");
Should this be a DOMException?  And if so, can we have a more informative
message like what was done in https://codereview.chromium.org/24877002/?

[haraken, 2013-10-11 01:09:09]

LGTM. Please address rtoy's comment before landing.

[Inactive, 2013-10-11 14:25:12]

On 2013/10/10 22:40:56, rtoy wrote:
> LGTM with a nit
> 
>
https://codereview.chromium.org/26883005/diff/1/Source/modules/webaudio/Audio...
> File Source/modules/webaudio/AudioBufferSourceNode.cpp (right):
> 
>
https://codereview.chromium.org/26883005/diff/1/Source/modules/webaudio/Audio...
> Source/modules/webaudio/AudioBufferSourceNode.cpp:360:
> es.throwTypeError("AudioBuffer unsupported number of channels");
> Should this be a DOMException?  And if so, can we have a more informative
> message like what was done in https://codereview.chromium.org/24877002/?

Sure, I can improve the error message to match what you used in the other CL.
However, I don't think we should change the exception type in this CL. The point
of this CL is really to get rid of the custom code while maintaining the exact
same web-exposed behavior. I have bad memories mixing refactoring and behavior
changes :)

[Inactive, 2013-10-11 14:27:41]

On 2013/10/11 14:25:12, Chris Dumez wrote:
> On 2013/10/10 22:40:56, rtoy wrote:
> > LGTM with a nit
> > 
> >
>
https://codereview.chromium.org/26883005/diff/1/Source/modules/webaudio/Audio...
> > File Source/modules/webaudio/AudioBufferSourceNode.cpp (right):
> > 
> >
>
https://codereview.chromium.org/26883005/diff/1/Source/modules/webaudio/Audio...
> > Source/modules/webaudio/AudioBufferSourceNode.cpp:360:
> > es.throwTypeError("AudioBuffer unsupported number of channels");
> > Should this be a DOMException?  And if so, can we have a more informative
> > message like what was done in https://codereview.chromium.org/24877002/?
> 
> Sure, I can improve the error message to match what you used in the other CL.
> However, I don't think we should change the exception type in this CL. The
point
> of this CL is really to get rid of the custom code while maintaining the exact
> same web-exposed behavior. I have bad memories mixing refactoring and behavior
> changes :)

I updated the error message but kept the exception type. Please let me know if I
can land as is.

[Raymond Toy (Google), 2013-10-11 17:34:02]

On 2013/10/11 14:27:41, Chris Dumez wrote:
> On 2013/10/11 14:25:12, Chris Dumez wrote:
> > On 2013/10/10 22:40:56, rtoy wrote:
> > > LGTM with a nit
> > > 
> > >
> >
>
https://codereview.chromium.org/26883005/diff/1/Source/modules/webaudio/Audio...
> > > File Source/modules/webaudio/AudioBufferSourceNode.cpp (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/26883005/diff/1/Source/modules/webaudio/Audio...
> > > Source/modules/webaudio/AudioBufferSourceNode.cpp:360:
> > > es.throwTypeError("AudioBuffer unsupported number of channels");
> > > Should this be a DOMException?  And if so, can we have a more informative
> > > message like what was done in https://codereview.chromium.org/24877002/?
> > 
> > Sure, I can improve the error message to match what you used in the other
CL.
> > However, I don't think we should change the exception type in this CL. The
> point
> > of this CL is really to get rid of the custom code while maintaining the
exact
> > same web-exposed behavior. I have bad memories mixing refactoring and
behavior
> > changes :)
> 
> I updated the error message but kept the exception type. Please let me know if
I
> can land as is.

LGTM, but I'm not an OWNER.

[commit-bot: I haz the power, 2013-10-11 18:00:54]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ch.dumez@samsung.com/26883005/10001

[commit-bot: I haz the power, 2013-10-11 22:20:58]

Retried try job too often on win_blink_rel for step(s) webkit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_blink_...

[commit-bot: I haz the power, 2013-10-11 23:21:21]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ch.dumez@samsung.com/26883005/10001

[commit-bot: I haz the power, 2013-10-12 00:24:20]

Change committed as 159490