Re: [blink-dev] Request for Deprecation Trial: Deprecate Mutation Events

[Mason Freed]

On Sat, Feb 10, 2024 at 5:39 AM Daniel Bratell  wrote:

> Just thinking about possible use cases for mutation events, do you know
> what the browser extension situation is? Those might have legitimate reason
> to react to page changes and maybe some of them use the old events?
>
> That's a good question, and I don't have a great answer. Except perhaps to
say that I would hope MutationObserver should be able to handle any such
reactions in the same way that an open web site would. Do you have a reason
to think extensions specifically need synchronous events for mutations?

Thanks,
Mason


> /Daniel
> On 2024-02-09 21:35, Mason Freed wrote:
>
>
> On Wed, Feb 7, 2024 at 6:52 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>> LGTM to run a deprecation trial M124-M134 inclusive.
>>
>
> Thanks!
>
>>
>> May our mutations no longer be eventful!!
>>
>
> 
>
>
>> On Wed, Feb 7, 2024 at 3:50 PM Mason Freed  wrote:
>>
>>>
>>>
>>> On Wed, Feb 7, 2024 at 6:06 AM Yoav Weiss (@Shopify) <
>>> yoavwe...@chromium.org> wrote:
>>>
 Just to clarify - this intent is asking to start a deprecation trial
 for mutation events in 124 and ending it in 134, but you'd send a separate
 intent on the actual removal of mutation events?

>>>
>>> Yes, that’s correct. Here’s the request for deprecation thread:
>>>
>>>
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/qDsKRU-cQ_4/m/P_iXWapTBgAJ
>>>
>>> And I’ll send a request for removal closer to 126.
>>>
>>> Thanks,
>>> Mason
>>>
>>>
>>>
 On Tue, Feb 6, 2024 at 5:12 PM Mason Freed  wrote:

>
>
> On Tue, Feb 6, 2024 at 3:38 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>>
>> Note that them shipping 2.0 and everyone upgrading to 2.0 are not the
>> same thing, and is unlikely to happen at the same time..
>>
>
> Agreed for sure. That’s why I’ve been trying to get them to confirm
> exactly what functionality will be broken. I can’t see any breakage 
> myself.
>
> What would breakage look like? Are we expecting JS to be borked
>>> entirely? Or do we expect the events to stop firing, resulting in 
>>> hopefully
>>> smaller and less-visible breakage?
>>>
>>
> No there shouldn’t be any exceptions thrown, so the JS should be fine.
> It’s just that those events will not be fired. The breakage, whatever it
> is, is so small that I’ve yet been able to notice it. That’s not to say
> there isn’t risk - there surely is. Just that I’m hopeful.
>
> Thanks,
> Mason
>
>
>
>>>
>>>
>>>

>
>>  The npm package you listed, for example, would use the actual
>> events if available, so sites using that polyfill would also count 
>> towards
>> the event usage if the browser supports those even though that's 
>> "safe",
>> right?
>>
>
> This is an excellent point that I hadn't thought of. I'm going to
> modify the polyfill right now to *always* run. That way polyfilled 
> usage
> will no longer be counted. I'm used to writing polyfills for features 
> that
> are getting *added*, where you want to avoid using the polyfill when 
> the
> feature is supported. This is the opposite.
>
> Thanks,
> Mason
>
>
>
>>>
>>> *Gecko*: Positive (
>>> https://github.com/mozilla/standards-positions/issues/807)
>>> "very strong positive position"
>>>
>>> *WebKit*: No signal (
>>> https://github.com/WebKit/standards-positions/issues/192)
>>>
>>> *Web developers*: No signals
>>>
>>> *Other signals*:
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs,
>>> such that it has potentially high risk for Android WebView-based
>>> applications?
>>>
>>> None
>>>
>>>
>>> Goals for experimentation
>>>
>>> Ongoing technical constraints
>>>
>>> Debuggability
>>>
>>> Will this feature be supported on all six Blink platforms
>>> (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
>>> Yes
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ? No
>>>
>>> Flag name on chrome://flags
>>>
>>> Finch feature name None
>>>
>>> Non-finch justification None
>>>
>>> Requires code in //chrome? False
>>>
>>> Tracking bug https://crbug.com/1446498
>>>
>>> Estimated milestones
>>> Shipping on desktop 115
>>> OriginTrial desktop last 134
>>> 

Re: [blink-dev] Intent to Ship: Shadow root clonable attribute

[Mason Freed]

On Fri, Feb 16, 2024 at 6:30 AM Mike Taylor  wrote:

> LGTM1 to ship (see below).
>
Thanks!

> It looks like Safari has only shipped to Beta...
>

Yes, this was a recent consensus/spec, so it hasn't made it all the way to
stable yet.

>
> *Gecko*: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1868428)
> Shipping soon
>
> ...but this has also been in Firefox Nightly and Beta, shipping to Stable
> in 123  (on Feb
> 20). Obvious breakage tends to surface in Firefox Nightly pretty quickly.
> Mozilla shipping 2 months before us will also allow us to get a sense of
> possible breakage before we hit the stable channel.
>
Ahh, thanks for checking on this. I agree that should help.

> I think the risk is non-zero, but likely very, very low - so thanks for
> rolling this out slowly and being willing to turn it off if you discover
> significant issues that can't be quickly resolved via outreach.
>
Thanks! Will do.

Thanks,
Mason


>
> *WebKit*: Shipped/Shipping (
> https://developer.apple.com/documentation/safari-release-notes/safari-17_4-release-notes#Web-API
> )
>
> *Web developers*: No signals
>
> *Other signals*:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Debuggability
>
> None
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)? Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ? Yes
>
> https://wpt.fyi/results/shadow-dom/shadow-root-clonable.html
>
>
> Flag name on chrome://flags ShadowRootClonable
>
> Finch feature name ShadowRootClonable
>
> Requires code in //chrome? False
>
> Tracking bug https://crbug.com/1510466
>
> Estimated milestones
> Shipping on desktop 124
> Shipping on Android 124
> Shipping on WebView 124
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project for the feature specification) whose resolution may
> introduce web compat/interop risk (e.g., changing to naming or structure of
> the API in a non-backward-compatible way).
> None
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5161435196030976
>
> Links to previous Intent discussions Intent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDiPDiSgLRpcW8Q%3DhYTrt%3Dgp%2B%2B6eiS21s_TwFEr%2BHamONA%40mail.gmail.com
>
> This intent message was generated by Chrome Platform Status
> .
> --
> 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/CAM%3DNeDjeNTzKD%3DMpiPbi64%2BEq97vnAA1Q%2BfMG--iFCG8N%3DSa9Q%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/CAM%3DNeDhpEru0j03S04%2Bea0LBfFNfRvqZPaRbXS_s3dG8qVza8A%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Remove "window-placement" alias for permission and permission policy "window-management"

[Brad Triebwasser]

Usage for the legacy permission and permission policy are ~0.006
 and
~0.015  (%
page loads) while the new variants are ~1.166
 and
~3.066  (%
page loads) respectively, so the main metric for potential breakage here is
0.006% of page loads. 0.006% seems low in my opinion, but I'm curious if
there is any guidance on a lower target % we should be aiming for prior to
removing this feature.

I separately calculated that the 200 origins make up about 0.0058% of
total origins tracked by UKM (if that's what you're asking), which aligns
with the UMA figures. I also want to note that 50 of those origins are
likely the same (spam?) website (e.g. https://123.com,
https://124.com, https://125.com). You can see examples of this in
the UMA sample data
.

Regards,
Brad

On Thu, Feb 15, 2024 at 12:42 AM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

> 200 origins sounds like a lot. Do you know what %age of page views those
> origins would represent?
>
> On Wed, Feb 14, 2024 at 11:32 PM Brad Triebwasser 
> wrote:
>
>> *tl;dr:* We expect at most 200 origins could break, and only ~30 of
>> those may be legitimately using the API.
>>
>> We do track UMA/UKM for the primary API entrypoint function (
>> GetScreenDetails
>> )
>> which we expect nearly all legitimate usage of the API to use. We see 60
>> unique origins invoking GetScreenDetails, dominated by a handful of
>> origins (which align with the partners we know are using the API).
>>
>> For reference, 2500 unique origins are checking the window-management
>> permission, and 200 unique origins checking the old window-placement
>> permission (82% of those origins are *not *logging any GetScreenDetails
>> calls).
>>
>> As Mike mentioned, the only breakage here would be a site using 
>> navigator.permissions.query({name:
>> 'window-placement'}) without error handling which according to UKM data
>> would be roughly 200 origins (at most 18% of those may be
>> legitimately using the API).
>>
>> I believe 200 unique origins is a relatively low number of potential
>> breakages, especially considering our data strongly suggests a majority of
>> that is fingerprinting.
>>
>> Regards,
>> Brad
>>
>>
>> On Mon, Feb 12, 2024 at 6:27 AM Mike Taylor 
>> wrote:
>>
>>> Agree that the risk feels low... one thing to perhaps check for (if you
>>> have UKM or use counters) is to see if there is any legit usage on sites of
>>> `navigator.permissions.query()` that isn't catching errors, since that will
>>> throw a TypeError and can break a page.
>>> On 2/12/24 9:16 AM, Rick Byers wrote:
>>>
>>> Presumably the risk of legitimate breakage here is bounded by the use of
>>> the Window Management API, right? Are there any UseCounters for the various
>>> Window Management operations? I couldn't find any at a quick glance. I
>>> imagine legitimate usage is dominated by a few sites with an obvious need
>>> (do we have UKM data?), and such sites should always degrade gracefully
>>> without window management capabilities, right?
>>>
>>> My intuition is that the compat risk here should be extremely low, but I
>>> hope we have some data to validate that which isn't tainted by the
>>> fingerprinting usage.
>>>
>>> Rick
>>>
>>>
>>> On Wed, Feb 7, 2024 at 1:59 PM Brad Triebwasser 
>>> wrote:
>>>
 +blink-dev@chromium.org  / Reply All

 Thanks for your feedback, Mike! Recipes inline:
>
> On Tue, Feb 6, 2024 at 9:36 PM Mike Taylor 
> wrote:
>
>> Hi Brad,
>> On 2/6/24 3:49 PM, Brad Triebwasser wrote:
>>
>> Contact emails
>>
>> btri...@chromium.org
>>
>> Explainer
>>
>>
>> https://github.com/w3c/window-management/blob/main/EXPLAINER_spec_and_permission_rename.md
>>
>> Specification
>>
>>
>> https://w3c.github.io/window-management/#api-permission-api-integration
>>
>> Summary
>>
>> Removes the legacy "window-placement" alias for permission and
>> permission policy "window-management". This is a follow-up to
>> https://chromestatus.com/feature/5146352391028736 and corresponding
>> blink-dev PSA
>> .
>> The "window-placement" alias has been showing console deprecation 
>> warnings
>> since M113
>> .
>> We will disable WindowPlacementPermissionAlias
>> 

Re: [blink-dev] Re: Intent to Ship: setHTMLUnsafe and parseHTMLUnsafe

[Joey Arhar]

> Is this the relevant explainer (referenced from the PR below):
https://github.com/WICG/sanitizer-api/blob/main/explainer.md

Yes, as far as I know.

> This seems positive, right?

Whoops, meant to put positive. I updated the chromestatus.

> Both of these look like "Shipped/Shipping", per
https://bit.ly/blink-signals. That status is a little odd, because it
doesn't look like they've actually made it to a stable release, but if I'm
reading the bug trackers right they're both merged, so they're past "In
Development".

Ok, I'll change them to shipped/shipping.

On Thu, Feb 15, 2024 at 9:35 AM Luke  wrote:

> Just to keep everyone up to date, you can disregard my remarks above I've
> landed a patch which addresses the lack of trusted types protection, thanks
> for the quick review Joey.
>
> Regards,
> Luke
>
> On Wednesday, February 14, 2024 at 10:49:23 PM UTC Luke wrote:
>
>> Hi,
>>
>> In it's current form Chromium's implementation of these functions
>> bypasses trusted types protection.
>>
>> The below WPT tests cover this behaviour:
>>
>>
>> https://wpt.fyi/results/trusted-types/block-string-assignment-to-ShadowRoot-setHTMLUnsafe.html?label=experimental=master
>>
>> https://wpt.fyi/results/trusted-types/block-string-assignment-to-Element-setHTMLUnsafe.html?label=experimental=master
>>
>> https://wpt.fyi/results/trusted-types/block-string-assignment-to-Document-parseHTMLUnsafe.html?label=experimental=master
>>
>> This should be addressed before shipping, else it will be an unexpected
>> security regression.
>>
>> On Wednesday, February 14, 2024 at 10:23:01 PM UTC Vladimir Levin wrote:
>>
>>> On Wed, Feb 14, 2024 at 1:53 PM Jeffrey Yasskin 
>>> wrote:
>>>
 Non-API-owner opinions inline:

 On Wed, Feb 14, 2024 at 1:42 PM 'Vladimir Levin' via blink-dev <
 blin...@chromium.org> wrote:

> I just had some clarifying questions
>
> On Wed, Feb 14, 2024 at 1:13 PM Joey Arhar 
> wrote:
>
>> Some additional notes:
>> - This API is tested in the declarative ShadowDOM tests in
>> interop2024, and it is counting against us to not have it enabled by
>> default.
>> - The future sanitization options will be added as an optional second
>> parameter to both methods, so there will not be any compat issues with
>> shipping now.
>>
>> On Wed, Feb 14, 2024 at 1:11 PM Joey Arhar 
>> wrote:
>>
>>> Contact emailsjar...@chromium.org
>>>
>>> ExplainerNone
>>>
>>
> Is this the relevant explainer (referenced from the PR below):
> https://github.com/WICG/sanitizer-api/blob/main/explainer.md
>
>
>>
>>>
>>> Specification
>>> https://html.spec.whatwg.org/C/#unsafe-html-parsing-methods
>>> https://github.com/whatwg/html/pull/9538
>>>
>>> Summary
>>>
>>> The setHTMLUnsafe and parseHTMLUnsafe methods allow Declarative
>>> ShadowDOM to be used from javascript. In the future, they may also get 
>>> new
>>> parameters for sanitization.
>>>
>>>
>>> Blink componentBlink>HTML
>>> 
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot applicable
>>>
>>
> There seems to be consensus within browser vendors that this is a good
> idea, but I'm just wondering why you decided against filing TAG here?
>

 IMO, either Firefox or Safari folks should have filed a TAG review for
 this before they merged their patches. Now that they've merged, I think it
 falls into the "[already specified && already shipped]" exception
 category
 ,
 and it's probably too fixed to ask the TAG to spend time on it.

>>>
>>> (also non-api-owner, but responding anyway): if that is in fact shipping
>>> then I agree that this should be the exception here, thanks.
>>>
>>>

> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> None
>>>
>>>
>>> *Gecko*: No signal (
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1850675)
>>> https://github.com/whatwg/html/pull/9538#issuecomment-1728947778
>>>
>>
> This seems positive, right?
>


> *WebKit*: Positive (https://bugs.webkit.org/show_bug.cgi?id=261143)
>>>
>>
> I'm not sure how to read this properly, but is this a positive signal
> or "shipped/shipping" signal?
>

 Both of these look like "Shipped/Shipping", per
 https://bit.ly/blink-signals. That status is a little odd, because it
 doesn't look like they've actually made it to a stable release, but if I'm
 reading the bug trackers right they're both merged, so they're past "In
 Development".

>>>
>>> Yeah, that's my thought here too. My understanding is that all of the
>>> patches here are merged, but I just wanted to double check in case I'm
>>> misunderstanding 

Re: [blink-dev] Intent to Ship: Zstd Content-Encoding

[Felix Handte]

Exciting! Meta supports shipping Zstd.

We've been running an experiment on our side and have seen positive user 
metrics movement from switching to serving zstd to Chrome traffic.
On Thursday, February 15, 2024 at 2:20:20 PM UTC-5 Mike Taylor wrote:

> LGTM3
> On 2/15/24 1:39 PM, Chris Harrelson wrote:
>
> LGTM2
>
> On Wed, Feb 14, 2024 at 7:11 PM Nidhi Jaju  wrote:
>
>>
>>
>> On Thu, Feb 15, 2024 at 12:50 AM David Benjamin  
>> wrote:
>>
>>> On Wed, Feb 14, 2024 at 9:20 AM Yoav Weiss (@Shopify) <
>>> yoav...@chromium.org> wrote:
>>>
 LGTM1

 On Wednesday, February 14, 2024 at 2:36:10 AM UTC+1 Nidhi Jaju wrote:

 On Wed, Feb 14, 2024 at 2:48 AM James Hartig  
 wrote:

 My employer ran into the window size during our pre-production 
 validation and it was difficult to debug since it was working in cURL, the 
 zstd CLI, and only presented itself on certain URLs. I appreciate Nidhi 
 responding to our issue so quickly and updating Chrome to have a more 
 helpful error message in the future. The Go package we use already updated 
 their default  to 8MB 
 (without any awareness to Chrome's size) which should help future users of 
 that package but there might be other packages out there that might not 
 have a low enough default. The updated Chrome error message will help but 
 only if you run into that error message when testing; which might not if 
 you happen to be testing with small responses. I'm not sure where 
 developers should be looking to be aware of the window size. Does it make 
 sense to mention in the Chrome Status entry? If the spec is updated that 
 might be good enough but I just wanted to discuss other avenues that might 
 be more developer-aware.


 Thank you, I've included these details about the window size limits 
 under the "Interoperability and Compatibility Risks" section in the 
 ChromeStatus entry. 

 On Tue, Feb 13, 2024 at 6:43 PM Yoav Weiss (@Shopify) <
 yoav...@chromium.org> wrote:



 On Tue, Feb 13, 2024 at 9:29 AM Nidhi Jaju  
 wrote:



 On Tue, Feb 13, 2024 at 4:18 PM Yoav Weiss (@Shopify) <
 yoav...@chromium.org> wrote:

 Thanks for working on this!! This is extremely exciting!

 On Tue, Feb 13, 2024 at 1:11 AM Nidhi Jaju  
 wrote:

 Contact emails 

 nidh...@chromium.org

 Explainer 

 https://docs.google.com/document/d/1aDyUw4mAzRdLyZyXpVgWvO-
 eLpc4ERz7I_7VDIPo9Hc/edit?usp=sharing

 Specification 

 https://datatracker.ietf.org/doc/html/rfc8878

 Design docs 

 https://docs.google.com/document/d/14dbzMpsYPfkefAJos124uPrlkvW7j
 yPJhzjujSWws2k/edit?usp=sharing

 Summary 

 Zstandard, or “zstd”, is a data compression mechanism described in 
 RFC8878. It is a fast lossless compression algorithm, targeting real-time 
 compression scenarios at zlib-level and better compression ratios. The 
 "zstd" token was added as an IANA-registered Content-Encoding token as per 
 https://datatracker.ietf.org/doc/html/rfc8878#name-content-encoding. 

 Adding support for "zstd" as a Content-Encoding will help load pages 
 faster and use less bandwidth, and spend less time and CPU/power on 
 compression on our servers, resulting in reduced server costs.

 Blink component 

 Internals>Network 
 

 TAG review 

 https://github.com/w3ctag/design-reviews/issues/930 

 TAG review status 

 Pending

 Risks
 Interoperability and Compatibility 

 Servers that have a broken implementation of zstd might exist, but the 
 risk of this is small. Additionally, middleware and middleboxes like virus 
 checkers that intercept HTTPS connections might not support zstd, but 
 might 
 fail to remove it from the Accept-Encoding header in the request.

 Another known risk is interoperability between clients that support 
 zstd regarding window frame sizes. In Chrome, we limit the window frame 
 size to 8MB to prevent excessive memory usage, but this limit does not 
 exist in curl and when using zstd directly. We have seen very few sites 
 that use a window size larger than 8MB which causes decoding errors, but 
 we 
 have added new net error codes and debugging messages to help them 
 understand what to do in this situation.


 I know we discussed 
 
  
 this at length at the WebPerfWG. 
 Can you summarize developments and/or findings since that discussion on 
 that front?
 Should we expect the default output of CLI tools to be compatible with 

[blink-dev] Intent to Ship: 'priority' HTTP request header

[Patrick Meenan]

Contact emailspmee...@google.com

ExplainerNone

Specificationhttps://datatracker.ietf.org/doc/rfc9218

Summary

This feature adds the 'priority' request header for all HTTP requests with
the priority information for the request at the time that it was sent. RFC
9218 (Extensible Prioritization Scheme for HTTP) defines a 'priority' HTTP
request header to use for signaling request priority to origins (and
intermediaries). It also defines negotiation processes and protocol-level
frames for HTTP/2 and HTTP/3 to carry the same priority information. The
header can only signal the initial priority for a resource when it was
first requested while the frame-based mechanisms allow for modifying the
priority after the fact. The header can operate end-to-end to the origin
servers (and provide a mechanism for the origin to override the priority if
recognized by intermediaries) while the frames are limited to operating on
a link level. This feature is specifically for supporting the header-based
prioritization scheme.


Blink componentBlink>Network


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

None
*Gecko*: Shipped/Shipping
*WebKit*: Shipped/Shipping
*Web developers*: No signals
*Other signals*:

Security

The priority information for a given request is already exposed in HTTP/2
and HTTP/3 in the frame-based priority fields (and weights in HTTP/2). This
moves the same information directly into the headers for HTTP/2 and HTTP/3
only.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

None


Debuggability

The "Priority" header is exposed in both the Dev Tools network panel (in
the Request Headers) and in the Netlog.

Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, ChromeOS, Android, and Android WebView)?Yes

Is this feature fully tested by web-platform-tests

?No

Request priorities are not standardized so the values themselves are not
testable across browsers. The presence of the header at all requires HTTP/3
(or HTTP/2 for Chrome) which is not something that is currently possible to
test in WPT.

Flag name on chrome://flags

Finch feature namePriorityHeader

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1404785

MeasurementN/A

Availability expectationFeature will be available on all browsers once
Chromium ships (already available in Safari and Firefox).

Adoption expectationN/A

Adoption planN/A

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open
source repository and its open-source dependencies to function?
None

Estimated milestones
Shipping on desktop 124
OriginTrial desktop last 122
OriginTrial desktop first 120
DevTrial on desktop 119
Shipping on Android 124
OriginTrial Android last 122
OriginTrial Android first 120
DevTrial on Android 119
Shipping on WebView 124
OriginTrial webView last 122
OriginTrial webView first 120

Anticipated spec changes

None

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5109106573049856

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/eEeDzwtw5v0 Intent
to Experiment:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w5KJijit8ObBhWKzCnLjro7jSfAsxfPPZ66NwmTO_ZT%3Dg%40mail.gmail.com


This intent message was generated by Chrome Platform Status
.

-- 
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/CAPq58w47qFBfznZH%3Ditr7-whRu3irmCTUxrpxKM5ySA%3DoA-yOg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Shadow root clonable attribute

[Mike Taylor]

LGTM1 to ship (see below).

On 2/15/24 6:12 PM, Mason Freed wrote:




Contact emails

mas...@chromium.org


Explainer

None


Specification

https://dom.spec.whatwg.org/#shadowroot-clonable


Summary

This enables individual control over whether a shadow root is clonable 
(via standard platform cloning commands such as `cloneNode()`). 
Imperative shadow roots can now be controlled via a parameter to 
`attachShadow({clonable:true})`. Declarative shadow roots can be 
controlled via a new attribute, `shadowrootclonable>`.




Blink component

Blink>DOM>ShadowDOM 




Search tags

declarative shadow dom 




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

This is a slight change in behavior, which poses a very small compat 
risk. Prior to this feature, declarative shadow roots within 
`` elements would get automatically cloned. With the change, 
only shadow roots that are explicitly set to `clonable` will be 
cloned. I believe the usage of the "inside-template" behavior before 
was minimal, so the risk should be low. Safari already shipped the new 
behavior, reducing the risk. I plan to enable this functionality 
slowly and monitor for breakage and bug reports.



It looks like Safari has only shipped to Beta...



/Gecko/: Positive 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1868428) Shipping soon


...but this has also been in Firefox Nightly and Beta, shipping to 
Stable in 123  (on 
Feb 20). Obvious breakage tends to surface in Firefox Nightly pretty 
quickly. Mozilla shipping 2 months before us will also allow us to get a 
sense of possible breakage before we hit the stable channel.


I think the risk is non-zero, but likely very, very low - so thanks for 
rolling this out slowly and being willing to turn it off if you discover 
significant issues that can't be quickly resolved via outreach.




/WebKit/: Shipped/Shipping 
(https://developer.apple.com/documentation/safari-release-notes/safari-17_4-release-notes#Web-API)


/Web developers/: No signals

/Other signals/:


WebView application risks

Does this intent deprecate or change behavior of existing APIs, such 
that it has potentially high risk for Android WebView-based applications?


None



Debuggability

None



Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes


Is this feature fully tested by web-platform-tests

?

Yes

https://wpt.fyi/results/shadow-dom/shadow-root-clonable.html



Flag name on chrome://flags

ShadowRootClonable


Finch feature name

ShadowRootClonable


Requires code in //chrome?

False


Tracking bug

https://crbug.com/1510466


Estimated milestones

Shipping on desktop 124

Shipping on Android 124

Shipping on WebView 124



Anticipated spec changes

Open questions about a feature may be a source of future web compat or 
interop issues. Please list open issues (e.g. links to known github 
issues in the project for the feature specification) whose resolution 
may introduce web compat/interop risk (e.g., changing to naming or 
structure of the API in a non-backward-compatible way).


None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5161435196030976


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDiPDiSgLRpcW8Q%3DhYTrt%3Dgp%2B%2B6eiS21s_TwFEr%2BHamONA%40mail.gmail.com


This intent message was generated by Chrome Platform Status 
.

--
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/CAM%3DNeDjeNTzKD%3DMpiPbi64%2BEq97vnAA1Q%2BfMG--iFCG8N%3DSa9Q%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/9ad627f6-da88-492e-91ed-8ab6697dccac%40chromium.org.

Re: [blink-dev] Intent to Ship: CSS picture-in-picture display mode

[Mike Taylor]

LGTM3

On 2/16/24 6:21 AM, Manuel Rego Casasnovas wrote:

Thanks for adding the test. LGTM2.

Cheers,
  Rego

On 14/02/2024 13:15, 'François Beaufort' via blink-dev wrote:


On Wed, Feb 14, 2024 at 10:48 AM Manuel Rego Casasnovas 
mailto:r...@igalia.com>> wrote:




    On 14/02/2024 10:46, François Beaufort wrote:
 >
 >
 > On Wed, Feb 14, 2024 at 10:43 AM Manuel Rego Casasnovas
    mailto:r...@igalia.com>
 > >> wrote:
 >
 >     Hi,
 >
 >     On 13/02/2024 11:13, 'François Beaufort' via blink-dev wrote:
 >      >
 >      >         Is this feature fully tested by web-platform-tests
 >      >
 > 
  
>>? 


 >      >
 >      > Yes
 >      >
 >      > https://wpt.fyi/results/css/mediaqueries/display-mode.html

 >  >
 >      >

 >  >>
 >      > https://wpt.live/css/mediaqueries/display-mode.html
    
 >  >
 >      > 
 >  >>
 >
 >     Is this only testing the parsing of the new value?
 >
 >
 > These ones only do that.
 >
 > We have chromium browser tests for this at
 >
https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/picture_in_picture/document_picture_in_picture_window_controller_browsertest.cc;l=781;drc=feec59141dfbef0543100614b568f2b8f7e71af1 
 
> 



    Is there any WPT limitation preventing us for testing this there? 
If so

    we should report a WPT issue.

    Having behavioral tests in WPT is always useful to ensure
    interoperability in the future.


I'm adding tests in WPT as suggested.
See 
https://chromium-review.googlesource.com/c/chromium/src/+/5290634/3/third_party/blink/web_tests/external/wpt/document-picture-in-picture/display-mode.https.html 
 



Thank you for catching!


    Cheers,
    Rego

--
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/CAPpwU5%2B-ajZwj01sZ3TOHADOwFd04FLoF0Zk7bF4Ow--riK6OA%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/56a73400-0299-473c-a872-3099e180ac17%40chromium.org.

Re: [blink-dev] Intent to Ship: CSS picture-in-picture display mode

[Manuel Rego Casasnovas]

Thanks for adding the test. LGTM2.

Cheers,
  Rego

On 14/02/2024 13:15, 'François Beaufort' via blink-dev wrote:


On Wed, Feb 14, 2024 at 10:48 AM Manuel Rego Casasnovas > wrote:




On 14/02/2024 10:46, François Beaufort wrote:
 >
 >
 > On Wed, Feb 14, 2024 at 10:43 AM Manuel Rego Casasnovas
mailto:r...@igalia.com>
 > >> wrote:
 >
 >     Hi,
 >
 >     On 13/02/2024 11:13, 'François Beaufort' via blink-dev wrote:
 >      >
 >      >         Is this feature fully tested by web-platform-tests
 >      >
 > 
   >>?

 >      >
 >      > Yes
 >      >
 >      > https://wpt.fyi/results/css/mediaqueries/display-mode.html

 >     >
 >      >

 >     >>
 >      > https://wpt.live/css/mediaqueries/display-mode.html

 >     >
 >      > 
 >     >>
 >
 >     Is this only testing the parsing of the new value?
 >
 >
 > These ones only do that.
 >
 > We have chromium browser tests for this at
 >

https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/picture_in_picture/document_picture_in_picture_window_controller_browsertest.cc;l=781;drc=feec59141dfbef0543100614b568f2b8f7e71af1
 

 
>

Is there any WPT limitation preventing us for testing this there? If so
we should report a WPT issue.

Having behavioral tests in WPT is always useful to ensure
interoperability in the future.


I'm adding tests in WPT as suggested.
See 
https://chromium-review.googlesource.com/c/chromium/src/+/5290634/3/third_party/blink/web_tests/external/wpt/document-picture-in-picture/display-mode.https.html 


Thank you for catching!


Cheers,
    Rego

--
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/CAPpwU5%2B-ajZwj01sZ3TOHADOwFd04FLoF0Zk7bF4Ow--riK6OA%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/3c37cf6d-0419-4dd6-ac8a-b3cae2dbee2c%40igalia.com.

Re: [blink-dev] Intent to Prototype: CSS functions

[Steinar H. Gunderson]

On Thu, Feb 15, 2024 at 04:59:25PM +, Kevin Babbitt wrote:
> Is there a tracking bug for this feature?

I created one, crbug.com/325504770.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

-- 
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/20240216102858.qn5vtiga53zxwcg7%40sesse.net.

Re: [blink-dev] Re: Intent to Ship: WebSocketStream

[Adam Rice]

>
> Any reason the PR for the spec hasn't landed yet?


We don't have interest from a second implementer yet. As far as I know,
Deno doesn't count for this purpose.

On Fri, 16 Feb 2024 at 03:50, Chris Harrelson  wrote:

> Hi,
>
> Any reason the PR for the spec hasn't landed yet?
>
> On Thu, Feb 15, 2024 at 7:54 AM Mike Taylor 
> wrote:
>
>> Thank you - LGTM1
>> On 2/15/24 7:16 AM, Adam Rice wrote:
>>
>> Thanks Mike,
>>
>> I have requested the approvals. Sorry for the delay, I didn't understand
>> the interface.
>>
>> Adam
>>
>> On Thu, 15 Feb 2024 at 01:39, Mike Taylor  wrote:
>>
>>> Hi Adam,
>>>
>>> Would you mind requesting approvals in the chromestatus entry for the
>>> various review gates?
>>> On 2/8/24 1:30 AM, Adam Rice wrote:
>>>
>>> Unfortunately, no partners were ready when we did the OT, so there was
>>> no feedback at all. However, we have subsequently received private feedback
>>> that the API works well.
>>>
>>> On Thu, 8 Feb 2024 at 04:23, Alex Russell 
>>> wrote:
>>>
 Hey Adam,

 Glad to see this moving forward! Has there been a summary somewhere of
 the OT feedback? Also, we noted that the other reviews were marked as
 unstarted in chromestatus; we will likely hold off voting until those are
 in flight.

 Thanks!

 On Tuesday, February 6, 2024 at 1:43:46 PM UTC-8 Adam Rice wrote:

> Contact emails ri...@chromium.org
>
> Explainer
> https://github.com/ricea/websocketstream-explainer/blob/master/README.md
>
> https://docs.google.com/document/d/1XuxEshh5VYBYm1qRVKordTamCOsR-uGQBCYFcHXP4L0/edit
>
> Specification https://github.com/whatwg/websockets/pull/48
>
> Design docs
> https://web.dev/websocketstream/
>
> Summary
>
> The WebSocket API provides a JavaScript interface to the RFC6455
> WebSocket protocol. While it has served well, it is awkward from an
> ergonomics perspective and is missing the important feature of
> backpressure. The intent of the WebSocketStream API is to resolve these
> deficiencies by integrating WHATWG Streams with the WebSocket API.
>
>
> Blink component Blink>Network>WebSockets
> 
>
> Search tags WebSocket
> , Streams
> , ReadableStream
> ,
> WritableStream 
>
> TAG review https://github.com/w3ctag/design-reviews/issues/394
>
> TAG review status Pending
>
> Chromium Trial Name WebSocketStream
>
> Link to origin trial feedback summary
> https://github.com/ricea/websocketstream-explainer/issues
>
> Origin Trial documentation link
> https://github.com/ricea/websocketstream-explainer/blob/master/README.md
>
> Risks
>
>
> Interoperability and Compatibility
>
> The main risk is that it fails to become an interoperable part of the
> web platform if other browsers do not implement it.
>
>
> *Gecko*: No signal (
> https://github.com/mozilla/standards-positions/issues/970)
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/315)
>
> *Web developers*: No signals
>
> *Other signals*: The Deno runtime has implemented the API:
> https://github.com/denoland/deno/issues/8831
>
> Ergonomics
>
> A major focus of the new API is improving ergonomics over the existing
> WebSocket API.
>
>
> Activation
>
> Everything except for correct backpressure behaviour can be
> polyfilled. Developers who are sensitive to backpressure may prefer to
> feature-detect and fall back to application-level backpressure if the
> feature is not available.
>
>
> Security
>
> Security posture is the same as the existing WebSocket API. The
> WebSocket mojo IPC layer was designed to support backpressure and didn't
> need changes to support the new API.
>
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such
> that it has potentially high risk for Android WebView-based applications?
>
> No specific risk.
>
>
> Debuggability
>
> The necessary probes are included in the code so that existing
> WebSocket debugging facilities work as-is.
>
>
> Will this feature be supported on all six Blink platforms (Windows,
> Mac, Linux, ChromeOS, Android, and Android WebView)? Yes
>
> The feature is easy to support everywhere existing Blink WebSocket
> support exists. Blink WebSockets are supported on every Blink platform.
>
>
> Is this feature fully tested by web-platform-tests
>