Bug 217637

Summary: 'parameters' argument to AudioWorkletProcessor.process() is not spec-compliant
Product: WebKit Reporter: Chris Dumez <cdumez>
Component: Web AudioAssignee: Chris Dumez <cdumez>
Status: RESOLVED FIXED    
Severity: Normal CC: cdumez, darin, eric.carlson, ews-watchlist, ggaren, glenn, jer.noble, philipj, saam, sam, sergio, webkit-bug-importer, youennf
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 217058    
Attachments:
Description Flags
Patch
none
Patch none

Description Chris Dumez 2020-10-12 15:10:55 PDT
'parameters' argument to AudioWorkletProcessor.process() is not spec-compliant:
- https://www.w3.org/TR/webaudio/#dom-audioworkletprocessor-process-inputs-outputs-parameters-parameters

Its type should not be a JSMap, as evidenced by how WPT tests use it. Also, as per the specification, if no automation is scheduled during the render quantum, the array may have length 1 with the array element being the constant value of the AudioParam for the render quantum.
Comment 1 Chris Dumez 2020-10-12 15:27:12 PDT
Created attachment 411170 [details]
Patch
Comment 2 Chris Dumez 2020-10-12 15:33:40 PDT
Created attachment 411172 [details]
Patch
Comment 3 Chris Dumez 2020-10-13 12:32:25 PDT
Patch is ready for review.
Comment 4 Darin Adler 2020-10-13 12:54:08 PDT
Comment on attachment 411172 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=411172&action=review

> Source/WebCore/ChangeLog:12
> +        Its type should not be a JS Map, as evidenced by how WPT tests use it. We now pass a generic JS Object,
> +        as Blink is doing.

I understand that the test helped make this clear. Was it also clear in the specification, or do we need to file an issue to ask for it to be made clearer.

> Source/WebCore/ChangeLog:15
> +        Also, as per the specification, if no automation is scheduled during the render quantum, the array may
> +        have length 1 with the array element being the constant value of the AudioParam for the render quantum.

Not sure I understand the word "may" here. Does this mean it "must"?

> Source/WebCore/Modules/webaudio/AudioParamTimeline.cpp:997
> +    auto endFrame = startFrame + AudioUtilities::renderQuantumSize;

What if someone passes a really huge startFrame in, like numeric_limits<size_t>::max()? Should we return true in that case instead of overflowing? Or is that impossible?
Comment 5 Chris Dumez 2020-10-13 13:00:36 PDT
(In reply to Darin Adler from comment #4)
> Comment on attachment 411172 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=411172&action=review
> 
> > Source/WebCore/ChangeLog:12
> > +        Its type should not be a JS Map, as evidenced by how WPT tests use it. We now pass a generic JS Object,
> > +        as Blink is doing.
> 
> I understand that the test helped make this clear. Was it also clear in the
> specification, or do we need to file an issue to ask for it to be made
> clearer.

The specification points to this:
https://infra.spec.whatwg.org/#ordered-map

I wrongly interpreted that as a JS map it seems.

> > Source/WebCore/ChangeLog:15
> > +        Also, as per the specification, if no automation is scheduled during the render quantum, the array may
> > +        have length 1 with the array element being the constant value of the AudioParam for the render quantum.
> 
> Not sure I understand the word "may" here. Does this mean it "must"?

Indeed, while the spec says "MAY", there are web-platform-tests that fail if you don't do it. I think either the tests or the specification should change because they are not in complete agreement.

> 
> > Source/WebCore/Modules/webaudio/AudioParamTimeline.cpp:997
> > +    auto endFrame = startFrame + AudioUtilities::renderQuantumSize;
> 
> What if someone passes a really huge startFrame in, like
> numeric_limits<size_t>::max()? Should we return true in that case instead of
> overflowing? Or is that impossible?
Comment 6 EWS 2020-10-13 13:02:28 PDT
Committed r268414: <https://trac.webkit.org/changeset/268414>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 411172 [details].
Comment 7 Radar WebKit Bug Importer 2020-10-13 13:03:19 PDT
<rdar://problem/70262818>