[Webkit-unassigned] [Bug 227690] New: ReadableStream's pipeTo() and pipeThrough() don't handle options in spec-perfect way

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Jul 5 14:24:44 PDT 2021


            Bug ID: 227690
           Summary: ReadableStream's pipeTo() and pipeThrough() don't
                    handle options in spec-perfect way
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: DOM
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: shvaikalesh at gmail.com

Streams spec for pipeThrough(): https://streams.spec.whatwg.org/#rs-pipe-through
WebIDL spec for dictionary types: https://heycam.github.io/webidl/#es-dictionary
Implementation: https://github.com/WebKit/WebKit/blob/3cd76abcda098f91d46fb0ad42e1eab68b6ddb12/Source/WebCore/Modules/streams/ReadableStream.js#L122

> if (@isReadableStreamLocked(this))
>     throw @makeTypeError("ReadableStream is locked");

While this is the first step of pipeThrough() algorithm, it should happen after all arguments (including `options`) are checked / handled.

> if (options === @undefined)
>     options = { };

This causes properties to queried from Object.prototype; the WebIDL spec doesn't perform [[Get]] for non-objects at all.
@Object. at create(null) may be used instead.

> let signal;
> if ("signal" in options) {
>     signal = options["signal"];

This is observable is options is a Proxy; the WebIDL spec merely compares [[Get]] result with undefined.

> const preventClose = !!options["preventClose"];
> const preventAbort = !!options["preventAbort"];
> const preventCancel = !!options["preventCancel"];

For these 3, lookup order matches the member declaration order of Streams spec.
However, the WebIDL spec requires "lexicographical order"; does it translate to 1) "preventAbort" 2) "preventCancel" 3) "preventClose"?
Either way, `options.signal` should be queried after these 3, which is observable by a userland getter.

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210705/92faeeab/attachment.htm>

More information about the webkit-unassigned mailing list