Re: [blink-dev] Intent to Ship: BYOB support for Fetch

[Yoav Weiss]

LGTM2

I agree that these patterns are likely to be rare, making this a low risk
endeavor. Please still make sure the flags are working as expected, and
slowly roll this out, just to be on the safe side.

On Tue, Jun 6, 2023 at 8:27 AM Nidhi Jaju  wrote:

>
>
> On Tue, Jun 6, 2023 at 1:01 PM Yoav Weiss  wrote:
>
>>
>>
>> On Monday, June 5, 2023 at 1:13:11 PM UTC+2 Nidhi Jaju wrote:
>>
>> Thank you, Mike and Yoav!
>>
>> I filed a standards position request with WebKit, and they are supportive
>> as well: https://github.com/WebKit/standards-positions/issues/194.
>>
>>
>> That's great!!
>>
>>
>>
>> On Wed, May 31, 2023 at 9:33 PM Yoav Weiss 
>> wrote:
>>
>> Thanks for aligning with Firefox here!
>>
>> On Fri, May 26, 2023 at 5:32 AM Nidhi Jaju 
>> wrote:
>>
>> Contact emailsnidhij...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://fetch.spec.whatwg.org/#http-network-fetch
>>
>> Summary
>>
>> Makes Response.body be a readable byte stream instead of a "default"
>> readable stream. This enables it to be used with bring-your-own-buffer
>> (BYOB) readers, reducing garbage collection overhead and copies.
>>
>> As mentioned in the Activation section below, we plan to ship the
>> ReadableStreamTeeCloneForBranch2 feature first, and then the FetchBYOB
>> feature later.
>> Blink componentBlink>Network>FetchAPI
>> 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Low risk because streams and fetch have already been standardized for a
>> long time. Other browsers have implemented other parts of the standard, and
>> Firefox has already shipped this behavior for many months and others will
>> most likely also adapt this feature as well soon.
>>
>>
>> *Gecko*: Shipped/Shipping (https://github.com/whatwg/
>> fetch/issues/267#issuecomment-1350303670) Already shipped in Firefox in
>> 2022.
>>
>> *WebKit*: Positive (https://github.com/whatwg/fetch/pull/1593) @annevk
>> from Apple approved the PR to update the spec with relevant changes and
>> expressed interest as an implementer on behalf of Apple.
>>
>> *Web developers*: No signals
>>
>> *Other signals*: Deno is also interested in, and somewhat shipped, this
>> behavior (https://github.com/denoland/deno/issues/17386).
>>
>> Activation
>>
>> Currently, to clone a body, we tee the body's stream, but teeing always
>> returns two "default" streams, where the chunks are not cloned for both
>> streams. Making Response.body into a byte stream, will mean that cloning it
>> will result in cloning the chunks for the second stream, which is different
>> behavior. In order to mitigate activation risks, we are splitting this
>> change into two releases. One where the default teeing behavior will also
>> start to clone for the second stream behind the "
>> ReadableStreamTeeCloneForBranch2" feature flag, and then make
>> Response.body a readable byte stream behind the "FetchBYOB" feature flag.
>>
>>
>> Can you help me understand what potential breakage (if any) may look
>> like?
>> How would these 2 behavior changes break developer expectations? What
>> would code that breaks as a result of this look like?
>>
>> The 2 changes are incremental, and will only break developer expectations
>> if there are websites that rely on the output of cloning a request/response
>> to have the same chunks as before or rely on modifying one of the chunks
>> changing the other one.
>>
>> A code sample of where the behavior difference would be observable is:
>> const request = new Request("image.jpg");
>> fetch(request).then((response) => {
>>   const cloned_response = response.clone();
>>
>>   const { value: value1 } = await response.getReader().read();
>>   const { value: value2 } = await cloned_response.getReader().read();
>>
>>   if (value1 === value2) {
>> console.log('old behavior');
>>   } else {
>> console.log('new behavior');
>>   }
>> });
>>
>> In both the old and the new behaviour, the contents of the Uint8Array are
>> the same, so it only makes a practical difference if a script modifies the
>> output.
>>
>>
>> Do we have a sense of an upper bound on potential breakage? e.g. a use
>> counter for fetch response cloning?
>>
>
> There's no use counter for fetch response cloning, but we believe the
> breakage will be extremely low, and may not even be a concern. There's not
> too many realistic scenarios where we might observe a breakage i.e. if the
> stream is input to some other API, for example the Cache API, then the site
> can't control the timing when the chunk will be consumed. If a service
> worker tries modifying a chunk after it has been queued, it is not
> guaranteed whether it will have been read by the Cache API yet or not, and
> so whether the modification makes it into the cache will not be
> deterministic. Hence, it's unlikely a site could be relying on that
> behaviour.
>
>
>>
>>
>> (An explainer that outlined

Re: [blink-dev] Intent to Ship: @scope

[Anders Hartvoll Ruud]

On Tue, Jun 6, 2023 at 4:07 PM Artur Janc  wrote:

> I'm wondering how @scope will interact with :visited (to make sure we
> avoid exposing the visitedness of links as per
> https://dbaron.org/mozilla/visited-privacy)


The exact privacy measures related to :visited/:link (in general) are
unspecified as far as I know. But given how :visited actually works with
selectors/APIs, my take is that without any explicit mention to the
contrary, "@scope (:visited) { .a {} }" is allowed (and would match within
visited links), but we would report the unvisited situation through CSSOM
APIs. In other words, it's privacy-wise equivalent to a ":visited .a"
selector. Note: I filed a blocking crbug.com/1452051
 to ensure
that we don't ship the wrong thing here.

are all links treated as unvisited for the purposes of @scope?
>

Right, if I remember correctly we did that (in spec) with style queries,
e.g. @container style(color:green) would query the "unvisited style". Doing
this for @scope would certainly eliminate privacy issues, but it's perhaps
a bit drastic if we don't have a specific *reason* to do it. Instead we can
ensure that privacy is maintained in a way that's more consistent with
selectors in general, i.e. what I said above.


> On Monday, June 5, 2023 at 11:49:40 PM UTC+2 Chris Harrelson wrote:
>
>> LGTM2!
>>
>> On Mon, Jun 5, 2023 at 1:24 PM 'Miriam Suzanne' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Haha, good to hear - thanks.
>>>
>>> Cheers,
>>> -Miriam
>>> On Jun 2, 2023 at 6:59 AM -0600, Yoav Weiss ,
>>> wrote:
>>>
>>> LGTM1
>>>
>>> This seems like an obvious useful addition with relatively broad
>>> consensus around it. Thanks for working on this!
>>>
>>> On Thu, Jun 1, 2023 at 10:39 AM Anders Hartvoll Ruud <
>>> and...@chromium.org> wrote:
>>>
 Contact emails

 and...@chromium.org

 Explainer

 https://css.oddbird.net/scope/explainer

>>>
>>> +Miriam Suzanne - that's a great explainer!! (and by far the most
>>> stylish one I've ever seen)
>>>
>>>

 Specification

 https://drafts.csswg.org/css-cascade-6/#scope-atrule

 Summary

 Allows authors to scope style rules to a given element. The key
 differences between this and regular descendant combinators are:


-

The scope proximity
 cascade
criterion, which makes it possible to weigh the priority of declarations
according to the distance to a given scoping element.
-

The scoping limit
, which
makes it possible for a rule to apply to elements within a given 
 subtree,
but only until some specified “lower bound”.


 Example:

 

   @scope (.foo) to (.limit) {

 .green { background-color: green; }

   }

 

 

   Green

   

   Not green (within .foo, but below .limit)

   

 

 Not green (not within .foo)

 Authors can also automatically scope the styles to ’s parent
 element by dropping the selector(s) in @scope’s prelude: