Re: [blink-dev] Intent to Implement and Ship: WritableStream controller AbortSignal

[Nidhi Jaju]

Hi all,

Another update: based on the feedback we received from TAG as previously
mentioned, we decided to remove the abortReason from
WritableStreamDefaultController which was initially proposed, and instead
add an "abort reason" property
 to AbortSignal
which was specced in https://github.com/whatwg/dom/pull/1027. Related to
this on the interface side, the static AbortSignal.abort()
 as well as the
AbortController.abort()
 now take an
optional reason argument. Gecko and WebKit folks and some developers have
also expressed implementer's interest on the PR, and some have gone on to
update their browser implementation/polyfills already.

This was also integrated into the Streams standard in
https://github.com/whatwg/streams/pull/1182. (FYI: the AbortSignal API is
connected to various different standards, so there is also an ongoing
effort to update those affected specs as well here
.)

I would like to resume the intent process based on these updates. Please
let me know if you have any questions or thoughts.

Thank you!

Best regards,
Nidhi

On Thu, Oct 7, 2021 at 1:11 PM Yoav Weiss  wrote:

> After talking to Nidhi offline, we can consider this intent on hold until
> the feedback is addressed.
>
> On Thursday, September 16, 2021 at 4:01:29 AM UTC+2 Nidhi Jaju wrote:
>
>> Hi,
>>
>> Just as an update, we have received some feedback on our TAG review (
>> https://github.com/w3ctag/design-reviews/issues/672#issuecomment-919578419),
>> and hence we are having some discussions and deciding on next best steps
>> accordingly.
>>
>> Best regards,
>> Nidhi
>>
>> On Fri, Sep 3, 2021 at 10:44 AM Nidhi Jaju 
>> wrote:
>>
>>>
>>>
>>> On Fri, Sep 3, 2021 at 4:35 AM Reilly Grant 
>>> wrote:
>>>
 The Web Serial API is also interested in this capability. See the note
 on the abort algorithm when initializing the WritableStream
 .
 Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome
 


 On Thu, Sep 2, 2021 at 12:32 PM Chris Harrelson 
 wrote:

>
>
> On Wed, Sep 1, 2021 at 8:22 PM Nidhi Jaju 
> wrote:
>
>>
>>
>> On Wed, Sep 1, 2021 at 10:54 PM Alex Russell <
>> slightly...@chromium.org> wrote:
>>
>>> Incremental features often benefit from TAG guidance. I'd feel
>>> better if this intent at least cited prior TAG reviews in this area or
>>> filed an FYI (with potential for TAG to request full review).
>>>
>>> If it was covered in a previous review of WritableStreams, that
>>> would also be good to know.
>>>
>>
>> This feature wasn't covered in a previous review of WritableStreams,
>> so I have filed a new TAG review:
>> https://github.com/w3ctag/design-reviews/issues/672
>>
>>
>>>
>>> On Wed, Sep 1, 2021, 2:28 PM Yoav Weiss 
>>> wrote:
>>>


 On Tue, Aug 31, 2021 at 5:14 PM Nidhi Jaju 
 wrote:

> Contact emailsnidhij...@chromium.org, ri...@chromium.org,
> yhir...@chromium.org
>
> Explainer
> https://github.com/whatwg/streams/blob/main/writable-stream-abort-signal-explainer.md
>
>

>
> Specification
> https://streams.spec.whatwg.org/#writablestreamdefaultcontroller-signal
>
> Summary
>
> The streams APIs provide ubiquitous, interoperable primitives for
> creating, composing, and consuming streams of data. This change 
> permits an
> underlying sink to rapidly abort an ongoing write or close when 
> requested
> by the writer.
>
>
> Previously, when writer.abort() was called, a long-running write
> would still have to continue to completion before the stream could be
> aborted. With this change, the write can be aborted immediately.
>

 Am I correct in assuming that the stream developer would have to
 change their code in order for that to happen, and if they won't, the
 current behavior won't change?

>>>
>> Yes, that's correct.
>>
>>

> In addition to being exposed to streams authored in JavaScript,
> this facility will also be used by platform-provided streams such as
> WebTransport.
>
> Blink componentBlink>Network>StreamsAPI
> 
>
> TAG reviewNot needed as this is an incremental improvement to an
> existing feature.
>
> TAG review statusNot applicable
>
> Risks
> 

Re: [blink-dev] Intent to Ship: Sec-CH-UA-Full-Version-List user-agent client hint

[Yoav Weiss]

LGTM1

Thanks for addressing feedback from other vendors on
`Sec-CH-Full-Version`'s design!

On Mon, Nov 22, 2021 at 5:39 PM Victor Tan  wrote:

> Contact emails
>
> victor...@chromium.org, miketa...@chromium.org, jadekess...@chromium.org
>
>
> Specification
>
> https://wicg.github.io/ua-client-hints/#sec-ch-ua-full-version-list
>
>
> Summary
>
> The Sec-CH-UA-Full-Version-List request header field gives a server
> information about the full version for each brand in its brands list.
>
>
> Blink component
>
> Privacy>Fingerprinting
> 
>
>
> Motivation
>
> As raised in UA-CH Issue 196
> ,
> Sec-CH-UA-Full-Version can be considered too tightly bound to the  primary
> brand in the brand list
> , especially
> for embedders. In order to prevent classes of bugs where a site might think
> the fictional “Hamburger” browser is not up to date (because its version
> scheme is different, and lower than Chromium’s), we propose to expose the
> full version of each brand in the brand list, by requesting this new client
> hint.
>
> Here’s what that would look like:
>
> Sec-CH-UA-Full-Version-List: “Hamburger”; v="92.0.902.73", "Chromium";
> v="92.0.4515.131", "?Not:A Browser"; v="3.1.2.0"
>
> Eventually, it will make sense to deprecate and remove
> Sec-CH-UA-Full-Version
> 
> (assuming usage allows us to do so). But we do not intend to do that until
> we ship its replacement.
>
>
> Initial public proposalhttps://github.com/WICG/ua-client-hints/issues/196
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/640
>
>
> TAG review status
>
> Pending (there’s a pre-existing review, and this hint came up in the
> review process as feedback from other browsers, so the TAG is aware of it).
>
>
> RisksInteroperability and CompatibilityThis is a new hint, so it should
> not create compatibility issues.
>
>   Edge: This hint was added to solve a bug (maybe a feature request?)
>  by Edge folks.
>
> Gecko: Non-harmful (
> https://mozilla.github.io/standards-positions/#ua-client-hints)
>
> WebKit: Requested through email
> 
>
> Web developers: No signals
> Debuggability
>
> No special DevTools support needed. It should just work™.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes. https://chromium-review.googlesource.com/c/chromium/src/+/3256910
>
>
> Flag name
>
> UserAgentClientHintFullVersionList
>
> Requires code in //chrome?
>
> False
>
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1249246
>
>
> Launch bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1260418
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5703317813460992
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh4P7FdCmHAA-8b1CH_So%3D2Fur2dZO8SKNetWmEetQ1KcP9_A%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWGKQx9ECJSFwAz9ejvmz36vp%2B1jrCDrYAAcFP_Pk%2BrYg%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: Sec-CH-UA-Full-Version-List user-agent client hint

[Victor Tan]

Hi,
Could you also review and ship this in blink-dev? Thanks!

Bests,
Victor

On Monday, November 22, 2021 at 11:39:47 AM UTC-5 Victor Tan wrote:

> Contact emails
>
> victor...@chromium.org, miketa...@chromium.org, jadekess...@chromium.org
>
>
> Specification
>
> https://wicg.github.io/ua-client-hints/#sec-ch-ua-full-version-list
>
>
> Summary
>
> The Sec-CH-UA-Full-Version-List request header field gives a server 
> information about the full version for each brand in its brands list.
>
>
> Blink component
>
> Privacy>Fingerprinting 
> 
>
>
> Motivation
>
> As raised in UA-CH Issue 196 
> , 
> Sec-CH-UA-Full-Version can be considered too tightly bound to the  primary 
> brand in the brand list 
> , especially 
> for embedders. In order to prevent classes of bugs where a site might think 
> the fictional “Hamburger” browser is not up to date (because its version 
> scheme is different, and lower than Chromium’s), we propose to expose the 
> full version of each brand in the brand list, by requesting this new client 
> hint.
>
> Here’s what that would look like:
>
> Sec-CH-UA-Full-Version-List: “Hamburger”; v="92.0.902.73", "Chromium"; 
> v="92.0.4515.131", "?Not:A Browser"; v="3.1.2.0"
>
> Eventually, it will make sense to deprecate and remove 
> Sec-CH-UA-Full-Version 
>  
> (assuming usage allows us to do so). But we do not intend to do that until 
> we ship its replacement.
>
>
> Initial public proposalhttps://github.com/WICG/ua-client-hints/issues/196
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/640
>
>
> TAG review status
>
> Pending (there’s a pre-existing review, and this hint came up in the 
> review process as feedback from other browsers, so the TAG is aware of it).
>
>
> RisksInteroperability and CompatibilityThis is a new hint, so it should 
> not create compatibility issues.
>
>   Edge: This hint was added to solve a bug (maybe a feature request?) 
>  by Edge folks.
>
> Gecko: Non-harmful (
> https://mozilla.github.io/standards-positions/#ua-client-hints)
>
> WebKit: Requested through email 
> 
>
> Web developers: No signals
> Debuggability
>
> No special DevTools support needed. It should just work™.
>
>
> Is this feature fully tested by web-platform-tests 
> 
> ?
>
> Yes. https://chromium-review.googlesource.com/c/chromium/src/+/3256910 
>
>
> Flag name
>
> UserAgentClientHintFullVersionList
>
> Requires code in //chrome?
>
> False
>
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1249246
>
>
> Launch bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1260418
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5703317813460992
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0695b943-d6d9-462d-ad3c-b8de537ee9b5n%40chromium.org.