Steps to reproduce:
(1) Open a tab and navigate to any URL;
(2) Run the following code in the Console of Devtools:
b = new Blob();
s = b.stream();
(3) Then this code would be evaluated successfully without throwing any exception.
This code is evaluated successfully without throwing any exception.
As https://docs.w3cub.com/dom/readablestream/getreader says, the getReader method accesses an optional parameter containing a property mode, which takes as its value a DOMString specifying the type of reader to create.
Thus when passing an integer 123 to this API, since 123 is not a dictionary and cannot be converted to a dictionary, an exception should be thrown by Webkit, just like what Chrome and Firefox do.
Evaluating the same code in Chrome and Firefox would throw exceptions:
For Chrome 90.0.4430.212: `VM622:3 Uncaught TypeError: Failed to execute 'getReader' on 'ReadableStream': cannot convert to dictionary.`
For Firefox 89.0b6: `Uncaught TypeError: can't convert 123 to dictionary`
See also 226215 for another bindings bug with dictionary types.
This is not using regular IDL in WebKit so I am deferring to Youenn on this one. It seems getReader() is implemented in JS?
Created attachment 432680 [details]
Created attachment 432693 [details]
Comment on attachment 432693 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=432693&action=review
> + // FIXME: We check for @undefined and null to match Chrome and WPT tests, we should check whether we can remove those checks.
This FIXME is wrong. We are doing this change to match the spec and other browser. The current code is wrong, the new code matches the spec and there shouldn't be a FIXME.
`If Type(esDict) is not Undefined, Null or Object, then throw a TypeError.`
Cf. https://streams.spec.whatwg.org/#rs-class (that says it is a dictionary parameter).
If this code was using WebIDL, we'd be getting correct / standard behavior for free.
Created attachment 432702 [details]
Committed r279472 (239326@main): <https://commits.webkit.org/239326@main>
All reviewed patches have been landed. Closing bug and clearing flags on attachment 432702 [details].