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

Chris Dumez
Reported 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.
Attachments
Patch (34.89 KB, patch)
2020-10-12 15:27 PDT, Chris Dumez 		no flags
DetailsFormatted DiffDiff
Patch (35.87 KB, patch)
2020-10-12 15:33 PDT, Chris Dumez 		no flags
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Chris Dumez
Comment 1 2020-10-12 15:27:12 PDT
Created attachment 411170 [details] Patch
Chris Dumez
Comment 2 2020-10-12 15:33:40 PDT
Created attachment 411172 [details] Patch
Chris Dumez
Comment 3 2020-10-13 12:32:25 PDT
Patch is ready for review.
Darin Adler
Comment 4 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?
Chris Dumez
Comment 5 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?
EWS
Comment 6 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].
Radar WebKit Bug Importer
Comment 7 2020-10-13 13:03:19 PDT
<rdar://problem/70262818>
Note You need to log in before you can comment on or make changes to this bug.