-
Notifications
You must be signed in to change notification settings - Fork 294
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AbortSignal's abort reason downstream integration #1030
Comments
@domenic created a list of affected specs at whatwg/streams#1165 (comment). |
Thanks, added. If someone could file issues for those as a first step that would be appreciated. |
I noticed it in Credential Management (w3c/webappsec-credential-management#176), which you have. Thanks! |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
(FYI: Web Bluetooth was fixed in WebBluetoothCG/web-bluetooth@c7c0901) |
Following on from whatwg/dom#1027, with introduces custom abort reasons, this uses the AbortSignal's abort reason in the ReadableStreamPipeTo function. It also updates WritableStreamAbort to use the reason to signal abort. Closes #1165. Part of whatwg/dom#1030.
I just filed a bug against WebOTP, can you update the tracking comment above? Thanks ❤️ |
I filed a bug for WebNFC at w3c/web-nfc#630. |
FYI: Geolocation Sensor was fixed in w3c/geolocation-sensor#53 and Idle Detection was fixed in WICG/idle-detection#48 There is also an ongoing PR for EyeDropper: WICG/eyedropper-api#25 |
We finally landed the Fetch PR (whatwg/fetch#1343) as well, so I think we can close this issue now :) |
Huge success; great work everyone!! |
I somehow forgot that
AbortSignal
is a pretty popular API these days. There's more than Fetch and Streams to update. For each impacted specification not only do we need to migrate away from the "aborted flag", we also need to make sure they take into account the object's abort reason, in a matter that is appropriate for the API.[=AbortSignal/abort reason=]
w3c/web-locks#86The text was updated successfully, but these errors were encountered: