Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Mike Taylor]

You should be able to see all the various bits for approvals in your 
chromestatus entry now, can you fill them out please?


There have been a few questions/comments about the lack of clarity of 
what "unimportant cross-origin frames" are. What exactly is the 
definition? You mention that Safari has a similar intervention - how 
similar is it? Do we know? I wonder if there is alignment for this 
"unimportant cross-origin frame" concept, if we shouldn't specify that 
somehow.


On 3/15/24 2:58 AM, Zheda Chen wrote:
*Intent to Ship: Add JavaScript timer wake up alignment for 
unimportant cross-origin frames*


Contact emails
zheda.c...@intel.com, fdo...@chromium.org

Specification
https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html

Summary

Align wake ups of JavaScript timers for unimportant cross-origin 
frames. Currently, DOM timers <32ms are all opt-out from AlignWakeUps 
[1] due to performance concerns. This is very conservative and 
actually some unimportant frames are eligible to use JS timer 
alignment. WebKit uses the policy to align DOM timer of non-interacted 
cross origin frames to 30ms. This feature adds JavaScript timer wake 
up alignment for unimportant frames on foreground pages. Unimportant 
frames means they are cross origin, visible but have non-large 
proportion of page’s visible area, and have no user interaction. The 
alignment interval is 32ms. [1] 
https://chromium-review.googlesource.com/c/chromium/src/+/4589092




Blink component
Blink>PerformanceAPIs>Timers 



TAG review
None

TAG review status
Not applicable

Risks


Interoperability and Compatibility

"Other vendors already have interoperable implementation" Safari has a 
similar intervention. DOM timers of non-interacted cross origin frames 
are aligned to 30ms. In Firefox, all DOM timers (both same-origin and 
cross-origin) in foreground pages would be aligned to 16ms. "A mature 
specification in the relevant standards body" This intervention is 
spec-compliant. The spec mentions "the SetTimeout/SetInterval API does 
not guarantee that timers will run exactly on schedule. Delays due to 
CPU load, other tasks, etc, are to be expected. ". The wait length of 
time is implementation-defined, "which is intended to allow user 
agents to pad timeouts as needed to optimize the power usage of the 
device. " 
https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html "A 
shared test suite for that specification" It isn't clear what should 
be tested specifically for this intervention since the spec allows 
waiting for an "implementation-defined" length.




/Gecko/: Shipped/Shipping
In Firefox, all DOM timers of frames (both same origin and cross 
origin) are aligned to 16ms


/WebKit/: Shipped/Shipping
In Safari, DOM timers of non-interacted cross origin frames are 
aligned to 30ms after reaching max nesting level (>=5)


/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

This intervention doesn't require changes to the spec. Timers are 
already covered by Web Platform Tests.




Flag name on chrome://flags
None

Finch feature name
ThrottleUnimportantFrameTimers

Requires code in //chrome?
False

Tracking bug
https://issues.chromium.org/issues/40942028

Launch bug
https://issues.chromium.org/issues/40942028

Estimated milestones
Shipping on desktop
123
DevTrial on desktop
121
Shipping on Android
123
DevTrial on Android
121

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/5106220399853568

Links to previous Intent discussions

This intent message was generated by Chrome Platform Status 
.



On Friday, March 15, 2024 at 6:24:06 AM UTC+8 mike...@chromium.org wrote:

The privacy and security teams review all intents, so requesting
reviews and answering the relevant questionnaires is the best path
forward.

Looking forward to the new I2S - thanks!

On 3/14/24 11:22 AM, Zheda Chen wrote:

More details are updated in ChromeStatus, including
interoperability and compatibility risks, Safari/Firefox views,
   

Re: [blink-dev] Intent to Deprecate and Remove: Deprecate the includeShadowRoots argument on DOMParser

[Mike Taylor]

On 3/19/24 6:51 PM, Mason Freed wrote:




On Tue, Mar 19, 2024 at 1:44 PM Mike Taylor  
wrote:


Hi Mason,

Would you mind requesting reviews for the various shipping gates
(privacy, security, enterprise, etc.) in your chromestatus entry?


Definitely! But I only need to do that before I ship this, right? I.e. 
not required yet, while I’m just deprecating but not yet removing the 
feature?
We discussed this in our owners meeting today, and we think it's 
probably useful to go ahead and do that now - Enterprise in particular 
would probably be very interested in knowing about a deprecation. And 
for the rest if you think they're N/A, it's not much work to request that.



On 3/15/24 6:49 PM, Mason Freed wrote:



Contact emails


mas...@chromium.org


Explainer


None


Specification


https://github.com/whatwg/html/pull/10139


Summary


The includeShadowRoots argument was a never-standardized
argument to the DOMParser.parseFromString() function,
which was there to allow imperative parsing of HTML
content that contains declarative shadow DOM. This was
shipped in M90 [1] as part of the initial shipment of
declarative shadow DOM. Since the standards discussion
rematerialized in 2023, the shape of DSD APIs changed,
including this feature for imperative parsing. (See [2]
for more context on the standards situation and recent
changes, and see [3] and [4] for other related
deprecations.) Now that a standardized version of this
API, in the form of setHTMLUnsafe() and parseHTMLUnsafe()
will ship in M124 ([5]), the non-standard
includeShadowRoots argument needs to be deprecated and
removed. All usage should shift accordingly: Instead of:
(new
DOMParser()).parseFromString(html,'text/html',{includeShadowRoots:
true}); this can be used instead:
document.parseHTMLUnsafe(html); [1]
https://chromestatus.com/feature/5191745052606464 [2]
https://chromestatus.com/feature/5161240576393216 [3]
https://chromestatus.com/feature/5081733588582400 [4]
https://chromestatus.com/feature/6239658726391808 [5]
https://chromestatus.com/feature/6560361081995264



Blink component


Blink>DOM>ShadowDOM

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EDOM%3EShadowDOM>


Motivation


Now that there is a standardized version of this API, it
makes sense to remove the non-standard, Chrome-only
version of the API.



Initial public proposal


None


TAG review


None


TAG review status


Not applicable


Risks




Interoperability and Compatibility


Because this is a removal of an API, there is some compat
risk if sites use the API without feature detection.
Additionally, feature detection is a bit difficult for
this feature directly, and typical usage would instead
feature-detect the old `shadowroot` attribute. In that
case, there should be no breakage, since that attribute
has since been removed. The use counter [1] for this
feature has unfortunately had a recent spike in usage,
peaking at just over 0.01% of page loads as of March,
2024. However, I analyzed 8 of the top sites, and 8 of 8
are due to the exact same code snippet, from AstroJS/Lit
[2]. And that code amounts to feature detection, which
as-written will properly detect the lack of
`includeShadowRoots` and fall back to other behavior.
This, plus the lack of support in other browsers, makes
me less concerned about the compat risk here. [1]
https://chromestatus.com/metrics/feature/timeline/popularity/4455
[2]

https://github.com/withastro/astro/blob/main/packages/integrations/lit/client-shim.js



/Gecko/: No signal

/WebKit/: No signal

/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



Is this feature fully tested by web-platform-tests

<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?


Yes

Tested via this WPT:

Re: [blink-dev] Intent to Ship: Attribution Reporting Feature Bundle: Header Error Debug Reports, Preferred Platform field, Changing Source Deactivation

[Mike Taylor]

On 3/18/24 7:17 PM, 'Akash Nadan' via blink-dev wrote:


Contact emails

akashna...@google.com , 
lin...@chromium.org , 
johni...@chromium.org 



Explainer

Attribution Reporting with event-level reports 



Attribution Reporting API with Aggregatable Reports 



Aggregation Service for the Attribution Reporting API 




Specification

https://wicg.github.io/attribution-reporting-api/ 




Blink component

Internals > AttributionReporting 




Summary

We are landing the following changes to the Attribution Reporting API 
focused on:


 *

additional debugging capabilities by supporting parsing failure
debug reports

 *

improving API ergonomics by supporting a field to specify
preferred registration platform

 *

improving privacy


Explainer/Spec changes

 1. Response header errors debug reports

 2. Supporting preferred platform for cross app attribution

 3. Move source deactivation step after top level filter matching



Risks
Interoperability and Compatibility

(1 ) 
Header errors debug reports and (2 
) 
preferred platform are both fully backwards compatible changes and are 
optional features.  (3 
) The 
source deactivation change has very low compatibility risk because it 
does not require any developer changes and only results in ad techs 
getting different reports in cases where a user had multiple 
interactions across different ads when rate limits in the API are hit, 
which should be very rare.


I think I understand why the potential compat issue should be rare based 
on reading 
https://github.com/WICG/attribution-reporting-api/issues/842#issuecomment-1612096408, 
but it's not super clear to me what the implications for "adtechs 
getting different reports in some circumstances (or not report where 
they previously would have gotten one)" are. Mind clarifying?


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


The attribution reporting feature bundle will be supported on all 
platforms with the exception of  Android WebView



Is this feature fully tested by web-platform-tests 
? 



Yes


Estimated milestones

This feature bundle is anticipated to ship as part ofChrome 124 
.



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5117902786396160 




Links to previous Intent discussions

Previous I2S:

Intent to Ship: Attribution Reporting API 



Intent to Ship: Attribution Reporting features M117 



Intent to Ship: Attribution Reporting features M118 



Intent to Ship: Attribution Reporting features M119 



Intent to Ship: Attribution Reporting features M120 



Intent to Ship: Attribution Reporting features M121 



Intent to Ship: Attribution Reporting features M123 




--
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/c691e58e-bfbb-492b-b235-6facc6d12062n%40chromium.org 
.


--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and s

Re: [blink-dev] Intent to Deprecate and Remove: Deprecate the includeShadowRoots argument on DOMParser

[Mike Taylor]

Hi Mason,

Would you mind requesting reviews for the various shipping gates 
(privacy, security, enterprise, etc.) in your chromestatus entry?


On 3/15/24 6:49 PM, Mason Freed wrote:



Contact emails


mas...@chromium.org


Explainer


None


Specification


https://github.com/whatwg/html/pull/10139


Summary


The includeShadowRoots argument was a never-standardized
argument to the DOMParser.parseFromString() function, which
was there to allow imperative parsing of HTML content that
contains declarative shadow DOM. This was shipped in M90 [1]
as part of the initial shipment of declarative shadow DOM.
Since the standards discussion rematerialized in 2023, the
shape of DSD APIs changed, including this feature for
imperative parsing. (See [2] for more context on the standards
situation and recent changes, and see [3] and [4] for other
related deprecations.) Now that a standardized version of this
API, in the form of setHTMLUnsafe() and parseHTMLUnsafe() will
ship in M124 ([5]), the non-standard includeShadowRoots
argument needs to be deprecated and removed. All usage should
shift accordingly: Instead of: (new
DOMParser()).parseFromString(html,'text/html',{includeShadowRoots:
true}); this can be used instead:
document.parseHTMLUnsafe(html); [1]
https://chromestatus.com/feature/5191745052606464 [2]
https://chromestatus.com/feature/5161240576393216 [3]
https://chromestatus.com/feature/5081733588582400 [4]
https://chromestatus.com/feature/6239658726391808 [5]
https://chromestatus.com/feature/6560361081995264



Blink component


Blink>DOM>ShadowDOM




Motivation


Now that there is a standardized version of this API, it makes
sense to remove the non-standard, Chrome-only version of the API.



Initial public proposal


None


TAG review


None


TAG review status


Not applicable


Risks




Interoperability and Compatibility


Because this is a removal of an API, there is some compat risk
if sites use the API without feature detection. Additionally,
feature detection is a bit difficult for this feature
directly, and typical usage would instead feature-detect the
old `shadowroot` attribute. In that case, there should be no
breakage, since that attribute has since been removed. The use
counter [1] for this feature has unfortunately had a recent
spike in usage, peaking at just over 0.01% of page loads as of
March, 2024. However, I analyzed 8 of the top sites, and 8 of
8 are due to the exact same code snippet, from AstroJS/Lit
[2]. And that code amounts to feature detection, which
as-written will properly detect the lack of
`includeShadowRoots` and fall back to other behavior. This,
plus the lack of support in other browsers, makes me less
concerned about the compat risk here. [1]
https://chromestatus.com/metrics/feature/timeline/popularity/4455
[2]

https://github.com/withastro/astro/blob/main/packages/integrations/lit/client-shim.js



/Gecko/: No signal

/WebKit/: No signal

/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



Is this feature fully tested by web-platform-tests

?


Yes

Tested via this WPT:

https://wpt.fyi/results/shadow-dom/declarative/declarative-shadow-dom-opt-in.html
which fails because `includeShadowRoots` is non-standard. This
is the only test failing within the Interop2024 Declarative
Shadow DOM section, due to this deprecation not being
completed yet.



Flag name on chrome://flags




Finch feature name


None


Non-finch justification


None


Requires code in //chrome?


False


Estimated milestones


Shipping on desktop 129
DevTrial on desktop 125

Shipping on Android 129
DevTrial on Android 125

Shipping on WebView 129



Link to entry on the Chrome Platform Status


https://chromestatus.com/feature/5116094370283520

This intent message was generated by Chrome Platform Status
.

--
You received

Re: [blink-dev] Intent to Ship: X25519Kyber768 key encapsulation for TLS on Desktop

[Mike Taylor]

Also, would you mind requesting reviews for the various shipping gates 
(privacy, security, enterprise, etc.) in your chromestatus entry?


On 3/19/24 12:34 PM, Yoav Weiss (@Shopify) wrote:



On Mon, Mar 18, 2024 at 3:37 PM 'David Adrian' via blink-dev 
 wrote:



Contact emails

dadr...@google.com


Explainer

https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html


Specification

https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html


Summary

Protect current Chrome TLS traffic against future quantum
cryptanalysis by deploying the Kyber768 quantum-resistant key
agreement algorithm. This is a hybrid X25519 + Kyber768 key
agreement based on an IETF standard. This specification and launch
is outside the scope of W3C. This key agreement will be launched
as a TLS cipher, and should be transparent to users.
https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html



Blink component

Internals>Network>SSL




Search tags

tls , kem
, kyber
, postquantum



TAG review



TAG review status

Not applicable


Risks



Interoperability and Compatibility

Post-quantum secure ciphers are larger than classical ciphers.
This may cause compatibility issues with middleboxes.


I'm guessing we're talking about MITM middleboxes, is that correct?
What's our plan to mitigate that risk? Slow rollout? Enterprise 
policy? Both? Something else entirely?




/Gecko/: Shipped/Shipping
(https://github.com/mozilla/standards-positions/issues/874)
Firefox is also in the process of rolling this out.

/WebKit/: No signal
(https://github.com/WebKit/standards-positions/issues/244)

/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?



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

?

N/A


Flag name on chrome://flags

enable-tls13-kyber


Finch feature name

PostQuantumKyber


Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1442377


Launch bug

https://launch.corp.google.com/launch/4252981


Estimated milestones

Shipping on desktop 124
Origin trial desktop first  118
Origin trial desktop last   123
DevTrial on desktop 115

Shipping on Android 128
OriginTrial Android last128
OriginTrial Android first   118
DevTrial on Android 115

Shipping on WebView 128
OriginTrial webView last128
OriginTrial webView first   118



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5257822742249472


Links to previous Intent discussions

Intent to prototype:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42%2BgKeCTA6vWwzrE%3DDVR%3DTmQaCyDFQxqnXkOy9GcVyGtnA%40mail.gmail.com
 Intent
to Experiment:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42%2B37SpGUy9t6bBkP13XQL4mrEaY%2Bu0wAzttjZyr_f2rGA%40mail.gmail.com


We plan to ship Kyber (ML-KEM) by default on /desktop platforms
only/ starting in M124. Kyber is a quantum-resistant key exchange
mechanism for TLS that defends against harvest-now-decrypt-later


attacks. This risk is relevant even if quantum computers do not
yet exist.

Due to the structure of TLS 1.3, Kyber key shares are sent on the
first ClientHello message regardless of server support. Servers
that do not yet support Kyber will ignore it, and select a
different algorithm. Servers that do support Kyber, such as GFEs
and Cloudflare, will select Kyber and respond with their own Kyber
key encapsulation.

Unfortunately, Kyber key shares are around 35x larger than an
X25519 key exchange, which increases the latency of the TLS
handshake connections by 4-6%. On Desktop platforms, this effect
is largely in the

Re: [blink-dev] Intent to Ship: Adding Cross-site Ancestor Chain Bit to CHIPS Partition Key

[Mike Taylor]

It would also be helpful to discuss what breakage looks like in this 
case. Would it be a one-time loss of state (i.e., have to log in again), 
or something different?


On 3/19/24 5:08 AM, Yoav Weiss (@Shopify) wrote:

OK, so just to summarize my understanding:

  * We expect this to have some impact on 0.032% of page views
  * We have a Finch flag that can be used as a kill switch in case we
see lots of breakage in the wild
  * Developers can get around this deprecation by changing their
cookies to be "same-site: none" *and* requesting SAA from users

Is the above correct?

If so, 0.032% sounds like a lot. Would it be possible for y'all to 
same pages that trigger that use counter and see how many of them 
break and what does breakage look like?


On Wed, Mar 13, 2024 at 8:23 PM Aaron Selya  wrote:

The flag is a base::features flag named
kAncestorChainBitEnabledInPartitionedCookies.

Updated the review gates on chromestatus.com 

On Wed, Mar 13, 2024 at 11:25 AM Yoav Weiss (@Shopify)
 wrote:

Also, can you flip on the relevant review gates in
chromestatus.com ?

On Wed, Mar 13, 2024 at 11:24 AM Yoav Weiss (@Shopify)
 wrote:



On Tue, Mar 12, 2024 at 4:46 PM 'Aaron Selya' via
blink-dev  wrote:

The first mitigation listed here is to migrate
existing partitioned cookies to include the new
bit, and the second mitigation is to have a flag
that can disable this feature. Would disabling the
feature also include migrating the existing
cookies back to exclude the new bit?


Disabling the flag would not migrate the existing
cookies back to exclude the new bit. It would make it
so that the new bit value is not considered when
checking equivalence. Not considering the value of the
bit when is the current behavior so we anticipate no
issues ignoring the bit if the flag needs to disable
the feature.


Can you clarify what kind of flag are we talking about? Is
this a Finch flag we expect to turn off if we encounter
lots of breakage? An enterprise policy flag? A flag we
expect users to use? (I doubt it's the latter, but
clarifications would help :D)

And somewhat related, but does the format of the
cookie request developers make have to change too,
or is this bit determination purely done within
the browser?

In almost all cases this is set within the browser.
The only circumstance I've run into where the value
could be set by a developer is with the
chrome.cookies.set api for extensions.  This API
allows the developer to set the site associated with
the cookie partition key and with this change would
allow for the bit value to be set as well.

On Tue, Mar 12, 2024 at 2:53 PM Vladimir Levin
 wrote:



On Mon, Mar 11, 2024 at 1:42 PM Aaron Selya
 wrote:


Contact emails

se...@chromium.org, dylancut...@chromium.org,
kaustub...@chromium.org


Explainer

Keying of "CHIPS" cookies should align with
other state:




Specification

Add cross-site ancestor chain bit to spec:

https://github.com/explainers-by-googlers/CHIPS-spec/pull/13





Summary

We are looking to align the partition key

in
CHIPS (Cookies Having Independent Partitioned
State, aka partitioned cookies) with the
existing implementation of StorageKey.


The only sites that would experience different
behavior, would be when a top-level site “A”
embeds an iframe to a cross-site document on
site “B”, and then the iframe B 

Re: [blink-dev] Intent to Ship: SVG context-fill and context-stroke

[Mike Taylor]

Thanks on both fronts, Stefan!

On 3/15/24 8:37 PM, Stefan Zager wrote:
On Fri, Mar 15, 2024 at 6:29 AM Mike Taylor  
wrote:


On 3/14/24 6:29 PM, Stefan Zager wrote:


On Thu, Mar 14, 2024, 3:13 PM Mike Taylor
 wrote:

On 3/14/24 1:17 PM, Stefan Zager wrote:


/WebKit/: No signal

Can we request a signal?


It strikes me as odd to request a position on a mature, long
since published spec, but if you think it's appropriate I will do so.


I think it serves as a good signal that WebKit should prioritize
shipping here as well, if they'll be the only engine without
support - and if they have strong feelings as to why something
should change before we do ship it, now is the time for them to
provide that input before it's too late.

I opened a webkit standards position issue 
<https://github.com/WebKit/standards-positions/issues/331>.



Presumably this is behind a feature flag, correct?


No it isn't. Again, I didn't think this merited that kind of
treatment.


Can you explain why you think this should be exempt, per

https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md?

In the future, you can avoid these kinds of questions if you give
a little bit more justification. :)


Sorry, the process requirements have expanded quite a bit since I last 
shipped web-exposed features. I will retrofit a feature flag (CL 
<https://chromium-review.googlesource.com/c/chromium/src/+/5375668>).


--
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/8a84dfe6-88cd-489b-a87b-b25ea71e3803%40chromium.org.

Re: [blink-dev] Intent to Ship: Document picture-in-picture: add option to hide back-to-tab button

[Mike Taylor]

Thank you! LGTM2

On 3/15/24 1:13 PM, Tommy Steimel wrote:
Got it, thanks! Adding one in crrev.com/c/5375045 
<http://crrev.com/c/5375045>


On Fri, Mar 15, 2024 at 7:51 AM Mike Taylor  
wrote:


If a human can observe the expected behavior by clicking on a
button and noticing the lack of the return to tab button, then
effectively yes.

On 3/15/24 10:40 AM, Tommy Steimel wrote:

I didn't realize you could do that. So if I make a manual WPT
test, I can make it depend on code in //chrome?

On Fri, Mar 15, 2024 at 6:15 AM Mike Taylor
 wrote:

Is there any reason to not convert

https://steimelchrome.github.io/document-pip/hide-back-to-tab-button.html
into a manual WPT
<https://web-platform-tests.org/writing-tests/manual.html>?
Manual tests aren't ideal, but something seems better than
nothing.

On 3/14/24 9:42 PM, Domenic Denicola wrote:

Awesome, thanks for the quick turnaround time! With that
change, LGTM1.

On Fri, Mar 15, 2024 at 2:16 AM Tommy Steimel
 wrote:

Thanks for the feedback! Updated in
https://github.com/WICG/document-picture-in-picture/pull/116

On Wed, Mar 13, 2024 at 6:53 PM Domenic Denicola
 wrote:

I found an issue with the API design here that might
result in a backward-incompatible change:
https://github.com/WICG/document-picture-in-picture/issues/115


With my spec mentor hat on, sorry for not catching
it sooner!

On Thu, Mar 14, 2024 at 2:12 AM 'Tommy Steimel' via
blink-dev  wrote:


Contact emails

stei...@chromium.org, liber...@chromium.org


Explainer

None


Specification

https://github.com/WICG/document-picture-in-picture/pull/114


Summary

This adds a new parameter
("allowReturnToOpener") to the document
picture-in-picture API that, when set to false,
hints to the user agent that they should not
show a button in the picture-in-picture window
that allows the user to return to the opener.
While having a button to return content to the
opener always makes sense in the video
picture-in-picture case (the video stream can be
returned to the video element in the opener
tab), this is not always the case for document
picture-in-picture experiences. This gives
developers more control over the user experience
when they determine that such a button does not
make sense for their use case.



Blink component

Blink>Media>PictureInPicture

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EMedia%3EPictureInPicture>


TAG review


https://github.com/w3ctag/design-reviews/issues/798#issuecomment-1967916721


TAG review status

Pending


Risks



Interoperability and Compatibility

None



/Gecko/: No signal

(https://github.com/mozilla/standards-positions/issues/670#issuecomment-1967919675)
Added comment to existing standards position
issue for document picture-in-picture. No
response yet

/WebKit/: No signal

(https://github.com/WebKit/standards-positions/issues/41#issuecomment-1967918830)
Added comment to existing standards position
issue for document picture-in-picture. No
response yet

/Web developers/: Positive

(https://github.com/WICG/document-picture-in-picture/issues/113)
We have received feature requests for the
ability to hide the "back to tab" button from
the document picture-in-picture window.

/Other signals/:


Ergonomics

N/A



Activation

N/A



Security

N/A



WebView application risks

Does this intent deprecate or change behavior of
existing APIs, such that it has potentially high

Re: [blink-dev] Intent to Ship: Document picture-in-picture: add option to hide back-to-tab button

[Mike Taylor]

If a human can observe the expected behavior by clicking on a button and 
noticing the lack of the return to tab button, then effectively yes.


On 3/15/24 10:40 AM, Tommy Steimel wrote:
I didn't realize you could do that. So if I make a manual WPT test, I 
can make it depend on code in //chrome?


On Fri, Mar 15, 2024 at 6:15 AM Mike Taylor  
wrote:


Is there any reason to not convert
https://steimelchrome.github.io/document-pip/hide-back-to-tab-button.html
into a manual WPT
<https://web-platform-tests.org/writing-tests/manual.html>? Manual
tests aren't ideal, but something seems better than nothing.

On 3/14/24 9:42 PM, Domenic Denicola wrote:

Awesome, thanks for the quick turnaround time! With that change,
LGTM1.

On Fri, Mar 15, 2024 at 2:16 AM Tommy Steimel
 wrote:

Thanks for the feedback! Updated in
https://github.com/WICG/document-picture-in-picture/pull/116

On Wed, Mar 13, 2024 at 6:53 PM Domenic Denicola
 wrote:

I found an issue with the API design here that might
result in a backward-incompatible change:
https://github.com/WICG/document-picture-in-picture/issues/115


With my spec mentor hat on, sorry for not catching it sooner!

On Thu, Mar 14, 2024 at 2:12 AM 'Tommy Steimel' via
blink-dev  wrote:


Contact emails

stei...@chromium.org, liber...@chromium.org


Explainer

None


Specification

https://github.com/WICG/document-picture-in-picture/pull/114


Summary

This adds a new parameter ("allowReturnToOpener") to
the document picture-in-picture API that, when set to
false, hints to the user agent that they should not
show a button in the picture-in-picture window that
allows the user to return to the opener. While having
a button to return content to the opener always makes
sense in the video picture-in-picture case (the video
stream can be returned to the video element in the
opener tab), this is not always the case for document
picture-in-picture experiences. This gives developers
more control over the user experience when they
determine that such a button does not make sense for
their use case.



Blink component

Blink>Media>PictureInPicture

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EMedia%3EPictureInPicture>


TAG review


https://github.com/w3ctag/design-reviews/issues/798#issuecomment-1967916721


TAG review status

Pending


Risks



Interoperability and Compatibility

None



/Gecko/: No signal

(https://github.com/mozilla/standards-positions/issues/670#issuecomment-1967919675)
Added comment to existing standards position issue
for document picture-in-picture. No response yet

/WebKit/: No signal

(https://github.com/WebKit/standards-positions/issues/41#issuecomment-1967918830)
Added comment to existing standards position issue
for document picture-in-picture. No response yet

/Web developers/: Positive
(https://github.com/WICG/document-picture-in-picture/issues/113)
We have received feature requests for the ability to
hide the "back to tab" button from the document
picture-in-picture window.

/Other signals/:


Ergonomics

N/A



Activation

N/A



Security

N/A



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?

N/A, as this is not available on Android



Debuggability

N/A



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

No

The document picture-in-picture API is not supported
on Android



Is this feature fully tested by
web-platform-tests

<https

Re: [blink-dev] Intent to Ship: SVG context-fill and context-stroke

[Mike Taylor]

On 3/14/24 6:29 PM, Stefan Zager wrote:




On Thu, Mar 14, 2024, 3:13 PM Mike Taylor  wrote:

On 3/14/24 1:17 PM, Stefan Zager wrote:



Contact emails

sza...@chromium.org


Explainer

None


Specification

https://svgwg.org/svg2-draft/painting.html#context-paint


Summary

Implements an existing SVG feature that allows the keywords
'context-fill' and 'context-stroke' when specifying fill and
stroke properties:
https://svgwg.org/svg2-draft/painting.html#context-paint This
only affects SVG sub-trees that are instantiated via a 
element, and  elements that are instantiated via the
'marker' property on a  element. In those circumstances,
'context-fill' and 'context-stroke' are resolved to the value of
the 'fill' and 'stroke' properties on the  or .



Blink component

Blink>SVG
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESVG>


TAG review

None


TAG review status

Not applicable

Is there a reason we think a TAG review would not be useful here?
Alternately, has TAG reviewed the SVG2 draft in any capacity before?


I didn't think this merited a TAG review. Do you think it does?


According to our process, we either need to request a TAG review, or 
explain why we think it doesn't require a TAG review. But I've just 
reminded myself of the exceptions at 
https://www.chromium.org/blink/guidelines/api-owners/process-exceptions/ 
- and I think you're good given the first exemption.






Risks



Interoperability and Compatibility

None



/Gecko/: Shipped/Shipping

Do you happen to know what milestone this shipped in?


I don't know the milestone, but it was in 2017.



/WebKit/: No signal

Can we request a signal?


It strikes me as odd to request a position on a mature, long since 
published spec, but if you think it's appropriate I will do so.


I think it serves as a good signal that WebKit should prioritize 
shipping here as well, if they'll be the only engine without support - 
and if they have strong feelings as to why something should change 
before we do ship it, now is the time for them to provide that input 
before it's too late.




/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

<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?

Yes


Flag name on chrome://flags

None


Finch feature name

None

Presumably this is behind a feature flag, correct?


No it isn't. Again, I didn't think this merited that kind of treatment.


Can you explain why you think this should be exempt, per 
https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md?


In the future, you can avoid these kinds of questions if you give a 
little bit more justification. :)




Non-finch justification

None


Requires code in //chrome?

False


Launch bug

https://issues.chromium.org/issues/40362923


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/5146558556536832

This intent message was generated by Chrome Platform Status
<https://chromestatus.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/CAHOQ7J-4E-nJJ2-pcUUDLxB2pRjOmYF0fKk%2BBjqeXZmuv1uVKw%40mail.gmail.com

<https://groups.google.com/a/chromium.org/d/ms

Re: [blink-dev] Intent to Ship: Document picture-in-picture: add option to hide back-to-tab button

[Mike Taylor]

Is there any reason to not convert 
https://steimelchrome.github.io/document-pip/hide-back-to-tab-button.html 
into a manual WPT 
? Manual tests 
aren't ideal, but something seems better than nothing.


On 3/14/24 9:42 PM, Domenic Denicola wrote:

Awesome, thanks for the quick turnaround time! With that change, LGTM1.

On Fri, Mar 15, 2024 at 2:16 AM Tommy Steimel  wrote:

Thanks for the feedback! Updated in
https://github.com/WICG/document-picture-in-picture/pull/116

On Wed, Mar 13, 2024 at 6:53 PM Domenic Denicola
 wrote:

I found an issue with the API design here that might result in
a backward-incompatible change:
https://github.com/WICG/document-picture-in-picture/issues/115

With my spec mentor hat on, sorry for not catching it sooner!

On Thu, Mar 14, 2024 at 2:12 AM 'Tommy Steimel' via blink-dev
 wrote:


Contact emails

stei...@chromium.org, liber...@chromium.org


Explainer

None


Specification

https://github.com/WICG/document-picture-in-picture/pull/114


Summary

This adds a new parameter ("allowReturnToOpener") to the
document picture-in-picture API that, when set to false,
hints to the user agent that they should not show a button
in the picture-in-picture window that allows the user to
return to the opener. While having a button to return
content to the opener always makes sense in the video
picture-in-picture case (the video stream can be returned
to the video element in the opener tab), this is not
always the case for document picture-in-picture
experiences. This gives developers more control over the
user experience when they determine that such a button
does not make sense for their use case.



Blink component

Blink>Media>PictureInPicture




TAG review


https://github.com/w3ctag/design-reviews/issues/798#issuecomment-1967916721


TAG review status

Pending


Risks



Interoperability and Compatibility

None



/Gecko/: No signal

(https://github.com/mozilla/standards-positions/issues/670#issuecomment-1967919675)
Added comment to existing standards position issue for
document picture-in-picture. No response yet

/WebKit/: No signal

(https://github.com/WebKit/standards-positions/issues/41#issuecomment-1967918830)
Added comment to existing standards position issue for
document picture-in-picture. No response yet

/Web developers/: Positive
(https://github.com/WICG/document-picture-in-picture/issues/113)
We have received feature requests for the ability to hide
the "back to tab" button from the document
picture-in-picture window.

/Other signals/:


Ergonomics

N/A



Activation

N/A



Security

N/A



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?

N/A, as this is not available on Android



Debuggability

N/A



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

No

The document picture-in-picture API is not supported on
Android



Is this feature fully tested by web-platform-tests

?

No

The document picture-in-picture feature itself is fully
tested on WPT, but this additional parameter isn't since
it's a hint to the user agent and therefore any actual
changes happen in the embedder



Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

Small change to existing API



Requires code in //chrome?

False


Sample links



https://steimelchrome.github.io/document-pip/hide-back-to-tab-button.html


Estimated milestones

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Mike Taylor]

The privacy and security teams review all intents, so requesting reviews 
and answering the relevant questionnaires is the best path forward.


Looking forward to the new I2S - thanks!

On 3/14/24 11:22 AM, Zheda Chen wrote:
More details are updated in ChromeStatus, including interoperability 
and compatibility risks, Safari/Firefox views, web platform tests. It 
compares the behaviors across different browser vendors.

https://chromestatus.com/feature/5106220399853568

Will send the updated "intent to ship" to this thread later if it 
looks good.


AFAIK, I don't see potential privacy/security issues, so can i set 
"security review status" and "privacy review status" to "not 
applicable"? Please let us know if you have any concerns.


On Wednesday, March 13, 2024 at 10:00:35 AM UTC+8 dom...@chromium.org 
wrote:


Can you fill out the interoperability and compatibility risks
section here? I don't think standards position requests are
necessary, but saying how this behavior might break existing sites
that assume Chromium's current behavior, and how this new behavior
compares to WebKit and Gecko, would be helpful.

Also, can you request the
privacy/security/enterprise/debuggability/testing gates on Chrome
Status?

On Tue, Mar 12, 2024 at 10:12 PM Zheda Chen 
wrote:

Okay I update the process stage in Chrome Platform Status, and
paste the newly-generated Intent above. Please take a look.

https://chromestatus.com/feature/5106220399853568



--
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/70b96db6-f908-48dc-82b8-a68eab3cce60%40chromium.org.

Re: [blink-dev] Intent to Ship: SVG context-fill and context-stroke

[Mike Taylor]

On 3/14/24 1:17 PM, Stefan Zager wrote:



Contact emails

sza...@chromium.org


Explainer

None


Specification

https://svgwg.org/svg2-draft/painting.html#context-paint


Summary

Implements an existing SVG feature that allows the keywords 
'context-fill' and 'context-stroke' when specifying fill and stroke 
properties: https://svgwg.org/svg2-draft/painting.html#context-paint 
This only affects SVG sub-trees that are instantiated via a  
element, and  elements that are instantiated via the 'marker' 
property on a  element. In those circumstances, 'context-fill' 
and 'context-stroke' are resolved to the value of the 'fill' and 
'stroke' properties on the  or .




Blink component

Blink>SVG 




TAG review

None


TAG review status

Not applicable
Is there a reason we think a TAG review would not be useful here? 
Alternately, has TAG reviewed the SVG2 draft in any capacity before?



Risks



Interoperability and Compatibility

None



/Gecko/: Shipped/Shipping

Do you happen to know what milestone this shipped in?


/WebKit/: No signal

Can we request a signal?


/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


Flag name on chrome://flags

None


Finch feature name

None

Presumably this is behind a feature flag, correct?



Non-finch justification

None


Requires code in //chrome?

False


Launch bug

https://issues.chromium.org/issues/40362923


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/5146558556536832

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/CAHOQ7J-4E-nJJ2-pcUUDLxB2pRjOmYF0fKk%2BBjqeXZmuv1uVKw%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/783e7d35-3106-45c5-9f76-c8367e1aa5c6%40chromium.org.

Re: [blink-dev] Re: Intent to Ship: 'writingsuggestions' attribute

[Mike Taylor]

LGTM2

On 3/14/24 12:43 AM, Domenic Denicola wrote:

Awesome! LGTM1.

On Thu, Mar 14, 2024 at 1:35 PM 'Stephanie Zhang' via blink-dev 
 wrote:


Thanks for clarifying! Updated the Chrome Status' "Finch Feature
Name" field to kWritingSuggestions and removed the "Non-finch
justification" field.

On Wednesday, March 13, 2024 at 9:20:57 PM UTC-7 Domenic Denicola
wrote:

On Thu, Mar 14, 2024 at 12:54 PM 'Stephanie Zhang' via
blink-dev  wrote:

We do have a runtime feature flag 'WritingSuggestions

'.
We didn't think a Finch Trial was necessary, as the bulk
of the changes were just adding the attribute and IDL
functions
.
Since everything is implemented on the blink side, is a
Finch feature flag still necessary? If it is, then I'll
add that flag :)


A runtime feature flag automatically generates


a Finch flag, unless you turn that off :). So I think this is
just a matter of updating the Chrome Status entry.


On Wednesday, March 13, 2024 at 6:55:48 PM UTC-7 Domenic
Denicola wrote:



On Thursday, March 14, 2024 at 2:08:28 AM UTC+9
Stephanie Zhang wrote:

*Contact emails*

_sa...@microsoft.com_,_daniec@microsoft.com_,_stephanie.zh...@microsoft.com_

*Explainer*

_https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WritingSuggestions/explainer.md_



*Specification*

_https://html.spec.whatwg.org/multipage/interaction.html#writing-suggestions_


*Summary*
UAs are starting to provide writing suggestions to
users as they type on various editable fields
across the web. While this is generally useful for
users, there are cases when developers may want to
turn off UA-provided writing assistance, such as
extensions or sites that wish to provide similar
functionality on their own. To that end,
developers need a solution that would turn on/off
UA-provided writing assistance. The new attribute
'writingsuggestions' has values 'true'/'false'
that would allow developers to turn on/off
browser-provided writing suggestions. The
attribute's state for an element can also be
inherited from ancestor elements, thereby allowing
developers to control this functionality at a
per-element or per-document/sub-document scale.


*Blink component*
_Blink>Editing_



*TAG review*
_https://github.com/w3ctag/design-reviews/issues/924_


*TAG review status*
Issues addressed

*Risks*


*Interoperability and Compatibility*
None


/Gecko/: No signal
(_https://github.com/mozilla/standards-positions/issues/855_
)

/WebKit/: In development
(_https://github.com/WebKit/standards-positions/issues/308_
)
WebKit Implementation
PR:_https://github.com/WebKit/WebKit/pull/24051_


/Web developers/: No signals

/Other signals/:

*Ergonomics*
None


*Activation*
None


*Security*
None


*WebView application risks*
/Does this intent deprecate or change behavior of
existing APIs, such that it has potentially

Re: [blink-dev] Intent to Experiment: WebAssembly JS String Builtins

[Mike Taylor]

LGTM to extend from M125 to M127 inclusive - thanks for all the updates on 
progress. And it's totally fine to come back and request another extension, 
with similar updates on progress of the aforementioned areas.

(As a side note, I think the API OWNERs would be open to a discussion on 
the possibility of renewing OTs for Wasm-related proposals for a 
longer-than-default period, given the unique constraints vs other platform 
primitives. If you'd like to pursue that, you could start a conversation on 
blink-api-owners-discuss@).

thx,
Mike

On Thursday, March 14, 2024 at 1:29:57 PM UTC-4 Adam Klein wrote:

> On Thu, Mar 14, 2024 at 8:45 AM Emanuel Ziegler  
> wrote:
>
>> Hi Mike,
>>
>> We can limit it to 3 milestones then and request another extension once 
>> we get further with our experimentation on string constants, because I 
>> don't expect that this will be enough. Every change we make has a 2-3 
>> months of turnaround time because of the multitude of parties (proposal 
>> change → Wasm Runtime + Wasm Tools implementation → Compiler toolchain 
>> implementation → Application recompilation and redeployment) involved to 
>> implement the feature end-to-end and their respective release schedules.
>>
>> To summarize the progress along each dimension:
>>
>>- As mentioned, there was progress on the draft spec and we had a 
>>community group vote on it with very strong support.
>>- We are planning on triggering a TAG review this week. But we don't 
>>intend to ship before reaching phase 4 of the proposal which would be 
>>covered in the exceptions anyway.
>>
>> Filed as https://github.com/w3ctag/design-reviews/issues/940 
>
>>
>>- The status of the Chrome Status entry is still up-to-date in that 
>>we have a very positive signal from Firefox (Mozilla is actually 
>>championing this proposal) with an active implementation and regular 
>>updates and no signal from Safari yet.
>>- The spec community is heavily involved through presentations to the 
>>community group and active discussions 
>><https://github.com/WebAssembly/js-string-builtins/issues> on the 
>>proposal itself.
>>- We don't have WPT tests yet, but they will be added before phase 3 
>>as required by the proposal process.
>>
>> Let me know if you have any further questions!
>>
>> Best regards,
>> Emanuel
>>
>> On Tue, Mar 12, 2024 at 3:52 PM Mike Taylor  
>> wrote:
>>
>>> Hi Emanuel,
>>>
>>> For OTs, we can approve extensions for 3 milestones at a time, depending 
>>> on the criteria set at 
>>> https://www.chromium.org/blink/launching-features/#origin-trials. Would 
>>> you mind summarizing progress in the various areas? It sounds like there is 
>>> good engagement from the "spec community" already.
>>>
>>> thx,
>>> Mike
>>> On 3/12/24 8:35 AM, Emanuel Ziegler wrote:
>>>
>>> Dear API owners, 
>>>
>>> Our origin trial on supporting JS Strings in Wasm 
>>> <https://developer.chrome.com/origintrials/#/view_trial/2142587522721513473>
>>>  
>>> (JS String Builtins 
>>> <https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md>
>>>  
>>> for Wasm) has reached its final milestone and we would like to continue to 
>>> experiment with it.
>>>
>>> The current status of the proposal and our experiments 
>>> <https://docs.google.com/document/d/1zL9goDsawTQUFuuQ8ddI_pUcLY1_iFOsHaDZ374dnGw/edit?usp=sharing>
>>>  
>>> is as follows:
>>>
>>>- The proposal is progressing well and has *reached phase 2* on 
>>>January 16 with overwhelming support by the community group (17 votes 
>>>strongly in favor, 11 votes in favor, 4 neutral and no votes against). 
>>>- Performance of native support for JS strings in J2Wasm, Kotlin and 
>>>Dart continues to look highly promising, making this a top priority for 
>>> us 
>>>to finalize the proposal and ship it in Chrome this year. 
>>>- There were a *series of changes 
>>>
>>> <https://docs.google.com/presentation/d/1gbyQz0nbLJJ07lbi8iuLHSchQ2-fH29UXS5ebLnG0ZU/edit#slide=id.g1ef40614c6f_0_0>
>>>  
>>>to the proposal* and its API leading up to the vote which since then 
>>>have all been implemented in V8. 
>>>- *Sheets and J2Wasm started experimentation on the proposal* and we 
>>>expec

Re: [blink-dev] Intent to Ship: WebGPU: ServiceWorker and SharedWorker support

[Mike Taylor]

LGTM2

On 3/13/24 12:40 PM, Corentin Wallez wrote:
Just to clarify, the ServiceWorker cannot do anything more than what 
the main thread can do for DoS. Or I guess the only additional 
capability is that it can trigger it up to 30 seconds after the user 
left the page.


The reason why we can't prevent DoS in all cases is that most GPUs 
don't have preemption so sending an infinite loop can make some of the 
processing units stuck forever. Chromium has mechanisms to try to 
detect this and assign the blame to a website that won't be allowed 
GPU access in the future, and some OSes can restart a stuck GPU. But 
this is all best effort (unfortunately, and already the case with 
WebGL, or potentially DOM with crazy filters).

On Wednesday, March 13, 2024 at 3:28:42 PM UTC+1 Corentin Wallez wrote:

I don't know the ServiceWorker mechanisms too much, but if the
Javascript dies in 30 seconds then WebGPU operations will soon
after. There isn't a lot of use in keeping WebGPU computations
running for much longer as Javascript is needed to get the result
of any computation in any useful places (canvas, ArrayBuffer,
MediaStream, etc). Technically the ServiceWorker could send a much
longer running job to the GPU (think an infinite loop) but apart
from DDoS there wouldn't be any use to this.

You might also be interested in the privacy and security section
<https://gpuweb.github.io/gpuweb/#malicious-use> of the WebGPU spec.
On Wednesday, March 13, 2024 at 9:55:02 AM UTC+1 Daniel Bratell wrote:

Just to ask what is probably a FAQ to get it out here...

The Service Worker timeout is 30 seconds right, so regardless
of how heavy the calculations are, a service worker and its
associated calculations will die in 30 seconds after the user
closes the associated page?

I ask because while it's been possible to run heavy
calculations in various workers in the past, this explicitly
encourages it. It would be a bad situation if a user cannot
detect or stop a runaway WebGPU operation from a possibly
hostile site.

/Daniel

On 2024-03-13 08:06, 'François Beaufort' via blink-dev wrote:



On Tue, Mar 12, 2024 at 10:14 PM Yoav Weiss (@Shopify)
 wrote:

LGTM1

On Tue, Mar 12, 2024, 15:10 'François Beaufort' via
blink-dev  wrote:



On Tue, Mar 12, 2024 at 6:58 PM Mike Taylor
 wrote:

On 3/11/24 4:06 PM, 'François Beaufort' via
blink-dev wrote:



Contact emails

fbea...@google.com


Explainer

None

Could you write a few sentences why this is a
useful addition?

Service Workers enable offline capabilities and
background processing for WebGPU. This means
graphics-intensive web applications or Chrome
Extensions can cache resources and perform
computations even when the user isn't actively
interacting with the page.
Shared Workers allow multiple tabs or extension
contexts to coordinate and share WebGPU resources.
This leads to smoother performance and more efficient
use of the user's graphics hardware.



Specification

https://gpuweb.github.io/gpuweb/#navigator-gpu


Summary

Functionality added to the WebGPU spec after its
first shipment in a browser. ServiceWorker and
SharedWorker support is added to WebGPU,
aligning with existing WebGL capabilities.


Blink component

Blink>WebGPU

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebGPU>


TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

ServiceWorker and SharedWorker support have not
yet been implemented in any browser, but have
been approved by the GPU for the Web Community
Group, with representatives from Chrome,
Firefox, and Safari. See minutes at

https://docs.google.com/document/d/15w7nsvqWwITA5yvCrsO3SEIEuZziXzj7YsrHN4Jd2uM/edit#heading=h.jbe7pg8ebd43



/Gecko/: No signal
(https://github.com/mozilla/standards-positions/issues/971)

Re: [blink-dev] Intent to Ship: Protected Audience: Downsampled forDebugOnly & Increase number of component ads

[Mike Taylor]

LGTM2

On 3/13/24 11:45 AM, Yoav Weiss (@Shopify) wrote:

LGTM1

On Monday, March 11, 2024 at 4:21:36 PM UTC-4 Paul Jensen wrote:

On Wed, Mar 6, 2024 at 12:07 PM Yoav Weiss (@Shopify)
 wrote:



On Mon, Mar 4, 2024 at 7:00 PM Paul Jensen
 wrote:



On Wed, Feb 28, 2024 at 12:24 PM Yoav Weiss (@Shopify)
 wrote:



On Thu, Feb 22, 2024 at 6:07 PM 'Orr Bernstein' via
blink-dev  wrote:

Contact emails

pauljen...@chromium.org


Explainer

Downsampled forDebugOnly:
https://github.com/WICG/turtledove/pull/1020


Increase number of component ads:
https://github.com/WICG/turtledove/pull/1003



Specification

Downsampled forDebugOnly:
https://github.com/WICG/turtledove/pull/1023


Increase number of component ads:
https://github.com/WICG/turtledove/pull/1004



Summary

Downsampled forDebugOnly:

The forDebuggingOnly.reportAdAuctionWin() and
forDebuggingOnly.reportAdAuctionLoss() (fDO) APIs
were added to the Protected Audience (PA) API to
allow debugging from within bidding and scoring
scripts in PA auctions.  We originally intended to
remove these APIs at third-party cookie
deprecation (3PCD) time, but received feedback
that they were essential for doing root cause
analysis in escalation situations (i.e. critical
crash). Instead of removing debug reports
entirely, we now plan to heavily downsample them
at 3PCD time as follows: they will only send a
report with a 1/1000 probability. Furthermore, if
a report is sent, the browser will not send
another for 3 years (“lockout”), and if a report
is not sent (999/1000 of the time), future calls
to the fDO API from the calling origin will be
ignored for 2 weeks 90% of the time and 1 year 10%
of the time (“cooldown”).  To avoid biasing
towards new browser installs (which aren’t in
lockout or cooldown), we may place new browser
installs initially in a shorter lockout period.
For now, until 3PCD, we’ll expose whether a fDO
caller is in the “lockout” or “cooldown” periods.


Increase number of component ads:

Today, PA allows selection of ads containing 20
component ads (aka product level ads).  We plan to
increase this number from 20 to 40 as we received
feedback that ads with higher numbers of
components were critical (e.g. for ads that rotate
through 3 sets of 12 products).


Can you expand on the implications of increasing that
number? What's the tradeoff involved?


As discussed on github here
and in
person here

,
we've heard from adtechs that large portions of their ad
inventory cannot be displayed without allowing higher
numbers of component ads, so increasing this number
restores more publisher site revenue.  The downsides to
increasing this number are fairly minor:  There's a
negligible privacy impact as the component ads are not
shared with PA reporting scripts, are required to be
k-anonymous, and when displayed, each component ad can be
isolated from each other in separate Fenced Frames.


I understand the benefits of increasing the number of ads, but
are there any pointers to past discussion/analysis RE the
privacy impact? I understand it's not huge (and it's not my
role to judge the privacy risk - that's what the privacy
review is for). I'd just love to better understand this :D


WRT the privacy impact, as it's negligible, there isn't much to
dis

Re: [blink-dev] Intent to Ship: WebGPU: ServiceWorker and SharedWorker support

[Mike Taylor]

On 3/11/24 4:06 PM, 'François Beaufort' via blink-dev wrote:



Contact emails

fbeauf...@google.com


Explainer

None

Could you write a few sentences why this is a useful addition?



Specification

https://gpuweb.github.io/gpuweb/#navigator-gpu


Summary

Functionality added to the WebGPU spec after its first shipment in a 
browser. ServiceWorker and SharedWorker support is added to WebGPU, 
aligning with existing WebGL capabilities.



Blink component

Blink>WebGPU 




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

ServiceWorker and SharedWorker support have not yet been implemented 
in any browser, but have been approved by the GPU for the Web 
Community Group, with representatives from Chrome, Firefox, and 
Safari. See minutes at 
https://docs.google.com/document/d/15w7nsvqWwITA5yvCrsO3SEIEuZziXzj7YsrHN4Jd2uM/edit#heading=h.jbe7pg8ebd43 




/Gecko/: No signal 
(https://github.com/mozilla/standards-positions/issues/971)
Not officially a positive signal, but looking positive based on the 
comments.


/WebKit/: No signal 
(https://github.com/WebKit/standards-positions/issues/294#issuecomment-1877411933)

This is kind of an "N/A to positive", given it's WebGPU.


/Web developers/: Positive (https://github.com/gpuweb/gpuweb/issues/4197)

/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)?

No
All platforms will eventually have support. Will immediately be 
available on Android, ChromeOS, Mac, and Windows, since those 
platforms already support WebGPU. Linux is planned to have WebGPU 
support in the future, so this feature will become available when 
WebGPU does.

What about WebView? Do we ship support for WebGPU there?




Is this feature fully tested by web-platform-tests

?

Yes

WebGPU/WGSL have a conformance test suite 
(https://github.com/gpuweb/cts) that is regularly pulled into Chromium 
and part of the testing of Dawn/Tint in Chromium. PRs: 
https://github.com/gpuweb/cts/pull/3419 - 
https://github.com/gpuweb/cts/pull/3345



Flag name on chrome://flags

None


Finch feature name

WebGPUExperimentalFeatures


Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1521763


Estimated milestones

Shipping on desktop 124

Shipping on Android 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/4875951026733056


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5%2BewUL-PTEQ_ZQgdtViKU2fSVXeDNab2oEy6RsGqkgcGQ%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/CAPpwU5Lo3k-Gynt4M%2BwgV3yfg%2BFvM1npij%2BGTNZLW-VZHojXYA%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/b93b29a5-db02-4959-8406-b09ad10355e7%40chromium.org.

Re: [blink-dev] Intent to Ship: FedCM CORS requirement on ID assertion endpoint

[Mike Taylor]

On 3/12/24 11:33 AM, Nicolás Peña Moreno wrote:

Thanks for the suggestion, Yoav! It seems something fetch experts have 
some concerns about, so we do not plan to proceed with that suggestion 
at the moment.


I'd like to append a small addition to this I2S (mainly to avoid 
having an additional PSA since it is very related to this one): we 
would also like approval to only send Same-Site=None cookies in the 
accounts endpoint, instead of all cookies (so not Same-Site=Lax or 
Same-Site=Strict). This is also a breaking change but we do not 
anticipate IDPs to break, and also plan to work with them to ensure 
that they are aware of this change and are not caught by surprise.
To my non-FedCM expert brain, this doesn't feel like a small addition 
(happy to be wrong!), beyond not understanding the scale of the risk, 
the normal process questions come to mind i.e., is it specced, do we 
have tests, what do other vendors think about it?


On Monday, March 11, 2024 at 6:39:14 AM UTC-4 Yoav Weiss wrote:


I left a comment
<https://github.com/fedidcg/FedCM/issues/428#issuecomment-1980469172> around
potentially adding a CORS mode that would help IDP servers
statically protect themselves from destination-change attacks. I
don't *think* it's a blocker, but it's worth considering something
along those lines to increase the solution's robustness to
configuration errors, and ensure it fails closed. (and ask IDPs'
security teams about their thoughts)

On Wed, Mar 6, 2024 at 5:51 PM Nicolás Peña  wrote:

No, Sec-Fetch-Dest

<https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Dest>
is not changing. Sec-Fetch-Mode

<https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Mode>
is.

On Wednesday, March 6, 2024 at 11:31:35 AM UTC-5 Chris
Harrelson wrote:

On Wed, Mar 6, 2024 at 8:28 AM Nicolás Peña
 wrote:



On Wednesday, March 6, 2024 at 5:11:09 AM UTC-5 Yoav
Weiss wrote:

On Wed, Mar 6, 2024 at 10:21 AM Yoav Weiss
(@Shopify)  wrote:



        On Mon, Mar 4, 2024 at 9:36 PM Mike Taylor
 wrote:

LGTM1

On 3/4/24 1:33 PM, Nicolás Peña wrote:

Contact emails

n...@chromium.org


Explainer

https://github.com/fedidcg/FedCM/issues/428
<https://github.com/fedidcg/FedCM/issues/428>



A few lines summarizing this issue would be
most useful when evaluating this and
understanding what y'all want to ship.
In particular, it'd be useful to understand
the request flow, what is the request's origin
(as IIUC, we're talking about requests issued
from the browser), and what is the request
destination that we may want IDPs to check.

Examples of the checks IDPs would have to make
would also be helpful.


Sure! From the spec

<https://fedidcg.github.io/FedCM/#idp-api-id-assertion-endpoint>,
here is a sample request:

POST /fedcm_assertion_endpoint HTTP/1.1
Host: idp.example
Origin: https://rp.example/
Content-Type: application/x-www-form-urlencoded
Cookie: 0x23223
Sec-Fetch-Dest: webidentity

account_id=123&client_id=client1234&nonce=Ct60bD&disclosure_text_shown=true
With this change, Sec-Fetch-Mode will now be cors in
this request and the IDP is expected to return the
following in the response (no preflight is performed):


Do you mean Sec-Fetch-Dest?


Access-Control-Allow-Origin: https://rp.example/
Access-Control-Allow-Credentials: true


Also, is the "identity assertion" endpoint the
same as the token endpoint

<https://github.com/fedidcg/FedCM/blob/main/explainer.md#token_endpoint>?


Yea. I think that explainer doc is not super up to date.



Specification

https://github.com/fedidcg/FedCM/pull/547
<https://github.com/fedidcg/FedCM/pull/547>


Summary

The fetches in the FedCM API are hard to
reason about because of the properties
   

Re: [blink-dev] Intent to Experiment: WebAssembly JS String Builtins

[Mike Taylor]

Hi Emanuel,

For OTs, we can approve extensions for 3 milestones at a time, depending 
on the criteria set at 
https://www.chromium.org/blink/launching-features/#origin-trials. Would 
you mind summarizing progress in the various areas? It sounds like there 
is good engagement from the "spec community" already.


thx,
Mike

On 3/12/24 8:35 AM, Emanuel Ziegler wrote:

Dear API owners,

Our origin trial on supporting JS Strings in Wasm 
 
(JS String Builtins 
 
for Wasm) has reached its final milestone and we would like to 
continue to experiment with it.


The current status of the proposal and our experiments 
 
is as follows:


  * The proposal is progressing well and has *reached phase 2* on
January 16 with overwhelming support by the community group (17
votes strongly in favor, 11 votes in favor, 4 neutral and no votes
against).
  * Performance of native support for JS strings in J2Wasm, Kotlin and
Dart continues to look highly promising, making this a top
priority for us to finalize the proposal and ship it in Chrome
this year.
  * There were a *series of changes


to the proposal* and its API leading up to the vote which since
then have all been implemented in V8.
  * *Sheets and J2Wasm started experimentation on the proposal* and we
expect in-the-wild performance numbers of the new API within the
next weeks, comparing this with the previous proposal (StringRef)


that this one will replace.
  * *More experimentation* *with respect to string constants *around
binary size, memory overhead and initialization performance is
required. Several options


are available regarding their implementation in the current proposal.
  * Rollout of Sheets experiments is currently at 20% of production
users offering us a wide number of real-world use cases.

We would therefore like to *extend the origin trial by another 6 
milestones*, effectively ending it with M130. This is taking into 
account the long turnaround times required to test any API change 
between proposal changes, their implementation in Chrome, Binaryen, 
J2Wasm and Sheets until we can update the experiment and gather new 
data. We expect to reach phase 3 within the next months and want to 
use the data to inform the final shape of the proposal to be voted to 
phase 4, hopefully before the end of the year.


Thank you,
    Emanuel


Contact emails

ecmzieg...@chromium.org, jkumme...@chromium.org, ad...@chromium.org


Explainer

None


Specification

https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md


Summary

This feature exposes common JS string operations for easy import into 
WebAssembly and optimizations thereof. This allows creating and 
manipulating JS strings from WebAssembly without native support within 
WebAssembly while still allowing for a similar performance as native 
string references. The mechanism works by exposing suitably strict 
versions of JS string operations in the WebAssembly JS API. These can 
be imported by modules using externref as a generic data type for 
storing the strings. The engine can identify that these imports can be 
represented by native graph operators without the need for calling 
into JS. This leads to a comparable peak performance as native string 
operations while allowing quick interoperability with JS since no 
copying at the boundary is required when calling into arbitrary JS 
functions that consume strings.




Blink component

Blink>JavaScript>WebAssembly 




TAG review

None


TAG review status

Not applicable


Chromium Trial Name

WebAssemblyJSStringBuiltins


Link to origin trial feedback summary

https://docs.google.com/document/d/1zL9goDsawTQUFuuQ8ddI_pUcLY1_iFOsHaDZ374dnGw/edit?usp=sharing


Origin Trial documentation link

https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md


Risks



Interoperability and Compatibility

None



/Gecko/: Positive

/WebKit/: No signal

/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 application

Re: [blink-dev] Intent to Ethe xperiment: Document Subtitle (Fix PWA app titles)

[Mike Taylor]

Cool - LGTM to experiment from M124 to M127 inclusive (I think that's 
what you requested - feel free to correct me if not).


later,
Mike

On 3/11/24 3:47 PM, 'Diego Gonzalez' via blink-dev wrote:

Hola Mike,

We're looking art M124 for 4 milestones.

🤘🏼

Diego

On Wednesday 6 March 2024 at 16:38:48 UTC mike...@chromium.org wrote:

Hey Diego,

Can you clarify what milestones you're requesting for the OT?

thx,
Mike

On 2/21/24 11:16 AM, 'Diego Gonzalez' via blink-dev wrote:

Hola Manuel,

Thanks for the heads up. In order for this to be an HTML PR, it
requires interest from another vendor
. I'll submit the
updated explainer for cross-vendor position requests and
follow-up on their new positions which may mean I could present
an HTML PR instead of a chromium-only implementation.

-Diego
On Wednesday 21 February 2024 at 08:47:46 UTC Manuel Rego wrote:



On 20/02/2024 18:47, 'Diego Gonzalez' via blink-dev wrote:
> Specification
>
> https://github.com/whatwg/html/compare/main...diekus:html:main
>


Should this be an actual HTML PR so discussion with third
parties can
happen there?

> /Gecko/: Defer
> (https://github.com/mozilla/standards-positions/issues/749
> )
>
> /WebKit/: No signal
> (https://github.com/WebKit/standards-positions/issues/138
> )

This is closed as "oppose".

Anyway it seems these standard positions requests are quite
old and for
a different initial proposal that has evolved and changed.
Shouldn't we
reopen them (or fill new ones, I'm not sure about the best
practice in
this case) and update them with the new proposal.

> Goals for experimentation

I think you should describe the goals of this
intent-to-experiment.

> Estimated milestones
>
> DevTrial on desktop
>
> 123

And you should define the OriginTrial first and last milestones.

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+...@chromium.org.
To view this discussion on the web visit

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/217e2f71-9e9b-42a4-9fe4-afb538bd765bn%40chromium.org

.


--
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/c184833d-7367-4ad2-9470-d7d5e8e19a8dn%40chromium.org 
.


--
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/fa6ea955-23bd-4b1c-ba0c-bfe2b934c2b6%40chromium.org.

Re: [blink-dev] Intent to Ship: RegExp duplicate named capture groups

[Mike Taylor]

On 3/11/24 6:49 AM, Yoav Weiss (@Shopify) wrote:




On Fri, Mar 8, 2024 at 4:26 PM Mike Taylor  wrote:

LGTM1

On 3/7/24 6:22 PM, Shu-yu Guo wrote:



Contact emails

pth...@chromium.org, s...@chromium.org


Explainer

None


Specification

https://github.com/tc39/ecma262/pull/2721



What are the implications of this on regexes that already have 
duplicate named capture groups? Would their behavior change?
Shu can confirm, but my understanding is any regexes in the wild that 
have duplicate named capture groups today are just busted (they should 
throw a SyntaxError - and those are pretty hard to miss). If they do 
exist in the wild, they should start working, which in theory would 
match author intent. The risk seems very low IMHO, if it exists at all.





Summary

https://github.com/tc39/proposal-duplicate-named-capturing-groups



Blink component

Blink>JavaScript>Regexp

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EJavaScript%3ERegexp>


TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

This is a Stage 3 TC39 proposal. No known interop risk. No known
web incompatibility risk.



/Gecko/: Positive Firefox uses V8's regexp engine, so it is not
actually an independent implementation here.

/WebKit/: Shipped/Shipping
(https://bugs.webkit.org/show_bug.cgi?id=252553) Stage 3 TC39
proposal.

/Web developers/: No signals

/Other signals/:


Ergonomics

No known ergonomics risks.



Activation

This is unlikely to be polyfillable since it's adding a new kind
of RegExp syntax.



Security

No known security risks.



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

Debuggable like any other JS RegExp.



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

<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?

Yes

Tested in test262. https://github.com/tc39/test262/pull/3625
https://github.com/tc39/test262/pull/3706
https://github.com/tc39/test262/pull/3709



Flag name on chrome://flags

--js-regexp-duplicate-named-groups


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Estimated milestones

DevTrial on desktop 123

DevTrial on Android 123



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/5149208388829184

This intent message was generated by Chrome Platform Status
<https://chromestatus.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/CAN-e9e_1DaU400sEcpB6RGv3pZg_382WduoF9MPZvK8QTPfdSQ%40mail.gmail.com

<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN-e9e_1DaU400sEcpB6RGv3pZg_382WduoF9MPZvK8QTPfdSQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
-- 
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/09ed7eb2-94f7-435b-a8fe-9271a5feb76c%40chromium.org

<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/09ed7eb2-94f7-435b-a8fe-9271a5feb76c%40chromium.org?utm_medium=email&utm_source=footer>.



--
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

Re: [blink-dev] Re: Intent to Experiment: IP Protection Phase 0

[Mike Taylor]

Hi Daniel,

We don't have any further details to announce right now, but when we do 
we can update this thread.


thanks,
Mike

On 3/8/24 7:28 PM, Daniel Santiago Rincón Silva wrote:

Hi Brianna and team.

I see that the readme has been updated to specify that the feature 
will be initially launched as an "opt-in setting in specific regions". 
Is there a tentative timeline for this roll-out as well as the 
candidate regions? Also will this roll-out still be limited to Google 
services only or all web traffic?



Thanks!

On Wednesday, November 29, 2023 at 8:10:53 AM UTC-8 Chris wrote:

Putting all other concerns aside, wouldn't this "ip protection"
proxy allow the owner/controllers of the proxies to decide what
websites and content the end user will and won't be allowed to
access?  Why is this problem not listed with other concerns in any
of the proposal write ups I have read? This is a serious 1st
Amendment concern,a nd should be addressed in the conversation and
made known to the public using chrome.

On Thursday, October 19, 2023 at 2:52:53 PM UTC-6 Brianna
Goldstein wrote:


Contact emails

Brianna Goldstein, James Bradley, David Schinazi


Explainer

IP Protection formerly known as Gnatcatcher



Specification

None


Summary

IP Protection
is a feature
that sends third-party traffic for a set of domains through
proxies for the purpose of protecting the user by masking
their IP address from those domains.


After receiving much feedback from the ecosystem, the design
of the broader proposal is as follows:

 *

IP Protection will be opt-in initially. This will help
ensure that there is user control over privacy decisions
and that Google can monitor behaviors at lower volumes.

 *

It will roll out in a phased manner. Like all of our
privacy proposals, we want to ensure that we learn as we
go and we recognize that there may also be regional
considerations to evaluate.

 *

We are using a list based approach and only domains on the
list in a third-party context will be impacted. We are
conscious that these proposals may cause undesired
disruptions for legitimate use cases and so we are just
focused on the scripts and domains that are considered to
be tracking users.


We plan to test and roll out the feature in multiple phases.
To start, Phase 0 will use a single Google-owned proxy and
will only proxy requests to domains owned by Google. This
first phase will allow us to test our infrastructure while
preventing impact to other companies and gives us more time to
refine the list of domains that will be proxied. For
simplicity, only clients with US-based IP addresses will be
granted access to the proxies for phase 0.


A small percentage of clients will be automatically enrolled
in this initial test, though the architecture and design will
evolve between this test and future launches. To access the
proxy, a user must be logged in to Chrome. To prevent abuse, a
Google-run authentication server will grant access tokens to
the Google run proxy based on a per-user quota.


In future phases we plan to use a 2-hop proxy, as had
previously been indicated in the IP Protection explainer.


Blink component

Privacy>Fingerprinting>IPProtection




TAG review

None


TAG review status

N/A


Risks


Interoperability and Compatibility

IP Protection changes how stable a client's IP address is but
does not otherwise cause a breaking change for existing sites.
In this experiment the only sites impacted are Google owned
domains which include the some domains

when
they are loaded in a third party context.

For those requests, a stable IP address for a client can no
longer be expected. There is no impact to other domains at
this time.


Gecko: No signal


WebKit: Shipped a similar feature in Intelligent Tracking
Protection. This experiment is only a single proxy, however we
plan in a later phase to move to the double hop proxy model
that Safari has also shipped.


Web developers: No signals


Other signals:


  

Re: [blink-dev] Intent to Extend Experiment: Extending Storage Access API (SAA) to non-cookie storage

[Mike Taylor]

I'm recused on this one, but even with the extension to 125, you're 
still not going beyond the default 6 milestones for an OT (the original 
request was for 120 to 124) - so the approval should be fairly trivial.


On 3/6/24 11:31 AM, Ari Chivukula wrote:


Contact emails

aric...@chromium.org , 
wanderv...@chromium.org , 
johann...@chromium.org , 
cfred...@chromium.org , 
kaustub...@chromium.org 



Specification

https://privacycg.github.io/saa-non-cookie-storage/ 




Feedback

https://github.com/privacycg/saa-non-cookie-storage/issues 




Design Doc

https://docs.google.com/document/d/19qCGb4qwOcGiNrQM3ptWvRmB4JtpaTFgFVlWLXNOQ6c/edit 




Intent to Prototype

https://groups.google.com/a/chromium.org/g/blink-dev/c/inRN8tI49O0 




Intent to Experiment

https://groups.google.com/a/chromium.org/g/blink-dev/c/SEL7N-xIE5s/ 




Origin Trial

https://developer.chrome.com/origintrials/#/view_trial/577023702256844801 




Summary

We propose extending the StorageAccessAPIBeyondCookies origin trial, 
which allows developers to test extensions to the Storage Access API 
that expose first-party communication/storage mechanisms beyond just 
cookies. We decided to extend the experiment based on a need for 
greater ecosystem feedback before shipping the proposed API.  We would 
like to request extending the end date from June 24, 2024 (M124) to 
August 6, 2024 (M125). We estimate that we will send the intent to 
ship for this API for M125 (pending feedback gathered from this 
extension).



Blink component

Blink>StorageAccessAPI 




Motivation

Developers have indicated the extensions to the Storage Access API in 
this experiment are crucial to site functionality given Storage 
Partitioning has launched and the Storage Partitioning Deprecation 
Trial is currently slated to end in M126. We want to be sure to ship 
the right API, but some components were late to arrive (Shared Worker 
support was only added in M123). Given the increasing volume of 
interest in this API in the past month we should be as sure as 
possible what we are shipping is what’s needed, especially given the 
lack of adoption by other vendors to date.



TAG review

https://github.com/w3ctag/design-reviews/issues/906 
(closed)



Compatibility

The Storage Access API is already implemented in Safari, Firefox, and 
Chrome , 
but the proposed API shape would not change existing behavior without 
new arguments added.



Interoperability

Gecko: No Position Yet 
https://github.com/mozilla/standards-positions/issues/898 



WebKit: No Position Yet 
https://github.com/WebKit/standards-positions/issues/262 



Web developers: Positive 




Debuggability

Storage written can be examined in devtools.


Is this feature fully tested by web-platform-tests?

Yes 




Tracking bug

https://issues.chromium.org/40282415 




Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5175585823522816 




--
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/CAGpy5DL7W60fWez8v7-%2BfkvYN-nr3iqN7hsdpuULJ_%3DL%2Brw4%3Dg%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

Re: [blink-dev] Intent to Ship: RegExp duplicate named capture groups

[Mike Taylor]

LGTM1

On 3/7/24 6:22 PM, Shu-yu Guo wrote:



Contact emails

pth...@chromium.org, s...@chromium.org


Explainer

None


Specification

https://github.com/tc39/ecma262/pull/2721


Summary

https://github.com/tc39/proposal-duplicate-named-capturing-groups



Blink component

Blink>JavaScript>Regexp 




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

This is a Stage 3 TC39 proposal. No known interop risk. No known web 
incompatibility risk.




/Gecko/: Positive Firefox uses V8's regexp engine, so it is not 
actually an independent implementation here.


/WebKit/: Shipped/Shipping 
(https://bugs.webkit.org/show_bug.cgi?id=252553) Stage 3 TC39 proposal.


/Web developers/: No signals

/Other signals/:


Ergonomics

No known ergonomics risks.



Activation

This is unlikely to be polyfillable since it's adding a new kind of 
RegExp syntax.




Security

No known security risks.



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

Debuggable like any other JS RegExp.



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

Tested in test262. https://github.com/tc39/test262/pull/3625 
https://github.com/tc39/test262/pull/3706 
https://github.com/tc39/test262/pull/3709




Flag name on chrome://flags

--js-regexp-duplicate-named-groups


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Estimated milestones

DevTrial on desktop 123

DevTrial on Android 123



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/5149208388829184

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/CAN-e9e_1DaU400sEcpB6RGv3pZg_382WduoF9MPZvK8QTPfdSQ%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/09ed7eb2-94f7-435b-a8fe-9271a5feb76c%40chromium.org.

Re: [blink-dev] Re: Intent to Ship: Document Render-Blocking

[Mike Taylor]

LGTM1

On 3/6/24 11:00 AM, Vladimir Levin wrote:

Re failing tests:
The flag is currently in "test" status 
 which 
I don't believe would be picked up by wpt.fyi experimental run.


Re explainer for non-vt cases:
We added several other examples 
 
to the explainer (thanks Noam!)


Re console warning:
Good catch indeed. We'll make sure to address 
https://issues.chromium.org/issues/328279707 in a timely manner.



On Wed, Mar 6, 2024 at 10:18 AM Jake Archibald 
 wrote:


The design of this looks great. Filed a couple of very minor spec
nuts https://github.com/whatwg/html/issues/10180


Thanks! 🔩



On Monday 4 March 2024 at 16:36:43 UTC vmp...@chromium.org wrote:


Contact emails

vmp...@chromium.org, nrose...@chromium.org


Explainer


https://github.com/WICG/view-transitions/blob/main/document-render-blocking.md#blocking-element-id


Specification

https://html.spec.whatwg.org/multipage/links.html#link-type-expect


Summary

This feature enables authors to block rendering of a Document
until the critical content has been parsed, ensuring a
consistent first paint across all browsers. Without this
feature, the first paint's state depends on the heuristics for
parser yielding which can vary across browsers. This is
particularly important for View Transitions where the parsed
DOM state on the first frame can drastically change the
transition created. Note that this feature specifically
implements a `` syntax that allows
a link element to reference another expected element on the
page. The rendering is then blocked until the expected element
is fully parsed. This supersedes previous implementation of
html attribute that allows the whole document to be render
blocked.



Blink component

Blink>ViewTransitions>MPA




TAG review

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


TAG review status

Issues addressed


Risks



Interoperability and Compatibility

None



/Gecko/: Positive
(https://github.com/mozilla/standards-positions/issues/875)

/WebKit/: No signal
(https://github.com/WebKit/standards-positions/issues/245)

/Web developers/: Positive
(https://github.com/whatwg/html/issues/9332) There are some
discussions between implementors and developers on this issue.
This feature is also a requisite feature for cross-document
View Transition adoption, which has strong positive signals
(https://daverupert.com/2023/05/getting-started-view-transitions/).

/Other signals/:


Ergonomics

This feature would be used frequently with cross-document View
Transitions, because it allows the browser to wait for
necessary content to be parsed.



Activation

This feature can be used directly.



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?

There are no WebView application risks



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/html/dom/render-blocking?label=master&label=experimental&aligned&q=element-render-blocking


Note that we will be renaming these from .tentative shortly



Flag name on chrome://flags

None


Finch feature name

DocumentRenderBlocking


Requires code in //chrome?

False


Adoption expectation

This feature is expected to be adopted by developers using
cross-document View Transitions


Estimated milestones

Shipping on desktop 124

Shipping on Android 124

Shipping on WebView 124



Anticipated 

Re: [blink-dev] Intent to ship: MP4 container support for MediaRecorder

[Mike Taylor]

We met today and discussed this intent as OWNERS, and would like you to 
still request a vendor position from Mozilla (as I requested earlier). 
If this change doesn't result in interop with Safari, can you also file 
a vendor position for them? My read of the explainer is that we should 
be matching Safari, but confirming would be good. Please consider 
shipping contingent on this request.


https://github.com/mozilla/standards-positions
https://github.com/WebKit/standards-positions

thanks,
Mike

On 3/6/24 11:48 AM, Alex Russell wrote:

LGTM3

At a higher level, it would be great for AV1/VP9 encode to end up in 
something like Interop. It makes me sad to be adding a vote here to 
enable a closed format when open ones are better.


On Wednesday, March 6, 2024 at 8:43:11 AM UTC-8 Philip Jägenstedt wrote:

LGTM2

I think that

https://wpt.fyi/results/mediacapture-record?label=master&label=experimental&aligned&q=mp4

<https://wpt.fyi/results/mediacapture-record?label=master&label=experimental&aligned&q=mp4>
are the relevant tests. LGTM assuming all of these tests pass with
MediaRecorderEnableMp4Muxer enabled. If that's not the case, is
there some functionality that won't be supported initially?

On Wed, Mar 6, 2024 at 7:19 AM Yoav Weiss (@Shopify)
 wrote:

LGTM1

On Tue, Mar 5, 2024 at 5:01 PM 'Michaela Merz' via blink-dev
 wrote:

Thank you for adding this. Finally we're going to be able
to do cross-browser video-recordings and playing. Can't
wait to see it in production.

M.


On Monday, March 4, 2024 at 3:50:13 PM UTC-7
sun...@microsoft.com wrote:

Mike, I've added feature detection and developer
engagement on

https://docs.google.com/document/d/1WV795DHY3Jf2p_htuAKZ9DXUefiGdQs29mCb8vRiHt8/edit?usp=sharing

<https://docs.google.com/document/d/1WV795DHY3Jf2p_htuAKZ9DXUefiGdQs29mCb8vRiHt8/edit?usp=sharing>.


On Monday, March 4, 2024 at 2:13:11 PM UTC-8 Sunggook
Chue wrote:

Yoav,

Philipp's answer is correct, please let me know if
you need any more info to unblock.

On Thursday, February 29, 2024 at 11:53:47 AM
UTC-8 philipp...@googlemail.com wrote:

Yoav,

in WebRTC land "we have a sample for that"
(thanks to the one and only WebRTC devrel guy
Sam Dutton, I think I stole this tagline from
him)!

https://webrtc.github.io/samples/src/content/getusermedia/record/

<https://webrtc.github.io/samples/src/content/getusermedia/record/>
with recent changes to improve MP4 support.

Discovery currently happens
with isTypeSupported but it seems the WG just
decided to deprecate that:

https://github.com/w3c/mediacapture-record/issues/202#issuecomment-1956065141

<https://github.com/w3c/mediacapture-record/issues/202#issuecomment-1956065141>
(not sure how I feel about that, I'd rather
nuke MediaRecorder entirely in favor of
WebCodecs + IndexedDB)

Am Do., 29. Feb. 2024 um 09:13 Uhr schrieb
Yoav Weiss (@Shopify) :



On Thu, Feb 29, 2024 at 1:46 AM 'Sunggook
Chue' via blink-dev 
wrote:

Here is an explainer, summary only.


https://docs.google.com/document/d/1WV795DHY3Jf2p_htuAKZ9DXUefiGdQs29mCb8vRiHt8/edit?usp=sharing

<https://docs.google.com/document/d/1WV795DHY3Jf2p_htuAKZ9DXUefiGdQs29mCb8vRiHt8/edit?usp=sharing>


Thanks! That's very useful! :)

What's the feature detection story? How
can developers know which formats are
supported?



On Wednesday, February 28, 2024 at
7:53:29 AM UTC-8 yoav...@chromium.org
        wrote:

On Tue, Feb 27, 2024 at 1:45 AM
Mike Taylor 
wrote:


On 2/22/24 9:21 PM, 'Sunggook
Chue' via blink-dev wrote:

Re: [blink-dev] Intent to Ethe xperiment: Document Subtitle (Fix PWA app titles)

[Mike Taylor]

Hey Diego,

Can you clarify what milestones you're requesting for the OT?

thx,
Mike

On 2/21/24 11:16 AM, 'Diego Gonzalez' via blink-dev wrote:

Hola Manuel,

Thanks for the heads up. In order for this to be an HTML PR, it 
requires interest from another vendor 
. I'll submit the updated 
explainer for cross-vendor position requests and follow-up on their 
new positions which may mean I could present an HTML PR instead of a 
chromium-only implementation.


-Diego
On Wednesday 21 February 2024 at 08:47:46 UTC Manuel Rego wrote:



On 20/02/2024 18:47, 'Diego Gonzalez' via blink-dev wrote:
> Specification
>
> https://github.com/whatwg/html/compare/main...diekus:html:main
> 

Should this be an actual HTML PR so discussion with third parties can
happen there?

> /Gecko/: Defer
> (https://github.com/mozilla/standards-positions/issues/749
> )
>
> /WebKit/: No signal
> (https://github.com/WebKit/standards-positions/issues/138
> )

This is closed as "oppose".

Anyway it seems these standard positions requests are quite old
and for
a different initial proposal that has evolved and changed.
Shouldn't we
reopen them (or fill new ones, I'm not sure about the best
practice in
this case) and update them with the new proposal.

> Goals for experimentation

I think you should describe the goals of this intent-to-experiment.

> Estimated milestones
>
> DevTrial on desktop
>
> 123

And you should define the OriginTrial first and last milestones.

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/217e2f71-9e9b-42a4-9fe4-afb538bd765bn%40chromium.org 
.


--
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/f88ad388-ca80-4ee5-a22b-3db2e3c46d4e%40chromium.org.

Re: [blink-dev] Intent to Ship: Private Aggregation debug mode for auctionReportBuyers reporting

[Mike Taylor]

LGTM2

On 3/6/24 5:39 AM, Yoav Weiss (@Shopify) wrote:

LGTM1

On Thu, Feb 29, 2024 at 7:29 PM Alex Turner  wrote:


Contact emails

ale...@chromium.org


Explainer


https://github.com/WICG/turtledove/blob/main/FLEDGE_extended_PA_reporting.md#temporary-debugging-mechanism


Specification

https://github.com/patcg-individual-drafts/private-aggregation-api/pull/118


Summary

Adds support for Private Aggregation’s debug mode for the
per-buyer extended Private Aggregation reporting to Protected
Audience sellers (aka auctionReportBuyers reporting). This is done
with a new, optional auctionReportBuyerDebugModeConfig field
passed to runAdAuction(). auctionReportBuyers reporting is
currently the only use of Private Aggregation reports that does
not have a way to enable its debug mode (a temporary mechanism
tied to third-party cookie eligibility that relaxes some of the
API’s privacy constraints to allow for easier debugging and
integration).



Blink component

Blink>PrivateAggregation




TAG review

https://github.com/w3ctag/design-reviews/issues/846 (We have not
requested a signal for these changes specifically.)


TAG review status

Pending


Risks



Interoperability and Compatibility

This feature is optional and backwards compatible.



/Gecko/: No signal
(https://github.com/mozilla/standards-positions/issues/805) We
have not requested a signal for this change specifically.

/WebKit/: No signal
(https://github.com/WebKit/standards-positions/issues/189) We have
not requested a signal for this change specifically.

/Web developers/: Positive
(https://github.com/WICG/turtledove/issues/709) This has been
requested by developers.

/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

This is primarily a debugging feature -- allowing the existing
debug mode for this kind of Private Aggregation reporting.



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

All but Webview



Is this feature fully tested by web-platform-tests

?

Yes


Flag name on chrome://flags

None


Finch feature name

PrivateAggregationAuctionReportBuyerDebugModeConfig


Requires code in //chrome?

False


Tracking bug

https://crbug.com/1513013


Launch bug

https://launch.corp.google.com/launch/4302460


Estimated milestones

We’re aiming to ship in M123.


Anticipated spec changes

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5088927692357632

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/CAA%2BBiFkYb%3DWswXSKM%2B9ESFdgTBUdbjoDq21Q5sWJm%2BPWqqE_nw%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/CAOmohS%2BJt8bhfgO5iLVa7j3byo%2Bov8%3D_kh-Jt6hLfBEbWyJHPA%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/01ae2f98-839d-4b94-975c-fc67394c1bf3%40chromium.org.

Re: [blink-dev] Intent to Ship: Compute Pressure

[Mike Taylor]

On 3/5/24 6:57 AM, Mandy, Arnaud wrote:



Contact emails

kenneth.r.christian...@intel.com, arnaud.ma...@intel.com, 
wei4.w...@intel.com, raphael.kubo.da.co...@intel.com



Explainer

https://github.com/w3c/compute-pressure/blob/main/README.md


Specification

https://www.w3.org/TR/compute-pressure


Summary

The Compute Pressure API offers high-level states that represent the 
pressure on the system. It allows the implementation to use underlying 
hardware/platform metrics to inform the API users of possible stress 
(high CPU load at the moment) on the system and consequently take the 
corrective actions needed.


“Pressure” is a generic term by design – at the moment it is 
calculated based on CPU load, but future plans include using signals 
from temperature and battery status, for example.



https://developer.chrome.com/docs/web-platform/compute-pressure/


Blink component

Blink>PerformanceAPIs>ComputePressure 




Search tags

compute pressure 




TAG review

spec review: https://github.com/w3ctag/design-reviews/issues/795

wide review tracker: https://github.com/w3c/compute-pressure/issues/177


TAG review status

Issues addressed


Chromium Trial Name

ComputePressure


Origin Trial documentation link

https://developer.chrome.com/docs/web-platform/compute-pressure/


Origin Trials history

The first Origin Trial 
 was 
run between M92-94.


The Compute Pressure API was widely redesigned after this OT to 
resemble existing observer-based web APIs and also to provide better 
privacy and security guarantees after discussions with PING.



The second Origin Trial 
 took 
place during M115-M120.
During this origin trial we realized that the full capacity of the API 
couldn’t be tested due to a lack of support for third-party tokens. An 
Origin Trial extension 
 was 
necessary until M123.



Risks


Interoperability and Compatibility


/Gecko/: No signal 
(https://github.com/mozilla/standards-positions/issues/521)


Can you add a comment to this issue pointing to this I2S, and any 
relevant changes since the original issue was opened?


/WebKit/: Negative 
(https://lists.webkit.org/pipermail/webkit-dev/2021-May/031845.html) 
This issue has been taken into account: 
https://github.com/w3c/compute-pressure/issues/24


https://github.com/w3c/compute-pressure/issues/24#issuecomment-1022516116 
suggests asking for re-review once issue 24 is settled (at least that's 
my interpretation). Do you know if that ever happened?


/Web developers/: Positive 
(https://github.com/w3c/compute-pressure/issues/14)



/Other signals/:


Security

https://github.com/w3c/compute-pressure/issues/79


WebView application risks

No


Debuggability


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

No,
Windows, Linux, ChromeOs, Mac.

Support on Android (incl. Android WebView) has been deprioritized as 
there is no current way to access the telemetry needed after Android 
11, and the current partners we are engaging with have no need as they 
are using native solutions on Android at this point.



Is this feature fully tested by web-platform-tests

?

Yes
https://wpt.fyi/results/compute-pressure?run_id=5116280230641664

The wpt.fyi results are flaky due to WPT bug 44438 




DevTrial instructions

https://github.com/w3c/compute-pressure/blob/main/HOWTO.md


Flag name on chrome://flags

see https://github.com/w3c/compute-pressure/blob/main/HOWTO.md


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

https://crbug.com/1067627


Launch bug

https://crbug.com/1173266


Sample links

https://w3c.github.io/compute-pressure/demo


Estimated milestones

OriginTrial desktop extension



123

OriginTrial desktop last



118

OriginTrial desktop first



115

OriginTrial desktop last



94

OriginTrial desktop first



92

DevTrial on desktop



109


Anticipated spec changes

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5597608644968448


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/g/blink-d

Re: [blink-dev] Intent to Ship: FedCM CORS requirement on ID assertion endpoint

[Mike Taylor]

LGTM1

On 3/4/24 1:33 PM, Nicolás Peña wrote:

Contact emails

n...@chromium.org


Explainer

https://github.com/fedidcg/FedCM/issues/428 




Specification

https://github.com/fedidcg/FedCM/pull/547 




Summary

The fetches in the FedCM API are hard to reason about because of the 
properties required of them. While there is ongoing discussion 
regarding the accounts endpoint, there is broad consensus that the ID 
assertion endpoint should use CORS. This aligns security properties of 
this fetch more closely to other fetches in the web platform.



Blink component

Blink>Identity>FedCM 




TAG review

Not requesting a TAG review. We have already had extensive discussions 
with Fetch experts.



TAG review status

N/A


Risks

Interoperability and Compatibility

This is a backwards incompatible feature, but one that is warranted 
due to consensus reached by our security reviewers as well as other 
browser vendor engineers. We have a manageable list of IDPs that we 
know are using the FedCM API and we have reached out to all IDPs that 
are currently deploying FedCM to make sure that they won’t break with 
this change.




Gecko: Positive based on TPAC discussions and 
https://github.com/fedidcg/FedCM/issues/428 
. Not filing a standards 
position request for small additions at the explicit request from 
Firefox (they prefer PRs).



WebKit: Positive based on TPAC discussions and 
https://github.com/fedidcg/FedCM/issues/428 
. Recently, standards 
position requests for smaller FedCM features have been closed, 
pointing to the (unresolved) main FedCM one in 
https://github.com/WebKit/standards-positions/issues/309 
so not 
filing one for this.



Web developers: No signals


Other signals:


Ergonomics

N/A



Activation

N/A



Security

By adding CORS, we add a check that the IDP explicitly agrees for the 
browser to share the ID assertion response to the RP. In addition, 
having this fetch align with most other credentialed fetches in the 
browser means that any future protections are received by default, and 
we do not have to special case this fetch.




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

We surface errors when there is a network problem with the ID 
assertion fetch. This will help developers understand when this 
feature introduces a problem in their FedCM calls.




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


No. FedCM is not supported on Android WebView.


Is this feature fully tested by web-platform-tests 
? 



https://wpt.fyi/results/credential-management/fedcm-identity-assertion-nocors.https.html?label=experimental&label=master&aligned 
(will 
pass on Chrome once we ship)



Flag name on chrome://flags

None


Finch feature name

FedCmIdAssertionCORS


Requires code in //chrome?

True (because FedCM API does)


Tracking bug

https://issues.chromium.org/issues/40284123 




Estimated milestones

DevTrial on desktop


120



DevTrial on Android


120


We want to ship on M124


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).


https://github.com/whatwg/fetch/issues/1637


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5094763339710464 




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/1814484e-4a0c-4210-b936-29ead46f32c5n%40chromium.org 
.


--
You received this message because you are sub

Re: [blink-dev] Intent to Experiment: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Mike Taylor]

My concern is going from 1% to 50% on stable - if something does go 
wrong, that's a _lot_ of folks who will experience it. Are you open to 
something smaller like 5%? If not, why not?


thx

On 2/29/24 12:34 AM, Zheda Chen wrote:
The volume of data on Beta is too low to draw any conclusion. Although 
the experiment on 1% stable shows some promising result, the data are 
not enough and we'd like to gather more data via experiment on higher 
percentage of stable.
After that, based on large volume of data, we can draw the conclusion 
and decide next step (whether to ship the feature).


I contribute the idea and CL source code of this feature, Francois 
(fdoray@) is the main reviewer and the trial is planned by him. Let us 
know if you have any concerns and we can discuss with fdoray@ together.


"Unimportant" frames means they are cross-origin, visible but use 
non-large proportion (<75%) of page's visible area and have not 
received a user gesture. All 3 conditions should be met.


On Thursday, February 29, 2024 at 10:26:22 AM UTC+8 
mike...@chromium.org wrote:


Could you say more why you would like to experiment on 50% of
stable, vs requesting permission to ship? That's quite a leap from
1% - and it seems you already have results demonstrating
performance improvements.

Also, mind answering the question of specifying "unimportant frames"?

On 2/27/24 5:54 AM, Zheda Chen wrote:

fdoray@ launched this trial since Nov 2023, at first canary/dev,
and then beta, 1% stable. The experiments show statistically
improvements to CPU time on navigation, page load time and input
delay.
So we are requesting to experiment on 50% stable as next step.

Actually the feature should be in origin trial stage now. But I
don't have the permission to add origin trial stage. I have to
use dev trial instead. Need some help from webstatus-request@ to
grant me the permission.

On Tuesday, February 27, 2024 at 8:53:34 AM UTC+8
mike...@chromium.org wrote:

Hello,

To clarify: is this intended to be an I2E, or a Developer
Trial? According to
https://chromestatus.com/feature/5106220399853568, it appears
you are in the dev trial stage. But you mention stable
experiment below... so perhaps that's a process mistake?

Can you give more info on the experiment timelines and what
stable percentages you are requesting permission to
experiment on?

On 2/22/24 2:30 AM, Zheda Chen wrote:


Contact emails
zheda...@intel.com, fdo...@chromium.org

Specification
https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html

Summary

Align wake ups of JavaScript timers for unimportant
cross-origin frames. Currently, DOM timers <32ms are all
opt-out from AlignWakeUps [1] due to performance concerns.
This is very conservative and actually some unimportant
frames are eligible to use JS timer alignment. WebKit uses
the policy to align DOM timer of non-interacted cross origin
frames to 30ms. This feature adds JavaScript timer wake up
alignment for unimportant frames on foreground pages.
Unimportant frames means they are cross origin, visible but
have small proportion of page’s visible area, and have no
user interaction. [1]
https://chromium-review.googlesource.com/c/chromium/src/+/4589092


Do you have plans to specify this concept of "unimportant
frames" somewhere?



Blink component
Blink>PerformanceAPIs>Timers



TAG review
None

TAG review status
Not applicable

Risks


Interoperability and Compatibility

None



/Gecko/: No signal

/WebKit/: No signal

/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 experimentationWe plan to experiment on stable to
confirm whether we observe same performance improvement as
on lower channels and similar power benefit as in the lab.
We will decide whether this feature ships based on the
experiment data.


Ongoing technical constraints

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

?
No

Flag name on chrome://flags
 

Re: [blink-dev] Intent to Ship: Used color scheme root scrollbars

[Mike Taylor]

Thanks for the summary of the experiment results on Edge - sounds positive.

If this is purely a browser UI change, then we don't really need the 
blink-dev process at all. However, if we're relying on concepts defined 
in a CSSWG draft, and devs can change the outcome w/ some CSS (or maybe 
here, the lack of CSS to result in non-`normal` computed value...) it 
would be if there were interoperability in UI choices across browsers. I 
don't necessarily think we should block on the outcome, but requesting 
vendor positions could be useful.


(and Daniel, if you scroll down a bit - I did ask about TAG and browser 
signals. :))


On 3/2/24 1:10 PM, Daniel Bratell wrote:


Mike didn't refer to the TAG review or browser signals, but the review 
steps in chromestatus. The intent should request, privacy, security, 
enterprise, and the other steps there.


I agree that this lives in the borderland between user agent UI and a 
web visible change so some shortcuts might be possible to motivate, 
but you still need to click the the appropriate buttons in the 
chromestatus tool.


/Daniel

On 2024-03-01 21:10, 'Yaroslav Shalivskyy' via blink-dev wrote:


Hello Mike,

Thank you for taking a look!

I am seeking consensus on how to approach the feature from a 
standardization perspective. I think the feature can be considered a 
browser UI change, which is why I haven't requested a TAG review or 
signals from other engines. However, I am open to doing so if necessary.


I apologize for any confusion. We did the general experimentation in 
Edge (not the "origin trials" as I mentioned in the email). Retention 
reports were neutral, and we observed no regressions in scorecards. 
Also, we have not received any negative user feedback thus far.


I am working on requesting reviews for my chromestatus entry. Thanks 
for pointing this out!


Thanks,
Yaroslav


On Friday, March 1, 2024 at 5:52:55 AM UTC-8 mike...@chromium.org wrote:

Hi there,


Would you mind requesting reviews for the various review gates in
your chromestatus entry?


On 2/29/24 4:12 PM, 'Yaroslav Shalivskyy' via blink-dev wrote:



Contact emails

gerc...@microsoft.com, yshal...@microsoft.com


Explainer

None


Specification

https://www.w3.org/TR/css-color-adjust-1


Summary

Makes the browser use the user's preferred color scheme to
render the viewport scrollbars if the value of "page’s supported
color schemes" is 'normal' or not specified, and the computed
value of the color-scheme for the root element is 'normal'.
Viewport scrollbars can be considered to be outside the web
content. Therefore, the user agents should honor the user's
preferred color scheme when rendering viewport scrollbars if
page authors have not explicitly specified support for color
schemes.



Blink component

Blink>Layout>Scrollbars




TAG review

None


TAG review status

Not applicable

Any reason you think this is N/A, or have you just not requested
TAG review?



Risks


Interoperability and Compatibility

None



/Gecko/: No signal

/WebKit/: No signal

/Web developers/: No signals

/Other signals/:

Could we request signals please?



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

?

No


Flag name on chrome://flags

None


Finch feature name

UsedColorSchemeRootScrollbars


Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/issues/40259909


Measurement

Added a use counter UsedColorSchemeRootScrollbarsDark. The
counter tracks the number of users who have dark mode root
scrollbars due to the feature. Adoption in Edge Stable
population based on this metric is approximately 13%.


Availability expectation

Initially available in Chromium browsers.


Adoption expectation

This feature immediately affects specific use cases upon launch.


Adoption plan

This feature has been through origin trials on Edge. Other
browsers adopt this feature to fix specific use cases.

Any details or feedback you can share from the Origin Trial?



Non-OSS dependencies

/Does the 

Re: [blink-dev] Intent to Ship: Used color scheme root scrollbars

[Mike Taylor]

Hi there,


Would you mind requesting reviews for the various review gates in your 
chromestatus entry?



On 2/29/24 4:12 PM, 'Yaroslav Shalivskyy' via blink-dev wrote:



Contact emails

gerch...@microsoft.com , 
yshalivs...@microsoft.com 



Explainer

None


Specification

https://www.w3.org/TR/css-color-adjust-1 




Summary

Makes the browser use the user's preferred color scheme to render the 
viewport scrollbars if the value of "page’s supported color schemes" 
is 'normal' or not specified, and the computed value of the 
color-scheme for the root element is 'normal'. Viewport scrollbars can 
be considered to be outside the web content. Therefore, the user 
agents should honor the user's preferred color scheme when rendering 
viewport scrollbars if page authors have not explicitly specified 
support for color schemes.




Blink component

Blink>Layout>Scrollbars 




TAG review

None


TAG review status

Not applicable

Any reason you think this is N/A, or have you just not requested TAG review?



Risks


Interoperability and Compatibility

None



/Gecko/: No signal

/WebKit/: No signal

/Web developers/: No signals

/Other signals/:

Could we request signals please?



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

?

No


Flag name on chrome://flags

None


Finch feature name

UsedColorSchemeRootScrollbars


Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/issues/40259909 




Measurement

Added a use counter UsedColorSchemeRootScrollbarsDark. The counter 
tracks the number of users who have dark mode root scrollbars due to 
the feature. Adoption in Edge Stable population based on this metric 
is approximately 13%.



Availability expectation

Initially available in Chromium browsers.


Adoption expectation

This feature immediately affects specific use cases upon launch.


Adoption plan

This feature has been through origin trials on Edge. Other browsers 
adopt this feature to fix specific use cases.

Any details or feedback you can share from the Origin Trial?



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?/


No.


Estimated milestones

Shipping on desktop

124
DevTrial on desktop

121



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/5089486318075904 




Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/PH8PR00MB16366CA3D32D8ECE2C646C54A94D2%40PH8PR00MB1636.namprd00.prod.outlook.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/LV3PR00MB17488611D88C9E41AC6A806BA95F2%40LV3PR00MB1748.namprd00.prod.outlook.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:

Re: [blink-dev] Re: Intent to Ship: Attribution Reporting API Features (Trigger Data Customization and Aggregatable Value Filters)

[Mike Taylor]

Thank you for the code pointer (and education). LGTM3

On 2/26/24 2:00 PM, Nan Lin wrote:

Hi Mike,

The web API is not supported for WebView (
https://source.chromium.org/chromium/chromium/src/+/main:android_webview/browser/aw_content_browser_client.cc;l=1217?q=aw_content_browser_client&ss=chromium 
<https://source.chromium.org/chromium/chromium/src/+/main:android_webview/browser/aw_content_browser_client.cc;l=1217?q=aw_content_browser_client&ss=chromium>), 
and therefore these features in the web API are not supported for 
WebView, but may be supported when these features are supported in the 
Android API.


Thanks,
Nan

On Mon, Feb 26, 2024 at 1:53 PM Mike Taylor  
wrote:


Hi Akash,

Could you please clarify: if WebView supports the web API (which
it does, IIUC?), these new features also be supported in the
WebView context, correct?

I'm not able to find where the Attribution Reporting API is
_disabled_ for WebView (assuming it would be in

https://source.chromium.org/chromium/chromium/src/+/main:android_webview/browser/aw_field_trials.cc;l=72-73).

On 2/23/24 1:38 PM, 'Akash Nadan' via blink-dev wrote:

Hi Peter,

The Attribution Reporting Web API is currently not supported in
Android WebView, but events can be delegated to Android. These
extensions are only for the web API.

Thanks,
Akash

On Friday, February 23, 2024 at 2:45:11 AM UTC-8 Peter Beverloo
wrote:

Hi Akash - the Attribution Reporting API is supported in
Android WebView, why won't these extensions be?

Thanks,
Peter

On Thu, Feb 22, 2024 at 8:32 PM 'Akash Nadan' via blink-dev
 wrote:

Hi All,

We did not do an OT for these features. But we have
discussed and collected feedback regarding these features
with multiple ad-techs and have shared these features
during the WICG (web platform incubator community group)
weekly calls.

Thanks,
Akash

On Wednesday, February 21, 2024 at 8:57:48 AM UTC-8 Alex
Russell wrote:

Hey folks,

I also appreciate the quality of the design work
here, but we need developer interest to be able to
launch features out ahead of other engines. Was an OT
done? What other signals do we have to go on?

Best,

Alex

On Tuesday, February 20, 2024 at 10:56:21 PM UTC-8
Yoav Weiss wrote:

LGTM2

On Wednesday, February 21, 2024 at 6:02:29 AM
UTC+1 Domenic Denicola wrote:

LGTM1. I appreciate the detailed explainers
and well-reviewed spec updates.

I noticed the TAG review field was missing,
but it seems the TAG review for the base
feature is still ongoing
<https://github.com/w3ctag/design-reviews/issues/724> 
since
2022-03-24, so I agree with the decision to
not derailing that ongoing review by
requesting additional review for small
additions like this.

On Tuesday, February 13, 2024 at 3:12:22 AM
UTC+9 Akash Nadan wrote:

Contact emails

akash...@google.com, lin...@chromium.org,
john...@chromium.org


Explainer

Attribution Reporting with event-level
reports

<https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md>

Attribution Reporting API with
Aggregatable Reports

<https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATE.md>

Aggregation Service for the Attribution
Reporting API

<https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATION_SERVICE_TEE.md>


Specification

https://wicg.github.io/attribution-reporting-api/
<https://wicg.github.io/attribution-reporting-api/>


Blink component

Internals > AttributionReporting

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EAttributionReporting>


Summary

We plan on landing the follow

Re: [blink-dev] Intent to Ship: Sec-CH-UA-Form-Factor client hint

[Mike Taylor]

(non-owner hat on) - Thanks for flagging, Domenic. We'll re-ping the 
thread once we decide if we should rename it, and to what.


On 2/28/24 9:43 PM, Domenic Denicola wrote:
I've raised a potentially-breaking spec issue which I'd like to get a 
conclusion on before LGTMing this: 
https://github.com/WICG/ua-client-hints/issues/355


On Thursday, February 29, 2024 at 2:03:07 AM UTC+9 Yoav Weiss wrote:

LGTM2

On Wed, Feb 21, 2024 at 6:04 PM Vladimir Levin
 wrote:



On Wed, Feb 21, 2024 at 11:25 AM Dustin Mitchell
 wrote:

Thanks for the comments!

On Tue, Feb 20, 2024 at 11:10 AM Vladimir Levin
 wrote:



On Tue, Feb 20, 2024 at 7:06 AM 'Dustin Mitchell' via
blink-dev  wrote:


Contact emails

djmit...@chromium.org


Explainer


https://github.com/djmitche/web-explainers/blob/main/sec-ch-ua-form-factor.md




Specification


https://wicg.github.io/ua-client-hints/#sec-ch-ua-form-factor




Design docs



https://github.com/djmitche/web-explainers/blob/main/sec-ch-ua-form-factor.md




Summary

This hint indicates the "form-factor" of the
user-agent / device, so that the site can tailor
its response.



Blink component

Blink>Network




Search tags

ua-ch
,
uach
,
form-factor



TAG review

This feature simply adds a new hint to the
existing set of hints, containing data that was
previously represented in the user-agent string.


Although this info may be available, I suspect this
can be a new channel of information for clients that
override the user-agent string or where this
information isn't provided in the user-agent string. I
don't believe this to be a problem, but just something
to consider


That's a good point, and likely needs to be considered for
all client hints. Do you think it's worth adding an issue
in https://github.com/WICG/ua-client-hints
 to track this?


I don't feel particularly strongly about this, but raising the
issue to invite more opinions seems worthwhile.




TAG review status

Not applicable


Risks



Interoperability and Compatibility

If other browsers do not implement this hint, then
the information will only be available in Chrome,
and other browsers will implicitly return an empty
value.



/Gecko/: No signal

/WebKit/: No signal


Can you please file requests for positions for both
Gecko and WebKit?


Gecko:
https://mozilla.github.io/standards-positions/#ua-client-hints

Webkit:

https://lists.webkit.org/pipermail/webkit-dev/2024-February/032618.html




Thank you for doing this. For posterity in the future, for
WebKit, it might be better to file an issue here:
https://github.com/WebKit/standards-positions/issues




/Web developers/: No signals

/Other signals/:


Ergonomics

None - this fits with existing, similar client hints.



Activation

No activation risks - developers will always need
to handle the situation where this hint is
unavailable.



Security

  

Re: [blink-dev] Intent to Ship: Form Controls Support Vertical Writing Mode Direction Support

[Mike Taylor]

LGTM2

On 2/28/24 9:37 PM, Domenic Denicola wrote:
With my HTML editor hat on, I can confirm the spec PR looks good and 
only has editorial issues left. It fell between the cracks for 2 
weeks; apologies for that.


With my API Owner hat on, LGTM1. There are a few borderline aspects here:

  * Security review on ChromeStatus has not yet been completed.
However, I trust you will not ship this until that is resolved.
  * Technically this does not yet meet the criteria for being exempt
from TAG review
,
since Safari has only shipped to beta and the specification isn't
yet merged. However, as mentioned above the spec PR is in good
shape, and I think it's unlikely to be worth the TAG's time to
perform a review at this stage, for a small change of this sort.


On Thu, Feb 29, 2024 at 8:13 AM Di Zhang  wrote:

Based on the release note, the Webkit implementation is already
implemented and currently shipping. Everything vertical
writing-mode related is shipping, including the changes included
in this feature.

https://developer.apple.com/documentation/safari-release-notes/safari-17_4-release-notes

For Gecko, there has been no update. The bug has been open for a year.
https://bugzilla.mozilla.org/show_bug.cgi?id=1801791

This feature is adding a few new WPT tests (listed in the HTML
spec PR description [1], specifically [2]).

> How far is this from being merged?
The comments are addressed and I am pinging the HTML reviewers to
take a final look.

[1] https://github.com/whatwg/html/pull/10096
[2]

https://github.com/web-platform-tests/wpt/commit/7f56feea538b986d5681532c0dcba8c9773cd6c4




On Wednesday, February 28, 2024 at 5:17:47 AM UTC-8 Manuel Rego wrote:



On 23/02/2024 21:42, Di Zhang wrote:
> Specification
>
> https://github.com/whatwg/html/issues/8413
> 

What's the status of this issue? Is there any spec text that
needs to
change?

> Interoperability and Compatibility
>
> Chrome: implemented behind flag Safari: implemented behind
flag Firefox:
> implemented for  in stable, issue created for
> meter/progress.
>
>
>
> /Gecko/: No signal

It seems something is implemented already and you mention
there's a bug
for some other things, could you link that bug? Are they
currently
working on it?

> /WebKit/: In development
>

(https://developer.apple.com/documentation/safari-release-notes/safari-17_4-release-notes

)
Added support for vertical writing mode support for form
controls. (12072686)

Has this actually shipped in WebKit or is "in development"?

You first mentioned "Safari: implemented behind flag", but you're
linking to some release notes.

Which parts are shipped in Safari and which are not yet?

> Is this feature fully tested by web-platform-tests
>

?

>
> Yes
>
>

https://wpt.fyi/results/css/css-writing-modes/forms?label=master&label=experimental&product=chrome&product=firefox&product=safari&aligned&view=interop&q=label%3Ainterop-2022-forms%20or%20label%3Ainterop-2023-forms



>


These tests are all passing in Chrome and Safari (only 3
failing in
Firefox). Is this feature adding new tests?

> 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).
>
> HTML spec currently under r

Re: [blink-dev] Intent to Experiment: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Mike Taylor]

Could you say more why you would like to experiment on 50% of stable, vs 
requesting permission to ship? That's quite a leap from 1% - and it 
seems you already have results demonstrating performance improvements.


Also, mind answering the question of specifying "unimportant frames"?

On 2/27/24 5:54 AM, Zheda Chen wrote:
fdoray@ launched this trial since Nov 2023, at first canary/dev, and 
then beta, 1% stable. The experiments show statistically improvements 
to CPU time on navigation, page load time and input delay.

So we are requesting to experiment on 50% stable as next step.

Actually the feature should be in origin trial stage now. But I don't 
have the permission to add origin trial stage. I have to use dev trial 
instead. Need some help from webstatus-request@ to grant me the 
permission.


On Tuesday, February 27, 2024 at 8:53:34 AM UTC+8 mike...@chromium.org 
wrote:


Hello,

To clarify: is this intended to be an I2E, or a Developer Trial?
According to https://chromestatus.com/feature/5106220399853568, it
appears you are in the dev trial stage. But you mention stable
experiment below... so perhaps that's a process mistake?

Can you give more info on the experiment timelines and what stable
percentages you are requesting permission to experiment on?

On 2/22/24 2:30 AM, Zheda Chen wrote:


Contact emails
zheda...@intel.com, fdo...@chromium.org

Specification
https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html

Summary

Align wake ups of JavaScript timers for unimportant cross-origin
frames. Currently, DOM timers <32ms are all opt-out from
AlignWakeUps [1] due to performance concerns. This is very
conservative and actually some unimportant frames are eligible to
use JS timer alignment. WebKit uses the policy to align DOM timer
of non-interacted cross origin frames to 30ms. This feature adds
JavaScript timer wake up alignment for unimportant frames on
foreground pages. Unimportant frames means they are cross origin,
visible but have small proportion of page’s visible area, and
have no user interaction. [1]
https://chromium-review.googlesource.com/c/chromium/src/+/4589092


Do you have plans to specify this concept of "unimportant frames"
somewhere?



Blink component
Blink>PerformanceAPIs>Timers



TAG review
None

TAG review status
Not applicable

Risks


Interoperability and Compatibility

None



/Gecko/: No signal

/WebKit/: No signal

/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 experimentationWe plan to experiment on stable to
confirm whether we observe same performance improvement as on
lower channels and similar power benefit as in the lab. We will
decide whether this feature ships based on the experiment data.


Ongoing technical constraints

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

?
No

Flag name on chrome://flags
None

Finch feature name
ThrottleUnimportantFrameTimers

Requires code in //chrome?
False

Tracking bug
https://issues.chromium.org/issues/40942028

Estimated milestones
DevTrial on desktop
122
DevTrial on Android
122

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

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+...@chromium.org.
To view this discussion on the web visit

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/38855cfe-3bf3-4a04-b96a-81adaa5ba72fn%40chromium.org

.




--
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/efba3840-d118-488f-85ed-e62cf81f34b4%40chromium.org.

Re: [blink-dev] Intent to Experiment: FedCM multi IDP in single get() call

[Mike Taylor]

Could you please request reviews for the privacy/security/debuggability 
review gates in your chromestatus entry?


On 2/21/24 3:21 PM, Nicolás Peña wrote:

Contact emails

n...@chromium.org


Explainer

The Federated Credential Management (FedCM) API currently only allows 
one identity provider (IDP) to be used when performing federated login 
in a website. We would like to experiment with allowing multiple 
providers to be specified in a single JavaScript get() call, which 
allows FedCM to be used in cases for which the website supports 
multiple IDPs for federation. See also additional context in 
https://github.com/fedidcg/FedCM/issues/319 
.



Specification

https://fedidcg.github.io/FedCM 


Summary

Allows FedCM to show multiple IDPs in the same dialog. This provides 
developers with a convenient way to present all supported identity 
providers to users. In this I2E, we are tackling the simple case of 
having all providers in the same get() call, while building much of 
the UX infratructure that will allow us to tackle more sophisticated 
production structures later.




Blink component

Blink>Identity>FedCM 




TAG review

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




TAG review status

Pending


Risks

Interoperability and Compatibility

This should not have additional interop risks on top of the existing 
FedCM API which is generally supported but not yet implemented by 
Firefox and Safari. In order to determine whether multiple IDPs are 
supported in a browser which supports FedCM, the developer can attempt 
to first call get() with multiple IDPs. It will be rejected 
immediately if not supported and the RP can retry with a single IDP.




Gecko: No signal 
(https://github.com/mozilla/standards-positions/issues/730 
)



WebKit: No signal 
(https://github.com/WebKit/standards-positions/issues/120 
)



Web developers: Positive (https://github.com/fedidcg/FedCM/issues/319 
)



Other signals:


Ergonomics

Using this API will just require expanding the get() to use more 
providers, so it will benefit from the ergonomics of the initial FedCM 
API.




Activation

The main activation issue is having to include all IDPs in the same 
get() call, which may be challenging in some cases because IDPs 
generally are independent from each other. That said, we do have 
developers who can use the single get() call, so we wish to start with 
the simpler version of multi IDP support.




Security

The security considerations are similar to those of the single IDP 
case. We do not require users to input usernames and passwords due to 
spoofing concerns, and we also have input protection to prevent 
accidental click right after the UI is shown.




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?


n/a, FedCM is not supported on WebView



Goals for experimentation

We want to ensure that the single get() call is sufficient for the use 
cases we are targeting, where the multiple IDPs are owned by a single 
entity, as well as gather developer feedback before fully shipping. 
The multiple independent IDPs scenario is out of scope for 
experimentation, as we anticipate that it will be hard to impossible 
to use FedCM in a single get() call in such a scenario.



A successful trial would result in our partner requesting us to ship 
this feature to allow using FedCM with their multiple IDPs.



Ongoing technical constraints

None



Debuggability

The debug tools are similar to that of original FedCM: console 
messages and DevTools issues. Seeing FedCM network requests is not 
supported in DevTools but can be achieved via chrome://net-export.




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


No

As with the initial FedCM, we do not support Android WebView.



Is this feature fully tested by web-platform-tests 
? 



Yes

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/credential-management/fedcm-multi-idp/ 
Some 
of these tests are not relevant as they are related to the multi-get() 
approach.




Flag name on chrome://flags

FedCmMultiIdp


Finch feature name

FedCmMultipleIdentityProviders


Requires code in //chrome?

True


Tracking bug

https://bugs.chromium

Re: [blink-dev] Intent to Experiment: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Mike Taylor]

Hello,

To clarify: is this intended to be an I2E, or a Developer Trial? 
According to https://chromestatus.com/feature/5106220399853568, it 
appears you are in the dev trial stage. But you mention stable 
experiment below... so perhaps that's a process mistake?


Can you give more info on the experiment timelines and what stable 
percentages you are requesting permission to experiment on?


On 2/22/24 2:30 AM, Zheda Chen wrote:


Contact emails
zheda.c...@intel.com, fdo...@chromium.org

Specification
https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html

Summary

Align wake ups of JavaScript timers for unimportant cross-origin 
frames. Currently, DOM timers <32ms are all opt-out from AlignWakeUps 
[1] due to performance concerns. This is very conservative and 
actually some unimportant frames are eligible to use JS timer 
alignment. WebKit uses the policy to align DOM timer of non-interacted 
cross origin frames to 30ms. This feature adds JavaScript timer wake 
up alignment for unimportant frames on foreground pages. Unimportant 
frames means they are cross origin, visible but have small proportion 
of page’s visible area, and have no user interaction. [1] 
https://chromium-review.googlesource.com/c/chromium/src/+/4589092



Do you have plans to specify this concept of "unimportant frames" somewhere?



Blink component
Blink>PerformanceAPIs>Timers 



TAG review
None

TAG review status
Not applicable

Risks


Interoperability and Compatibility

None



/Gecko/: No signal

/WebKit/: No signal

/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 experimentationWe plan to experiment on stable to confirm 
whether we observe same performance improvement as on lower channels 
and similar power benefit as in the lab. We will decide whether this 
feature ships based on the experiment data.


Ongoing technical constraints

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 
?

No

Flag name on chrome://flags
None

Finch feature name
ThrottleUnimportantFrameTimers

Requires code in //chrome?
False

Tracking bug
https://issues.chromium.org/issues/40942028

Estimated milestones
DevTrial on desktop
122
DevTrial on Android
122

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

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/38855cfe-3bf3-4a04-b96a-81adaa5ba72fn%40chromium.org 
.


--
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/6f43eb59-d6d5-4ac3-86c4-ba1c93b77387%40chromium.org.

Re: [blink-dev] Intent to ship: MP4 container support for MediaRecorder

[Mike Taylor]

On 2/22/24 9:21 PM, 'Sunggook Chue' via blink-dev wrote:

Contact emails

sung...@microsoft.com 


dalecur...@chromium.com (reviewer and 
mentor).



Explainer

https://www.w3.org/TR/mediastream-recording/


Specification

https://www.w3.org/TR/mediastream-recording/


Summary

Adds support for muxing audio/video into MP4 containers with 
MediaRecorder.



Developers can record media format, container, with MP4 of H264 video 
and AAC audio codecs in the MediaRecorder API.




Blink component

Blink::MediaRecording


TAG review
TAG review status
Risks

No Additional risks on existing containers such as webm.


Interoperability and Compatibility


This is missing vendor and developer signals - can you add (or request) 
them please?



Ergonomics

N/A



Activation

Unchallenging to use.



Security

N/A



WebView Application Risks

N/A



Debuggability

Developers can see the API failure on DevTools.


Is this feature fully tested by web-platform-tests 
? 



Yes


Flag name

MediaRecorderEnableMp4Muxer


Tracking bug

https://issues.chromium.org/issues/40127044


Launch bug

https://issues.chromium.org/issues/40127044


Sample links

https://webrtc.github.io/samples/src/content/getusermedia/record/


Estimated milestones

Dev Trial on Desktop: 120



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5163469011943424


Links to previous Intent discussions

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/1dd6d89b-34f4-4f18-b3e8-c1309d479530n%40chromium.org 
.


--
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/8119a014-24b2-487e-bbbd-324c1bf77081%40chromium.org.

Re: [blink-dev] Intent to Experiment: FedCM Button Mode API and Use Other Account API

[Mike Taylor]

That said, please request approvals from the various review gates in 
your chromestatus entry before experimenting.


On 2/26/24 7:41 PM, Mike Taylor wrote:


LGTM to experiment from M124 to M127 inclusive.

On 2/26/24 5:45 PM, Yi Gu wrote:



Contact emails


*

y...@chromium.org, cbiesin...@chromium.org,
tanzach...@chromium.org


*


Explainer


*

https://github.com/fedidcg/FedCM/issues/442
<https://github.com/fedidcg/FedCM/issues/442#issuecomment-1949323416>


*


Specification


*

https://fedidcg.github.io/FedCM <https://fedidcg.github.io/FedCM>

This will be added as an extension.


*


Summary


*

We plan to experiment with two new extensions for the
Federated Credential Management (FedCM) API:


 *

Button Mode API

 o

The button mode lets websites trigger FedCM directly
when a user clicks a button (like a "Sign-in with
IdP" button). This means FedCM will always display a
visible user interface for login, in contrast to the
widget mode where no UI is shown if a user’s login
status is logged out.

 o

When the FedCM API is used in "button mode" and a
user isn't logged in, they'll be taken to the IdP
login screen (in a pop-up window). Since this happens
in response to a clear user action, the UI might even
be more prominent (e.g., centered and modal) compared
to the more subtle UI of widget mode.


 *

Use Other Account API

 o

With this API, an Identity Provider can request the
browser to show a button that allows users to choose
other accounts.



*


Blink component


*

Blink>Identity>FedCM

<https://issues.chromium.org/u/1/issues?q=status:open%20componentid:1456331&s=created_time:desc>


*


Search tags


*

fedcm <https://chromestatus.com/features#fedcm>


*


TAG review


*

https://github.com/w3ctag/design-reviews/issues/935
<https://github.com/w3ctag/design-reviews/issues/935>


*


TAG review status


*

Pending


*


Risks


*

*


Interoperability and Compatibility


*

These are extensions to the FedCM API. Apple and Mozilla have
both expressed a positive opinion on the initial FedCM API
[1]. They have not yet shipped but Mozilla is prototyping
[2]. If a user agent chooses not to implement these
extensions, the sign-in flow should not be affected in that
user agent because developers can fallback to the existing
federated sign-in mechanisms.


[1]

https://groups.google.com/a/chromium.org/g/blink-dev/c/URpYPPH-YQ4/m/bzghj9N3AQAJ

<https://groups.google.com/a/chromium.org/g/blink-dev/c/URpYPPH-YQ4/m/bzghj9N3AQAJ>

[2]

https://groups.google.com/a/mozilla.org/g/dev-platform/c/ncmUwK1uO98/m/COhPA4ZrAAAJ

<https://groups.google.com/a/mozilla.org/g/dev-platform/c/ncmUwK1uO98/m/COhPA4ZrAAAJ>


Gecko: No signal


WebKit: No signal


Web developers: Positive
(https://github.com/fedidcg/FedCM/issues/442
<https://github.com/fedidcg/FedCM/issues/442>) These features
are being developed to address existing feedback for the
FedCM API.


Other signals:


*


Activation


*

Similar to the FedCM API, we deliberately leave the bulk of
the work to the IdP to ensure that minimal RP change is needed.


This feature, specifically, is one that can be currently
controlled by IdP (via JS SDK for “button mode”, via
server-side config for “use other account”), so we expect
activation to have a similar profile as FedCM: immediately
enabled to websites (without redeployment) by IdPs making use
of it (by redeploying their JS SDKs).



*


Security


*

The button mode shares most of the security properties from
the widget mode. e.g. honoring CSP, CORS, using security
headers, not asking users to type in the browser UI etc.


It’s worth noting that the pop-up window has the same web
platform properties as what one would get with
window.open(url,””,”popup,noopener,noreferrer”)that loads the
login_url. It is important to note that there's no
communication allowed between the website and this pop-up
(e.g. no postMessage, no wind

Re: [blink-dev] Intent to Experiment: FedCM Button Mode API and Use Other Account API

[Mike Taylor]

LGTM to experiment from M124 to M127 inclusive.

On 2/26/24 5:45 PM, Yi Gu wrote:



Contact emails


*

y...@chromium.org, cbiesin...@chromium.org,
tanzach...@chromium.org


*


Explainer


*

https://github.com/fedidcg/FedCM/issues/442



*


Specification


*

https://fedidcg.github.io/FedCM 

This will be added as an extension.


*


Summary


*

We plan to experiment with two new extensions for the
Federated Credential Management (FedCM) API:


 *

Button Mode API

 o

The button mode lets websites trigger FedCM directly
when a user clicks a button (like a "Sign-in with IdP"
button). This means FedCM will always display a
visible user interface for login, in contrast to the
widget mode where no UI is shown if a user’s login
status is logged out.

 o

When the FedCM API is used in "button mode" and a user
isn't logged in, they'll be taken to the IdP login
screen (in a pop-up window). Since this happens in
response to a clear user action, the UI might even be
more prominent (e.g., centered and modal) compared to
the more subtle UI of widget mode.


 *

Use Other Account API

 o

With this API, an Identity Provider can request the
browser to show a button that allows users to choose
other accounts.



*


Blink component


*

Blink>Identity>FedCM




*


Search tags


*

fedcm 


*


TAG review


*

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



*


TAG review status


*

Pending


*


Risks


*

*


Interoperability and Compatibility


*

These are extensions to the FedCM API. Apple and Mozilla have
both expressed a positive opinion on the initial FedCM API
[1]. They have not yet shipped but Mozilla is prototyping [2].
If a user agent chooses not to implement these extensions, the
sign-in flow should not be affected in that user agent because
developers can fallback to the existing federated sign-in
mechanisms.


[1]

https://groups.google.com/a/chromium.org/g/blink-dev/c/URpYPPH-YQ4/m/bzghj9N3AQAJ



[2]

https://groups.google.com/a/mozilla.org/g/dev-platform/c/ncmUwK1uO98/m/COhPA4ZrAAAJ




Gecko: No signal


WebKit: No signal


Web developers: Positive
(https://github.com/fedidcg/FedCM/issues/442
) These features
are being developed to address existing feedback for the FedCM
API.


Other signals:


*


Activation


*

Similar to the FedCM API, we deliberately leave the bulk of
the work to the IdP to ensure that minimal RP change is needed.


This feature, specifically, is one that can be currently
controlled by IdP (via JS SDK for “button mode”, via
server-side config for “use other account”), so we expect
activation to have a similar profile as FedCM: immediately
enabled to websites (without redeployment) by IdPs making use
of it (by redeploying their JS SDKs).



*


Security


*

The button mode shares most of the security properties from
the widget mode. e.g. honoring CSP, CORS, using security
headers, not asking users to type in the browser UI etc.


It’s worth noting that the pop-up window has the same web
platform properties as what one would get with
window.open(url,””,”popup,noopener,noreferrer”)that loads the
login_url. It is important to note that there's no
communication allowed between the website and this pop-up
(e.g. no postMessage, no window.opener). We have shipped
LoginStatus API and Error API in FedCM that use this type of
pop-up window.



*


WebView application risks


*

Does this intent deprecate or change behavior of existing
  

Re: [blink-dev] Intent to Ship: ServiceWorker static routing API

[Mike Taylor]

LGTM3

On 2/26/24 5:39 PM, Domenic Denicola wrote:

LGTM2

On Tue, Feb 27, 2024 at 1:33 AM Chris Harrelson 
 wrote:


I see the main spec PR has landed and a small related Fetch PR is
done. Thanks all for doing that!

LGTM1


On Tue, Feb 13, 2024 at 8:55 PM Domenic Denicola
 wrote:

At the moment it appears the spec is not complete, as a
possibly-large chunk of behavior (regarding request/response
reuse that modifies the behavior of fetch() inside service
worker fetch handlers) needs to have its spec written:

https://github.com/yoshisatoyanagisawa/ServiceWorker/pull/10/files#r1483835014

On Wed, Feb 14, 2024 at 10:39 AM Yoshisato Yanagisawa
 wrote:

Do you have any other questions? concerns? comments?
There were many Intent to Ship/Experiment emails at the
same time, and I am afraid this mail thread was overlooked.


2024年2月9日(金) 14:20 Yoshisato Yanagisawa
:



2024年2月9日(金) 13:20 Vladimir Levin
:



On Thu, Feb 8, 2024, 22:56 Yoshisato Yanagisawa
 wrote:

Contact emails

yyanagis...@chromium.org, sisidov...@chromium.org


Explainer


https://github.com/WICG/service-worker-static-routing-api




Specification

https://github.com/w3c/ServiceWorker/pull/1701



Summary

This API allows developers to configure the
routing, and allows them to offload simple
things ServiceWorkers do.  If the condition
matches, the navigation happens without
starting ServiceWorkers or executing
JavaScript, which allows web pages to avoid
performance penalties due to ServiceWorker
interceptions.



Blink component

Blink>ServiceWorker




TAG review

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



TAG review status

Issues addressed


Chromium Trial Name

ServiceWorkerStaticRouter


Link to origin trial feedback summary


https://docs.google.com/document/d/1mE3tngHQdz0s66Z_iIGksFxQui3taogP8pDafLUHMEg/edit#heading=h.ia9i7k1ocjnq




I just want to say that it's heartening to see OT
feedback being taken seriously and addressed in
rigorous manner.


Thank you.



Origin Trial documentation link


https://github.com/WICG/service-worker-static-routing-api?tab=readme-ov-file#origin-trial




Risks



Interoperability and Compatibility



Gecko: Positive

(https://github.com/mozilla/standards-positions/issues/828

)


WebKit: No signal

(https://github.com/WebKit/standards-positions/issues/206

)
Informal positive signals at TPAC, but no
official standards position.


It seems like the only concerns with this proposal
(in TAG and elsewhere) was the status of
URLPattern in the spec, but that has been since
resolved. Is this your understanding as well?


Yes.  I think we are on the same page.
As I have left a comment in the WebKit link,
URLPattern has already become the standard, and is
actively maintained.


Web developers: Positive
(https://github.com/w3c/ServiceWorker/issues/1373

Re: [blink-dev] Re: Intent to Ship: Attribution Reporting API Features (Trigger Data Customization and Aggregatable Value Filters)

[Mike Taylor]

Hi Akash,

Could you please clarify: if WebView supports the web API (which it 
does, IIUC?), these new features also be supported in the WebView 
context, correct?


I'm not able to find where the Attribution Reporting API is _disabled_ 
for WebView (assuming it would be in 
https://source.chromium.org/chromium/chromium/src/+/main:android_webview/browser/aw_field_trials.cc;l=72-73).


On 2/23/24 1:38 PM, 'Akash Nadan' via blink-dev wrote:

Hi Peter,

The Attribution Reporting Web API is currently not supported in 
Android WebView, but events can be delegated to Android. These 
extensions are only for the web API.


Thanks,
Akash

On Friday, February 23, 2024 at 2:45:11 AM UTC-8 Peter Beverloo wrote:

Hi Akash - the Attribution Reporting API is supported in Android
WebView, why won't these extensions be?

Thanks,
Peter

On Thu, Feb 22, 2024 at 8:32 PM 'Akash Nadan' via blink-dev
 wrote:

Hi All,

We did not do an OT for these features. But we have discussed
and collected feedback regarding these features with multiple
ad-techs and have shared these features during the WICG (web
platform incubator community group) weekly calls.

Thanks,
Akash

On Wednesday, February 21, 2024 at 8:57:48 AM UTC-8 Alex
Russell wrote:

Hey folks,

I also appreciate the quality of the design work here, but
we need developer interest to be able to launch features
out ahead of other engines. Was an OT done? What other
signals do we have to go on?

Best,

Alex

On Tuesday, February 20, 2024 at 10:56:21 PM UTC-8 Yoav
Weiss wrote:

LGTM2

On Wednesday, February 21, 2024 at 6:02:29 AM UTC+1
Domenic Denicola wrote:

LGTM1. I appreciate the detailed explainers and
well-reviewed spec updates.

I noticed the TAG review field was missing, but it
seems the TAG review for the base feature is still
ongoing
 since
2022-03-24, so I agree with the decision to not
derailing that ongoing review by requesting
additional review for small additions like this.

On Tuesday, February 13, 2024 at 3:12:22 AM UTC+9
Akash Nadan wrote:

Contact emails

akash...@google.com, lin...@chromium.org,
john...@chromium.org


Explainer

Attribution Reporting with event-level reports



Attribution Reporting API with Aggregatable
Reports



Aggregation Service for the Attribution
Reporting API




Specification

https://wicg.github.io/attribution-reporting-api/



Blink component

Internals > AttributionReporting




Summary

We plan on landing the following changes to
the Attribution Reporting API focused on:

 *

additional API configurability for
event-level reporting by supporting
customization for trigger data cardinality
and values

 *

additional API configurability for summary
reports by supporting filters in
aggregatable values


Explainer/Spec changes

  * Allow sources to customize trigger data
cardinality and values


  * Allow trigger side filtering on
aggregation keys




Risks
Interoperability and Compatibility

Both features are fully backwards compatible
   

Re: [blink-dev] Problem chrome after upgrade to 122

[Mike Taylor]

Hello,

Could you please file a bug at crbug.com/new, with steps to reproduce 
and (ideally) a publicly accessible URL? It's not obvious what "big-IP 
Technology" is.


thanks,
Mike

On 2/26/24 5:48 AM, argane jalal wrote:

hi,
I have application exécute with big-IP Technology this application 
work fine in chrome 121 but after upgrade to 122 this not working.


I resolve this problem after disable flags "Latest stable JavaScript 
features".


can you help me for resolve this problème but not change this flags.


thanks
--
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/aa37d6e4-2aaa-4e4b-92bc-975a0828835cn%40chromium.org 
.


--
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/07e4eb07-7087-4130-b121-fcc7c063db96%40chromium.org.

Re: [blink-dev] Intent to Prototype and Ship: Standardized CSS zoom

[Mike Taylor]

Thanks for the feedback Noam - would you mind filing a bug at 
crbug.com/new that contains some steps to reproduce the breakage, and 
possibly some affected codepaths and report back here? Agree that 
breaking Excel is not a great outcome.


On 2/26/24 10:01 AM, Noam Helfman wrote:

Great to see work is being done to get this standardized!

However, I think it should not be shipped yet.

We have done some basic testing of this feature with Excel Online and 
it breaks lots of critical user scenarios related to our zoom feature. 
This will impact many millions of users and regress a major feature.


We will need to spend time to investigate if there is a simple 
workaround that we can use to address this regression.


Few questions:
1. What is the expected timeline to ship this?
2. Is there an option to programatically determine if the feature is 
enabled? (e.g. would /CSS.supports("zoom")/ return /true/? )

3. Will there be an option to enable/disable it (e.g. release with OT)?

Please do not ship this until we can confirm we have a workaround or 
the API is adapted in a way that does not regress existing behavior.


Thanks,
Noam
On Thursday, February 15, 2024 at 12:18:06 PM UTC+2 Daniel Bratell wrote:

Same for me. A proprietary long term CSS property is now fully
standardized and will be interoperable. This is a win for the web,
and thank you for all who worked to make it happen!

/Daniel

On 2024-02-14 18:13, Yoav Weiss (@Shopify) wrote:

Just wanted to say that it's exciting to see this standardized
after all these years. Given the manual inspection, it seems like
shipping this to 100% with a killswitch is (hopefully) safe enough!

On Wed, Feb 14, 2024 at 6:11 PM Yoav Weiss (@Shopify)
 wrote:

LGTM3

On Wed, Feb 14, 2024 at 6:00 PM Philip Jägenstedt
 wrote:

LGTM2

On Wed, Feb 14, 2024 at 11:53 PM Daniel Bratell
 wrote:
>
> LGTM1
>
> /Daniel
>
> On 2024-02-09 20:24, 'Yotam Hacohen' via blink-dev wrote:
>
>
>
> On Thursday, February 8, 2024 at 6:46:00 PM UTC-8
Domenic Denicola wrote:
>
> On Fri, Feb 9, 2024 at 10:55 AM Yotam Hacohen
 wrote:
>
> Hey Dominic and thanks for the input!
>
> On Sunday, February 4, 2024 at 7:34:53 PM UTC-8 Domenic
Denicola wrote:
>
> It's always exciting to move such an old feature from
nonstandard to standardized!
>
> On Sat, Feb 3, 2024 at 4:18 AM 'Yotam Hacohen' via
blink-dev  wrote:
>
> Contact emailsyo...@google.com
>
> ExplainerNone
>
>
> FWIW, I think the contents of
https://github.com/w3c/csswg-drafts/pull/9699 and
https://drafts.csswg.org/css-viewport/#zoom-property are
probably a good enough explainer. It might be a good idea
to update ChromeStatus to link to them.
>
> Added those. Thanks!
>
>
>
>
>
>
Specificationhttps://github.com/w3c/csswg-drafts/pull/9699

>
> Design

docshttps://docs.google.com/document/d/1AcnDShjT-kEuRaMchZPm5uaIgNZ4OiYtM4JI9qiV8Po/edit


>
> Summary
>
> Aligns the existing implementation of the previously
non-standard CSS zoom property to align with the new
standard. This changes various JS APIs to align with the
spec (see design doc), change zoom to apply to iframes,
and change it to apply to all inherit all length
properties (currently it only changes inherited font-size)
>
>
> Blink componentBlink>Paint
>
> TAG reviewNone
>
> TAG review statusPending
>
>
> Probably this fits under the first exception here.
>
>
>
>
> Risks
>
> Interoperability and Compatibility
>
> There is web compatibility risk for these changes.
However, previous research indicates broken content due
to unexpected changes of the JS APIs is very unlikely,
since: * The changes to the JS API simply change the
coordinate space of the responses, not the syntax or what
APIs are available. * Most pages found during the
research didn't appear to use CSS zoom at all 

Re: [blink-dev] Intent to Ship: CSSImportRule.styleSheet

[Mike Taylor]

On 2/23/24 8:31 AM, Amos Lim wrote:



Contact emails

eui-sang@samsung.com


Explainer

None
Would you mind explaining why this is a useful addition for developers? 
Or is the motivation improved spec compliance?



Specification

https://drafts.csswg.org/cssom/#the-cssimportrule-interface


Summary

Allow CSSImportRule.styleSheet to be nullable. The styleSheet 
attribute in CSSImportRule can be null if there is no associated CSS 
style sheet.




Blink component

Blink>CSS 




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: Shipped/Shipping

/WebKit/: No signal

Can you request a signal? https://github.com/WebKit/standards-positions


/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)?

No


Is this feature fully tested by web-platform-tests

?

Yes

https://wpt.fyi/results/css/cssom/cssimportrule.html?label=experimental&label=master&aligned 




All of these tests are passing right now - will you be adding new tests?



Flag name on chrome://flags



Finch feature name

CSSImportRuleStyleSheetNullable


Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/issues/40266154


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/5123480866783232

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/CAOGEg03EdbMR2-x-7taf692_FmX4%2BwBMgFW%2BwaZiM7gs1Zo5-Q%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/032d8d45-c28b-439d-a72c-fff1f0b535e8%40chromium.org.

Re: [blink-dev] Re: Intent to Ship: RTCIceCandidate url and relayProtocol attributes

[Mike Taylor]

LGTM2

On 2/19/24 11:34 AM, Yoav Weiss (@Shopify) wrote:

LGTM1

On Wed, Feb 14, 2024 at 7:29 PM Philipp Hancke 
 wrote:


Am Mi., 14. Feb. 2024 um 16:09 Uhr schrieb Yoav Weiss (@Shopify)
:



On Monday, February 12, 2024 at 7:52:17 PM UTC+1
philipp...@googlemail.com wrote:

Contact emails

phan...@microsoft.com


Explainer

None


I think it would be useful to write a few sentences on what
you want to ship, what's the motivation for shipping it and
how we expect web developers to make use of it.


Will add. There are two small use-cases:
1/ "which server did I gather this ICE candidate from", as shown
on
https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
2/ answering the "Is my call now getting relayed via a TURN
server" in the selectedcandidatepairchange event

.
 Which
sometimes leads to the question
  "why is my call being relayed through a server in another part
of the world and doing it over TCP makes things terrible?"

Both of these were possible to obtain by asking the getStats API
and then traversing the stats graph but that is rather cumbersome
(and that still requires a lot of backward compat code


 for
the second case)
In the case of relayProtocol it was also possible by looking at
the upper 8 bits of the "priority" field already exposed but that
was/is implementation-specific.


Specification

https://w3c.github.io/webrtc-pc/#rtcicecandidate-interface



Summary

https://w3c.github.io/webrtc-pc/#rtcicecandidate-interface


gets implementations for two new properties for
RTCIceCandidate objects emitted from the 'icecandidate' event.



https://github.com/w3c/webrtc-pc/pull/2773


added the url of the STUN or TURN server a local ICE
candidate of type 'srflx' or 'relay' was gathered from.


https://github.com/w3c/webrtc-pc/pull/2763


added the relay protocol (i.e. whether the candidate was
gathered via TURN/UDP, TURN/TCP or TURN/TLS) a local ice
candidate of type 'relay' was gathered from.


These properties are already available in the getStats API
as RTCIceCandidateStats.


OK, so I'm guessing the motivation here is ergonomics?

Any reason why we want to expose the same data from multiple APIs?


Ergonomics and consistency, this makes both APIs return the same
information for the ICE candidates.


Blink component

Blink>WebRTC




TAG review

None


TAG review status

Not applicable


Risks

Interoperability and Compatibility

None



Gecko: No official signal yet but positive
(https://github.com/mozilla/standards-positions/issues/976
)


WebKit: No signal
(https://github.com/WebKit/standards-positions/issues/310
)


Web developers: No signals


Other signals:


WebView application risks

None



Debuggability

None



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

No


Is this feature fully tested by web-platform-tests

?


Not testable in WPT due to lack of STUN/TURN servers



Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1354626



Estimated milestones

Shipping on desktop

123



Anticipated spec changes

None


Link to entry on the Chrome Platform Status

   

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 paint-order for non-SVG text

[Mike Taylor]

LGTM3, with the same conditions from Chris.

On 2/15/24 6:15 PM, Chris Harrelson wrote:

LGTM2, conditioned on also making the tests Rego mentioned non-tentative.

On Mon, Feb 12, 2024 at 11:05 AM Stefan Zager  wrote:

Done (requested N/A).

On Mon, Feb 12, 2024 at 3:05 AM Manuel Rego Casasnovas
 wrote:

Oops, before we can approve you have to fill the other review
gates at
chromestatus, e.g.
https://chromestatus.com/feature/5178467903864832?gate=5166816630669312

Could you make sure you request the review for all the gates:
Privacy,
Security, Enterprise, Debuggability and Testing?

Thanks!
   Rego

On 12/02/2024 12:02, Manuel Rego Casasnovas wrote:
> LGTM1.
>
> Good to know it's a different issue in Firefox.
>
> Now that all browsers will be supporting this, please could
you make the
> test non tentative?
>
> JFYI, I've filled an issue so the MDN documentation gets
updated to also
> include the HTML case:
https://github.com/mdn/content/issues/32236
>
> Cheers,
>    Rego
>
> On 09/02/2024 09:00, Stefan Zager wrote:
>>
>>
>> On Thu, Feb 8, 2024 at 4:00 AM Manuel Rego Casasnovas
> > wrote:
>>
>>     Why is the WPT test marked as tentative?
>>
>>

https://wpt.fyi/results/css/css-fill-stroke/paint-order-001.tentative.html


>>
>>     Not sure if there are more tests or is only that one,
but it's
>> failing
>>     in Firefox. What are the interop issues? Are those
reported
>> somewhere?
>>
>>
>> Looks like an implementation-specific line-breaking issue
in the
>> Firefox runs, but the text rendering appears consistent
with webkit
>> and chromium.
>>
>> I'm unaware of any interop issues.
>>
>>
>>     Thanks,
>>     Rego
>>
>>     On 08/02/2024 11:48, Fredrik Söderquist wrote:
>>  > On Thu, Feb 8, 2024 at 11:30 AM Daniel Bratell
>>     mailto:bratel...@gmail.com>
>>  > >> wrote:
>>  >
>>  >     __
>>  >
>>  >     I didn't really get how it affects non-SVG text. The
>>     documentation
>>  >     and the examples are all for SVG. Is there HTML
text that is
>>     also a
>>  >     mix of stroke, fill and marker blitting?
>>  >
>>  > Here's an example for non-SVG (HTML) text:
>>  > https://jsfiddle.net/4mh71efb/

>>     >
>>  >
>>  > Getting a stroke on HTML text requires using the
>>     -webkit-text-stroke-*
>>  > family of properties. Markers don't apply to text
(same as for
>>     SVG text).
>>  >
>>  >
>>  > /fs
>>  >
>>  >     /Daniel
>>  >
>>  >     On 2024-02-08 10:14, Fredrik Söderquist wrote:
>>  >>     On Thu, Feb 8, 2024 at 2:48 AM Stefan Zager
>>     mailto:sza...@chromium.org>
>>  >>     >>
>>     wrote:
>>  >>
>>  >>
>>  >>                 Contact emails
>>  >>
>>  >> sza...@chromium.org 
>>     >
>>  >>
>>  >>
>>  >>                 Explainer
>>  >>
>>  >>
https://developer.mozilla.org/en-US/docs/Web/CSS/paint-order
>>    

>>  >>
>>  >    
>
>>  >>
>>  >>
>>  >>                 Specification
>>  >>
>>  >> https://svgwg.org/svg2-draft/painting.html#PaintOrder
>>     
>>  >>       
 >     >
>>  >>
>>  >>
>>  >>                 Summary
>>  >>
>>  >>         Adds support for t

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

[Mike Taylor]

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)
 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)
 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)  wrote:

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

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

Contact emails

nidhij...@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/14dbzMpsYPfkefAJos124uPrlkvW7jyPJhzjujSWws2k/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

perhttps://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

Re: [blink-dev] Intent to Ship: Private Network Access permission to relax mixed content

[Mike Taylor]

LGTM2

On 2/15/24 4:55 AM, Yoav Weiss (@Shopify) wrote:

LGTM1

On Thu, Feb 15, 2024 at 9:51 AM 'Yifan Luo' via blink-dev 
 wrote:


OT findings:

https://docs.google.com/spreadsheets/d/15b2kCikEqw6P0xZFXQKMiKk_WnqnIZpT5p8nmLgc93Y/edit?usp=sharing
There are 7 OT users and most of them (6/7) mentioned they will
keep using this new feature.

We aimed to use this feature to make it possible for developers to
drop the non-secure context deprecation trial,

which currently got 1000+ registrations:

https://docs.google.com/spreadsheets/d/1yTjZs3yvTFwn0SupdBmzZiOQ_A3Auvg_Qrp3DwOKBNw/edit?pli=1#gid=369270489

RFPs: This feature is a sub-feature of Private Network Access
: filled in the
previous RFP of PNA.
Flag: Sorry for the missing, there's a finch flag
"PrivateNetworkAccessPermissionPrompt"

On Tuesday, February 13, 2024 at 5:02:38 PM UTC+1 Yifan Luo wrote:

Contact emailsl...@chromium.org, cl...@chromium.org,
tit...@chromium.org


Explainerhttps://github.com/WICG/private-network-access/blob/main/permission_prompt/explainer.md


I had a minor concern 
 after 
reading the explainer about the lack of a preflight and opt-in 
requirement. Turns out that those are already required as part of the 
broader PNA feature.




Specificationhttps://wicg.github.io/private-network-access

Design docs

https://docs.google.com/document/d/1Q18g4fZoDIYQ9IuxlZTaItgkzfiz_tCqaEAI8J3Y1WY/edit

https://github.com/WICG/private-network-access/blob/main/permission_prompt/security_privacy_self_review.md

Summary

In order to establish connections to devices on a local
network that do not have globally unique names, and therefore
cannot obtain TLS certificates, this feature introduces a new
option to `fetch()` to declare a developers' intent to talk to
such a device, a new policy-controlled feature to gate each
sites' access to this capability, and new headers for the
server's preflight response to provide additional metadata.



Blink componentBlink>SecurityFeature>CORS>PrivateNetworkAccess



TAG reviewhttps://github.com/w3ctag/design-reviews/issues/751

TAG review statusIssues addressed

Chromium Trial NamePrivateNetworkAccessPermissionPrompt

Origin Trial documentation

linkhttps://github.com/WICG/private-network-access/blob/main/permission_prompt/explainer.md

WebFeature UseCounter namekPrivateNetworkAccessPermissionPrompt

Risks


Interoperability and Compatibility

/Gecko/: Positive
(https://github.com/mozilla/standards-positions/issues/143)
Worth prototyping.

/WebKit/: Positive
(https://github.com/WebKit/standards-positions/issues/163)


/Web developers/: Positive
(https://github.com/WICG/private-network-access/issues/23)

/Other signals/:

Ergonomics

This new feature requires users to click on the new
permission. This may lead users to spamming on some websites.
However, this is an intentional move to encourage the websites
to provide security context. The origin trial also aimed to
measure the frequency of users getting the permissions.



Activation

No. This feature attempt to bring developers an easier way to
restrict Private Network Access with secure context.



Security

This is a security positive feature.



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

Relevant information (client and resource IP address space) is
already piped into the DevTools network panel. We’ll likely
also represent the permission state in the settings pages.



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

Mac, Windows, Linux, Chrome OS, Fuchsia, Android, WebLayer.
Not Android WebView because of the absence of deprecation
trial integration (though that may be changing soon, see
https://crbug.com/1308425). Not iOS because this requires
changes in Blink and the network service, neither of which are
used on iOS.



Is this feature fully tested by web-platform-tests

?No



https://wp

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

[Mike Taylor]

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

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork%3EWebSockets>


Search tags

WebSocket
<https://chromestatus.com/features#tags:WebSocket>,
Streams <https://chromestatus.com/features#tags:Streams>,
ReadableStream
<https://chromestatus.com/features#tags:ReadableStream>,
WritableStream
<https://chromestatus.com/features#tags: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 featur

Re: [blink-dev] Re: Intent to Ship: Document picture-in-picture: allow Window's focus() API to focus opener

[Mike Taylor]

LGTM3

On 2/15/24 1:06 AM, Yoav Weiss (@Shopify) wrote:

LGTM2

On Wed, Feb 14, 2024 at 9:28 PM Chris Harrelson 
 wrote:


Thanks!

LGTM1

On Wed, Feb 14, 2024 at 11:07 AM 'Tommy Steimel' via blink-dev
 wrote:

Landed the PR and added a comment to the TAG thread. Thanks!

On Wed, Feb 14, 2024 at 6:24 AM Yoav Weiss (@Shopify)
 wrote:



On Monday, February 12, 2024 at 10:31:12 PM UTC+1 Tommy
Steimel wrote:

Contact emailsstei...@chromium.org,
liber...@chromium.org 

ExplainerNone


Specificationhttps://github.com/WICG/document-picture-in-picture/pull/109



What's preventing the PR from landing?



Summary

This enables `opener.focus()` from a document
picture-in-picture window to bring system-level focus
to the tab that owns the document picture-in-picture
window. This allows developers to bring the original
tab back to the foreground when necessary, e.g. when
the user needs to access a more full UI/experience
that doesn't fit in the smaller picture-in-picture window.



Blink componentBlink>Media>PictureInPicture



TAG reviewN/A as this is a minor change to the
behavior of an existing API


Can you add a comment to notify the TAG of this change?



TAG review statusNot applicable

Risks


Interoperability and Compatibility

None



/Gecko/: No signal

(https://github.com/mozilla/standards-positions/issues/670#issuecomment-1919880414

)
Added comment to existing standards position issue for
document picture-in-picture. No response yet

/WebKit/: No signal

(https://github.com/WebKit/standards-positions/issues/41#issuecomment-1919879502

)
Added comment to existing standards position issue for
document picture-in-picture. No response yet

/Web developers/: Positive
(https://github.com/WICG/document-picture-in-picture/issues/94
)
We have received feature requests for programmatically
returning to the opener tab from multiple first and
third-party partners

/Other signals/:

Ergonomics

N/A



Activation

N/A



Security

While allowing the picture-in-picture window to bring
system-level focus to the opener tab at will could be
abused, the user gesture requirement effectively
ensures that the user is at least currently
interacting with that website and not another, so is
less likely to be surprised or tricked by the change
of focus to another window from the same origin.



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?

N/A



Debuggability

N/A



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

The document picture-in-picture API is not supported
on Android



Is this feature fully tested by web-platform-tests

?Yes


document-picture-in-picture/focus-opener.https.html



Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justification

Small change to existing API



Requires code in //chrome?False

Sample links
https://steimelchrome.github.io/backtotab.html


Estimated milestonesShipping on desktop123

Anticipated spec changes

Open questions about a feature may be a sourc

Re: [blink-dev] Intent to Ship: Support in Chrome for the VoiceIsolation getUserMedia constraint

[Mike Taylor]

LGTM3

On 2/14/24 11:49 AM, Chris Harrelson wrote:

LGTM2

On Wed, Feb 14, 2024 at 8:46 AM Philip Jägenstedt 
 wrote:


LGTM1, some comments inline.

On Sat, Feb 3, 2024 at 6:15 AM Per Åhgren  wrote:
>>
>>
>> TAG review status
>>
>> Issues addressed
>> This is somewhat at odds with the previous response. :) Did you
intend to link a TAG review and forget?
>
> Sorry, my bad. I did not remove this from the template before
sending it.
> The intention was not to add any issues and there is no TAG
review to link.

That's OK, this is a very small addition to the platform and doesn't
need a TAG review.

>> Could we please request signals?
>
> Yes, signals have now been requested
> https://github.com/mozilla/standards-positions/issues/982
> https://github.com/WebKit/standards-positions/issues/314

No replies on these issues yet, but I see that
https://github.com/w3c/mediacapture-extensions/pull/63 was reviewed by
someone from WebKit. That doesn't imply a positive standards position,
but it does reduce the risk. Let's move forward with this, but please
circle back on this thread if there's feedback on the two issues
above.

-- 
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/CAARdPYe2CqrV4ofwfYPSR%3D-F_rzRcEYk2z_OfUFWBb8cwSRBWw%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/6f8a4545-df7e-4854-b79e-3b9c29f170c7%40chromium.org.

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

[Mike Taylor]

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

?

Yes

https://wpt.fyi/results/websockets/stream/tentative



Flag name on chrome://flags

about://flags/#enable-experimental-web-platform-features


Finch feature name

WebSocketStream


Requires code in //chrome?

False


Tracking b

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

[Mike Taylor]

Thanks! I had intended to reply that it's very simple to add a runtime 
enabled feature to IDL, but it's been a busy day. :)


On 2/13/24 3:57 PM, Eldar Rello wrote:


>Can we add a flag? 
https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md


>(Or someone can explain why that's difficult and the risk is low 
here...).


I made it as a runtime enabled feature now.


On Monday, February 12, 2024 at 10:50:18 PM UTC+2 Eldar Rello wrote:

On Monday, February 12, 2024 at 4:53:50 PM UTC+2
mike...@chromium.org wrote:

On 2/12/24 6:36 AM, Eldar Rello wrote:


Contact emails eldar...@gmail.com

Explainer None

Specification

https://w3c.github.io/webrtc-extensions/#dom-rtcrtpreceiver-jitterbuffertarget

Summary

JitterBufferTarget attribute allows applications to specify a
target duration of time in milliseconds of media for the
RTCRtpReceiver's jitter buffer to hold. This influences the
amount of buffering done by the user agent, which in turn
affects retransmissions and packet loss recovery. Altering
the target value allows applications to control the tradeoff
between playout delay and the risk of running out of audio or
video frames due to network jitter.


Essentially it is a rename of already shipped
playoutDelayHint attribute.


Is this purely a rename, or are there changes to the semantics?

Other than the name change, it throws RangeError when delay
parameter is out of range. playoutDelayHint is throwing only if
delay is negative. Another difference is that jitterBuffferTarget
is in milliseconds unit while playoutDelayHint is using seconds.

And do we have any sense how widely used playoutDelayHint is
in the wild? There is some discussion of the bikeshedding in
https://lists.w3.org/Archives/Public/public-webrtc/2023Apr/0045.html,
but no consideration of existing usage (at least as reflected
in the minutes).

I do not have visibility over usage, but playoutDelayHint remains
supported to enable smooth adaption.



Blink component Blink>WebRTC



TAG review None

TAG review status Not applicable

Opening an issue seems useful, but that seems like a heavy tax
for a contributor (vs the spec editors...).



Risks


Interoperability and Compatibility

None



/Gecko/: Shipped/Shipping

Mind providing a link to a bug?

Added



/WebKit/: No signal

Can we request a permission please?
https://github.com/WebKit/standards-positions


Created ticket there.




/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)? No

Which platforms will it be supported on, if not all of them?

Fixed. Initially I was unsure, but it should be supported on all
platforms where WebRTC is available.




Is this feature fully tested by web-platform-tests

?
Yes


https://wpt.fyi/results/webrtc-extensions/RTCRtpReceiver-jitterBufferTarget.html?label=experimental&label=master&aligned





Flag name on chrome://flags None

Finch feature name None


Can we add a flag?

https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md

(Or someone can explain why that's difficult and the risk is
low here...).

Personally I do not see any value for guarding as like already
mentioned exactly same functionality is already exposed by legacy
attribute playoutDelayHint.



Non-finch justification None

Requires code in //chrome? False

Estimated milestones Shipping on desktop 123

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
  

Re: [blink-dev] Intent to Ship: Cross App and Web Attribution Measurement

[Mike Taylor]

Thanks Nan for helping us better understand the feature.

LGTM1 given the following "...it’s possible that Android may ship 
support for new registration fields in the OS-level API, which may or 
may not be supported in the web API. The web API may lag behind, or even 
not implement the new features at all."


Shipping support for these new fields would require the Blink process - 
so we can evaluate future additions in the future (and I'm not worried 
about only supporting a subset of the OS-level API - if there is 
developer demand and utility to be gained from it, I suspect we'll 
eventually add support).


On 2/8/24 11:59 PM, Nan Lin wrote:

Hi Yoav,

On Thu, Feb 8, 2024 at 11:09 PM Yoav Weiss (@Shopify) 
 wrote:






On Wed, Feb 7, 2024 at 12:58 PM Nan Lin  wrote:

Thanks Mike.

On Wed, Feb 7, 2024 at 12:50 AM Mike Taylor
 wrote:

On 2/6/24 3:59 AM, Nan Lin wrote:


Hi Mike,

Thanks for reviewing. Please see responses inline.

Nan

On Mon, Feb 5, 2024 at 9:33 PM Mike Taylor
 wrote:

Hi Nan,

On 2/2/24 5:00 AM, Nan Lin wrote:



Contact emails

lin...@chromium.org <mailto:lin...@chromium.org>,
johni...@chromium.org <mailto:johni...@chromium.org>


Explainer

Cross App and Web Attribution Measurement

<https://github.com/WICG/attribution-reporting-api/blob/main/app_to_web.md>


Specification


https://wicg.github.io/attribution-reporting-api/#cross-app-and-web

<https://wicg.github.io/attribution-reporting-api/#cross-app-and-web>


Summary


This is an extension to the Attribution Reporting
API
<https://github.com/WICG/conversion-measurement-api>that
has already shipped.


Currently, the Attribution Reporting API
<https://github.com/WICG/conversion-measurement-api>supports
attributing events within a single browser instance.
This proposal expands the scope of attribution to
allow attributing conversions that happen on the web
to events that happen off the browser on the same
device, within other applications such as mobile
applications, or vice-versa.

The proposal here leverages OS-level support for
attribution. In particular, it gives the developer
an option to allow events on the mobile web to be
delegated to Android’s Privacy Sandbox

<https://developer.android.com/design-for-safety/privacy-sandbox/attribution>,
although support for other platforms could also be
implemented in the future.

Note that with this proposal new features shipped by
the OS may be implicitly supported without web API
changes. For example, Android may ship support for
new registration fields not supported in the
existing Attribution Reporting API. Once a developer
elects to delegate events to the OS, there is no way
web-visible to introspect this.


Could you help me better understand the implications
of this? Does it just mean that debugging becomes
challenging for new fields, or are there other
possible implications depending on new OS features?
Or possibly the web API lags behind what is possible
via the platform, until the web API catches up formally?


It’s not about debugging. Currently the web API and the
Android’s implementation of the Attribution Reporting API
are expected to be interoperable. However it’s possible
that Android may ship support for new registration fields
in the OS-level API, which may or may not be supported in
the web API. The web API may lag behind, or even not
implement the new features at all. Once the event is
delegated to the OS, the attribution registration will be
handled by the OS and possibly using the new features in
its API.



Can you provide an example of how future OS-level changes can
result in semantics changes for the web exposed API?
Is the information flow here strictly from the web API to the OS
API? Or is it possible for the OS attribution to flow into the
web? (e.g. if an ad on a native app ends up landing on a website)


Please see my response below for the workflow to delegate a web event 
to the OS.


For example, the OS API implements a new feature, 

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

[Mike Taylor]

We also need to flip the various review gates on the chromestatus entry 
(privacy, security, enterprise... etc.). If you're working with someone 
at Google on this feature, perhaps they could assist?


On 2/12/24 9:53 AM, Mike Taylor wrote:


On 2/12/24 6:36 AM, Eldar Rello wrote:



Contact emails

eldar.re...@gmail.com


Explainer

None


Specification

https://w3c.github.io/webrtc-extensions/#dom-rtcrtpreceiver-jitterbuffertarget


Summary

JitterBufferTarget attribute allows applications to specify a target 
duration of time in milliseconds of media for the RTCRtpReceiver's 
jitter buffer to hold. This influences the amount of buffering done 
by the user agent, which in turn affects retransmissions and packet 
loss recovery. Altering the target value allows applications to 
control the tradeoff between playout delay and the risk of running 
out of audio or video frames due to network jitter.



Essentially it is a rename of already shipped playoutDelayHint attribute.


Is this purely a rename, or are there changes to the semantics?

And do we have any sense how widely used playoutDelayHint is in the 
wild? There is some discussion of the bikeshedding in 
https://lists.w3.org/Archives/Public/public-webrtc/2023Apr/0045.html, 
but no consideration of existing usage (at least as reflected in the 
minutes).





Blink component

Blink>WebRTC 
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebRTC>



TAG review

None


TAG review status

Not applicable
Opening an issue seems useful, but that seems like a heavy tax for a 
contributor (vs the spec editors...).



Risks



Interoperability and Compatibility

None



/Gecko/: Shipped/Shipping

Mind providing a link to a bug?


/WebKit/: No signal
Can we request a permission please? 
https://github.com/WebKit/standards-positions


/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)?

No

Which platforms will it be supported on, if not all of them?



Is this feature fully tested by web-platform-tests

<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?

Yes

https://wpt.fyi/results/webrtc-extensions/RTCRtpReceiver-jitterBufferTarget.html?label=experimental&label=master&aligned 
<https://wpt.fyi/results/webrtc-extensions/RTCRtpReceiver-jitterBufferTarget.html?label=experimental&label=master&aligned>




Flag name on chrome://flags

None


Finch feature name

None


Can we add a flag? 
https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md


(Or someone can explain why that's difficult and the risk is low here...).



Non-finch justification

None


Requires code in //chrome?

False


Estimated milestones

Shipping on desktop 123



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/5930772496384000

This intent message was generated by Chrome Platform Status 
<https://chromestatus.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/CALvR0FL%2BF95hLfNZWDMK6W6qNGiPf1xqKeZ9pn__2aru4urypw%40mail.gmail.com 
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALvR0FL%2BF95hLfNZWDMK6W6qNGiPf1xqKeZ9pn__2aru4urypw%40mail.gmail.com?utm_medium=email&utm_source=footer>.


--
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/13aaa2e8-097e-427c-b5ba-b1dafb5e5f2f%40chromium.org.

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

[Mike Taylor]

On 2/12/24 6:36 AM, Eldar Rello wrote:



Contact emails

eldar.re...@gmail.com


Explainer

None


Specification

https://w3c.github.io/webrtc-extensions/#dom-rtcrtpreceiver-jitterbuffertarget


Summary

JitterBufferTarget attribute allows applications to specify a target 
duration of time in milliseconds of media for the RTCRtpReceiver's 
jitter buffer to hold. This influences the amount of buffering done by 
the user agent, which in turn affects retransmissions and packet loss 
recovery. Altering the target value allows applications to control the 
tradeoff between playout delay and the risk of running out of audio or 
video frames due to network jitter.



Essentially it is a rename of already shipped playoutDelayHint attribute.


Is this purely a rename, or are there changes to the semantics?

And do we have any sense how widely used playoutDelayHint is in the 
wild? There is some discussion of the bikeshedding in 
https://lists.w3.org/Archives/Public/public-webrtc/2023Apr/0045.html, 
but no consideration of existing usage (at least as reflected in the 
minutes).





Blink component

Blink>WebRTC 




TAG review

None


TAG review status

Not applicable
Opening an issue seems useful, but that seems like a heavy tax for a 
contributor (vs the spec editors...).



Risks



Interoperability and Compatibility

None



/Gecko/: Shipped/Shipping

Mind providing a link to a bug?


/WebKit/: No signal
Can we request a permission please? 
https://github.com/WebKit/standards-positions


/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)?

No

Which platforms will it be supported on, if not all of them?



Is this feature fully tested by web-platform-tests

?

Yes

https://wpt.fyi/results/webrtc-extensions/RTCRtpReceiver-jitterBufferTarget.html?label=experimental&label=master&aligned 





Flag name on chrome://flags

None


Finch feature name

None


Can we add a flag? 
https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md


(Or someone can explain why that's difficult and the risk is low here...).



Non-finch justification

None


Requires code in //chrome?

False


Estimated milestones

Shipping on desktop 123



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/5930772496384000

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/CALvR0FL%2BF95hLfNZWDMK6W6qNGiPf1xqKeZ9pn__2aru4urypw%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/5bf08d14-b1b9-4216-b50d-2a68e7dcfb00%40chromium.org.

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

[Mike Taylor]

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 <mailto: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

<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

<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
tohttps://chromestatus.com/feature/5146352391028736
<https://chromestatus.com/feature/5146352391028736>and
corresponding blink-dev PSA

<https://groups.google.com/a/chromium.org/g/blink-dev/c/Hf2b1-S39Uw/m/YAEC_0DSBQAJ>.
The "window-placement" alias has been showing console
deprecation warnings since M113

<https://chromium.googlesource.com/chromium/src.git/+/13204be718225ae09c8ba7e36b055a369c36c878>.
We will disable WindowPlacementPermissionAlias

<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/runtime_enabled_features.json5?q=-f:gen%2F%20AND%20-f:out%2F%20WindowPlacementPermissionAlias>by
default, and remove the flag and legacy code shortly
thereafter.


I'm a little bit confused here - it seems like the PSA of
the alias is being treated as the beginning of a
deprecation, is that correct? My interpretation of "will
lead to a deprecation and removal" from the original
message was that it would be followed with an Intent to
Deprecate and Remove (per
https://www.chromium.org/blink/launching-features/#deprecate),
but it seems like that step of the process was skipped.

 Yes, I never sent out a separate "Intent to Deprecate" in
this case. The original PSA

<https://groups.google.com/a/chromium.org/g/blink-dev/c/Hf2b1-S39Uw/m/YAEC_0DSBQAJ>
 was
intended to be a hybrid of the introduction of the new names
and deprecation of the old ones so we also landed deprecation
code (DevTools deprecation warnings etc.) during that time.
Since these have already been "deprecated" since M113, I
wasn't sure if a separate "intent to deprecate" was
appropriate in this case since we already deprecated them and
monitored usage to be sufficiently low, but I can back-up and
send an I2D if recommended here.



Blink component

Blink>Screen>MultiScreen

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScreen%3EMultiScreen>


TAG review

No feedback was specifically requested for the permission
rename, however related TAG reviews have been requested
with both the old (1
<https://github.com/w3ctag/design-reviews/issues/413>, 2
<https://github.com/w3ctag/design-reviews/issues/602>)
and new terminology (3
<https://github.com/w3ctag/design-reviews/issues/840>).


TAG review status

Not applicable


Risks


Interoperability and Compatibility

There are low

Re: [blink-dev] Intent to Prototype and Ship: Private network access checks for navigation requests: warning-only mode

[Mike Taylor]

The change in milestones won't affect your approvals to ship. :)

On 2/9/24 6:24 AM, Jonathan Hao wrote:
I just realized that we can still make M123 so I plan to do so unless 
there are any objections.


On Thu, Feb 8, 2024 at 2:29 PM Jonathan Hao  wrote:

Here's a public version of the design doc:

https://docs.google.com/document/d/1QyFqHCgZLmEfy0wbgXNgce9zKpZVaqSpQY3JleFWrk0/edit?usp=sharing

On Wed, Feb 7, 2024 at 5:22 PM Daniel Bratell
 wrote:

LGTM3 to add a warning.

Normally we don't like open ended deprecation warnings, end,
which this is, but this should be a rare warning, except
possibly in enterprise situations, and even there, warnings
might trigger some feedback from a group that is normally not
aware of upcoming changes.

/Daniel

On 2024-02-07 14:40, Yoav Weiss (@Shopify) wrote:

LGTM2

On Fri, Feb 2, 2024 at 11:10 PM Mike Taylor
 wrote:

Correction: LGTM1, conditioned on requesting Enterprise,
Debuggability, and Testing bits in chromestatus. :)

On 2/2/24 5:09 PM, Mike Taylor wrote:


LGTM1

On 2/2/24 11:17 AM, Jonathan Hao wrote:



Contact emails

p...@chromium.org


Explainer


https://github.com/WICG/private-network-access/blob/main/explainer.md


Specification

https://wicg.github.io/private-network-access


Design docs



https://docs.google.com/document/d/1UqkJsc2VZ4bXmZkVxh-EPyBFEtdxX9p2zX4sxzAj754/edit?usp=sharing&resourcekey=0-7cfhrTo57AElxA6M9EVScg

<https://docs.google.com/document/d/1UqkJsc2VZ4bXmZkVxh-EPyBFEtdxX9p2zX4sxzAj754/edit?usp=sharing&resourcekey=0-7cfhrTo57AElxA6M9EVScg>


Summary

Before a website A navigates to another site B in the
user's private network, this feature does the following:
1. Checks whether the request has been initiated from a
secure context
2. Sends a preflight request, and checks whether B
responds with a header that allows private network access.

The above checks are made to protect the user's private
network. There are already features for subresources
and workers, but this one is for navigation requests
specifically.


Since this feature is the "warning-only" mode, we do
not fail the requests if any of the checks fails. 
Instead, a warning will be shown in the DevTools, to
help developers prepare for the coming enforcement.



Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ECORS%3EPrivateNetworkAccess>


Motivation

To prevent malicious websites from pivoting through the
user agent's network position to attack devices and
services which reasonably assumed they were unreachable
from the Internet at large, by virtue of residing on
the user’s local intranet or the user's machine.



Initial public proposal


https://discourse.wicg.io/t/transfer-cors-rfc1918-and-hsts-priming-to-wicg/1726


TAG review

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


TAG review status

Issues addressed


Risks



Interoperability and Compatibility

Since we don't enforce the checks and only show
warnings, there isn't any compatibility risks on the
client side. On the server side, it shouldn't pose any
risk either as the server can ignore the preflight
requests.



/Gecko/: Positive
(https://github.com/mozilla/standards-positions/issues/143)

https://mozilla.github.io/standards-positions/#cors-and-rfc1918
makes it a bit clearer that this is indeed positive (vs
the issue).


/WebKit/: Positive
(https://github.com/WebKit/standards-positions/issues/163)
Safari disagrees with the spec name and header names,
but still overall positive.

/Web developers/: Mixed signals Anecdotal evidence so
far suggests that most web developers are OK with this
new requirement, though some do not control the target
endpoints and would be negatively impacted.

/Other signals/:


Security

This change aims to be security-positive, preventing
CSRF attacks against soft and

Re: [blink-dev] Intent to Ship: Cross App and Web Attribution Measurement

[Mike Taylor]

On 2/6/24 3:59 AM, Nan Lin wrote:


Hi Mike,

Thanks for reviewing. Please see responses inline.

Nan

On Mon, Feb 5, 2024 at 9:33 PM Mike Taylor  wrote:

Hi Nan,

On 2/2/24 5:00 AM, Nan Lin wrote:



Contact emails

lin...@chromium.org <mailto:lin...@chromium.org>,
johni...@chromium.org <mailto:johni...@chromium.org>


Explainer

Cross App and Web Attribution Measurement
<https://github.com/WICG/attribution-reporting-api/blob/main/app_to_web.md>


Specification

https://wicg.github.io/attribution-reporting-api/#cross-app-and-web
<https://wicg.github.io/attribution-reporting-api/#cross-app-and-web>


Summary


This is an extension to the Attribution Reporting API
<https://github.com/WICG/conversion-measurement-api>that has
already shipped.


Currently, the Attribution Reporting API
<https://github.com/WICG/conversion-measurement-api>supports
attributing events within a single browser instance. This
proposal expands the scope of attribution to allow attributing
conversions that happen on the web to events that happen off the
browser on the same device, within other applications such as
mobile applications, or vice-versa.

The proposal here leverages OS-level support for attribution. In
particular, it gives the developer an option to allow events on
the mobile web to be delegated to Android’s Privacy Sandbox

<https://developer.android.com/design-for-safety/privacy-sandbox/attribution>,
although support for other platforms could also be implemented in
the future.

Note that with this proposal new features shipped by the OS may
be implicitly supported without web API changes. For example,
Android may ship support for new registration fields not
supported in the existing Attribution Reporting API. Once a
developer elects to delegate events to the OS, there is no way
web-visible to introspect this.


Could you help me better understand the implications of this? Does
it just mean that debugging becomes challenging for new fields, or
are there other possible implications depending on new OS
features? Or possibly the web API lags behind what is possible via
the platform, until the web API catches up formally?


It’s not about debugging. Currently the web API and the Android’s 
implementation of the Attribution Reporting API are expected to be 
interoperable. However it’s possible that Android may ship support for 
new registration fields in the OS-level API, which may or may not be 
supported in the web API. The web API may lag behind, or even not 
implement the new features at all. Once the event is delegated to the 
OS, the attribution registration will be handled by the OS and 
possibly using the new features in its API.
Thanks for the response! I'm still trying to understand what a 
registration field is in the context of this API - is that a possible 
future item added to the OS registration struct in 
https://wicg.github.io/attribution-reporting-api/#os-registration? 
(Apologies, I can't find any reference to "registration field" in the 
draft spec...).
This can happen without web API change and there’s no way web-visible 
to introspect this.
OK, so introspection here is not about debugging, but being able to make 
decisions programmatically at runtime? Is that correct?




Blink component

Internals > AttributionReporting

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EAttributionReporting>


TAG review

https://github.com/w3ctag/design-reviews/issues/724#issuecomment-1908353938

<https://github.com/w3ctag/design-reviews/issues/724#issuecomment-1908353938>


TAG review status

Pending


Risks


 Interoperability and Compatibility


See the Attribution Reporting API I2S
<https://groups.google.com/a/chromium.org/g/blink-dev/c/2Rmj5V6FSaY>for
information on the other general measurement proposals in this space.


Private Click Measurement in Safari supports app to web
measurement

(https://webkit.org/blog/11529/introducing-private-click-measurement-pcm/#:~:text=App%2Dto%2DWeb%20Click%20Measurement

<https://webkit.org/blog/11529/introducing-private-click-measurement-pcm/#:~:text=App%2Dto%2DWeb%20Click%20Measurement>).
On iOS, some web to app measurement is supported via SKAdNetwork
(https://developer.apple.com/documentation/skadnetworkforwebads
<https://developer.apple.com/documentation/skadnetworkforwebads>).
There is currently no interop between these proposals and the
cross app web API for Attribution Reporting.


If Blink ever ships on iOS (at least in the EU, given recent
announcements by Apple), would it be possible to expect interop
between iO

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

[Mike Taylor]

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 
tohttps://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 
by 
default, and remove the flag and legacy code shortly thereafter.


I'm a little bit confused here - it seems like the PSA of the alias is 
being treated as the beginning of a deprecation, is that correct? My 
interpretation of "will lead to a deprecation and removal" from the 
original message was that it would be followed with an Intent to 
Deprecate and Remove (per 
https://www.chromium.org/blink/launching-features/#deprecate), but it 
seems like that step of the process was skipped.



Blink component

Blink>Screen>MultiScreen 




TAG review

No feedback was specifically requested for the permission rename, 
however related TAG reviews have been requested with both the old (1 
, 2 
) and new 
terminology (3 ).



TAG review status

Not applicable


Risks


Interoperability and Compatibility

There are low compatibility risks. 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, indicating most usage has already migrated.


These percentages are still relatively high, especially for the 
permissions policy variant. Besides the obvious fingerprint.js usage 
(which shouldn't break pages... I would hope), can you describe what the 
failure mode is after the proposed removal is? Have you dug into the 
remaining usage to verify?


Gecko: No signal

Firefox has not implemented the API and corresponding permission yet.


WebKit: No signal

Safari has not implemented the API and corresponding permission yet.


Mind linking to the original API position requests here in this thread?


Web developers: We have communicated internally with partners using 
the API who have expressed commitment to updating the permission 
strings in their code.



Other signals: Positivecomment 
from 
W3C WG Chair



WebView application risks

This is considered low risk. It removes an alias without any change in 
behavior of the underlying API.



Does this permission do anything on WebView? I would have guessed no.



Debuggability

Disabling WindowPlacementPermissionAlias 
will 
stop DevTools deprecation warnings for usage of the legacy strings and 
instead will act as if they did not exist at all (e.g. Permission API 
will produce an error when using "window-placement").




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

No. This feature is not supported on Android.


Is this feature fully tested by web-platform-tests

?

Yes. Web Platform tests have already been migrated to the new alias:

https://github.com/web-platform-tests/wpt/tree/master/window-management 




  

Re: [blink-dev] Intent to Ship: Cross App and Web Attribution Measurement

[Mike Taylor]

Hi Nan,

On 2/2/24 5:00 AM, Nan Lin wrote:



Contact emails

lin...@chromium.org , 
johni...@chromium.org 



Explainer

Cross App and Web Attribution Measurement 




Specification

https://wicg.github.io/attribution-reporting-api/#cross-app-and-web 




Summary


This is an extension to the Attribution Reporting API 
that has already 
shipped.



Currently, the Attribution Reporting API 
supports 
attributing events within a single browser instance. This proposal 
expands the scope of attribution to allow attributing conversions that 
happen on the web to events that happen off the browser on the same 
device, within other applications such as mobile applications, or 
vice-versa.


The proposal here leverages OS-level support for attribution. In 
particular, it gives the developer an option to allow events on the 
mobile web to be delegated to Android’s Privacy Sandbox 
, 
although support for other platforms could also be implemented in the 
future.


Note that with this proposal new features shipped by the OS may be 
implicitly supported without web API changes. For example, Android may 
ship support for new registration fields not supported in the existing 
Attribution Reporting API. Once a developer elects to delegate events 
to the OS, there is no way web-visible to introspect this.


Could you help me better understand the implications of this? Does it 
just mean that debugging becomes challenging for new fields, or are 
there other possible implications depending on new OS features? Or 
possibly the web API lags behind what is possible via the platform, 
until the web API catches up formally?



Blink component

Internals > AttributionReporting 




TAG review

https://github.com/w3ctag/design-reviews/issues/724#issuecomment-1908353938 




TAG review status

Pending


Risks


 Interoperability and Compatibility


See the Attribution Reporting API I2S 
for 
information on the other general measurement proposals in this space.



Private Click Measurement in Safari supports app to web measurement 
(https://webkit.org/blog/11529/introducing-private-click-measurement-pcm/#:~:text=App%2Dto%2DWeb%20Click%20Measurement 
). 
On iOS, some web to app measurement is supported via SKAdNetwork 
(https://developer.apple.com/documentation/skadnetworkforwebads 
). 
There is currently no interop between these proposals and the cross 
app web API for Attribution Reporting.


If Blink ever ships on iOS (at least in the EU, given recent 
announcements by Apple), would it be possible to expect interop between 
iOS and Android?


Gecko: No official position 
(https://github.com/mozilla/standards-positions/issues/791#issuecomment-1908359889 
)


Any reason we didn't file a new issue w/ Mozilla (or TAG...), but we did 
with WebKit?


WebKit: No official position 
(https://github.com/WebKit/standards-positions/issues/307 
)



Web developers: Positive. Some testers are currently implementing and 
providing feedback and more usage expected in 2024. Developers have 
requested expansion of coverage of this feature (example: 
https://github.com/WICG/attribution-reporting-api/issues/1125 
).



Debuggability


The Attribution Reporting API utilizes DevTools and an internal page 
(chrome://attribution-internals) to facilitate testing and 
integration. The debugging information for OS registrations from 
Chrome will be displayed in DevTools and the internal page as 
well.



Additionally, debug reports 
are 
supported for OS registrations. The Attribution Reporting API for 
Android also implements a similar debugging reports framework 
to 

Re: [blink-dev] Intent to Prototype and Ship: Private network access checks for navigation requests: warning-only mode

[Mike Taylor]

Correction: LGTM1, conditioned on requesting Enterprise, Debuggability, 
and Testing bits in chromestatus. :)


On 2/2/24 5:09 PM, Mike Taylor wrote:


LGTM1

On 2/2/24 11:17 AM, Jonathan Hao wrote:



Contact emails

p...@chromium.org


Explainer

https://github.com/WICG/private-network-access/blob/main/explainer.md


Specification

https://wicg.github.io/private-network-access


Design docs


https://docs.google.com/document/d/1UqkJsc2VZ4bXmZkVxh-EPyBFEtdxX9p2zX4sxzAj754/edit?usp=sharing&resourcekey=0-7cfhrTo57AElxA6M9EVScg 
<https://docs.google.com/document/d/1UqkJsc2VZ4bXmZkVxh-EPyBFEtdxX9p2zX4sxzAj754/edit?usp=sharing&resourcekey=0-7cfhrTo57AElxA6M9EVScg>



Summary

Before a website A navigates to another site B in the user's private 
network, this feature does the following:

1. Checks whether the request has been initiated from a secure context
2. Sends a preflight request, and checks whether B responds with a 
header that allows private network access.


The above checks are made to protect the user's private network. 
There are already features for subresources and workers, but this one 
is for navigation requests specifically.



Since this feature is the "warning-only" mode, we do not fail the 
requests if any of the checks fails.  Instead, a warning will be 
shown in the DevTools, to help developers prepare for the coming 
enforcement.




Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess 
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ECORS%3EPrivateNetworkAccess>



Motivation

To prevent malicious websites from pivoting through the user agent's 
network position to attack devices and services which reasonably 
assumed they were unreachable from the Internet at large, by virtue 
of residing on the user’s local intranet or the user's machine.




Initial public proposal

https://discourse.wicg.io/t/transfer-cors-rfc1918-and-hsts-priming-to-wicg/1726


TAG review

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


TAG review status

Issues addressed


Risks



Interoperability and Compatibility

Since we don't enforce the checks and only show warnings, there isn't 
any compatibility risks on the client side. On the server side, it 
shouldn't pose any risk either as the server can ignore the preflight 
requests.




/Gecko/: Positive 
(https://github.com/mozilla/standards-positions/issues/143)
https://mozilla.github.io/standards-positions/#cors-and-rfc1918 makes 
it a bit clearer that this is indeed positive (vs the issue).


/WebKit/: Positive 
(https://github.com/WebKit/standards-positions/issues/163) Safari 
disagrees with the spec name and header names, but still overall 
positive.


/Web developers/: Mixed signals Anecdotal evidence so far suggests 
that most web developers are OK with this new requirement, though 
some do not control the target endpoints and would be negatively 
impacted.


/Other signals/:


Security

This change aims to be security-positive, preventing CSRF attacks 
against soft and juicy targets such as router admin interfaces. DNS 
rebinding threats were of particular concern during the design of 
this feature: 
https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit#heading=h.189j5gnadts9




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

Relevant information (client and resource IP address space) is 
already piped into the DevTools network panel. Deprecation warnings 
and errors will be surfaced in the DevTools issues panel explaining 
the problem when it arises.




Is this feature fully tested by web-platform-tests

<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?

Yes

https://wpt.fyi/results/fetch/private-network-access?q=fetch%2Fprivate-network-access&run_id=5090117631868928&run_id=6245938696814592&run_id=5769215446351872&run_id=5679819023974400 
<https://wpt.fyi/results/fetch/private-network-access?q=fetch%2Fprivate-network-access&run_id=5090117631868928&run_id=6245938696814592&run_id=5769215446351872&run_id=5679819023974400>




Flag name on chrome://flags

None


Finch feature name

PrivateNetworkAccessForNavigations, 
PrivateNetworkAccessForNavigationsWarningOnly



Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1524350


Estimated milestones

Shipping on desktop 124

Shipping on Android 124



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4869685172764672

This intent message was generat

Re: [blink-dev] Intent to Prototype and Ship: Private network access checks for navigation requests: warning-only mode

[Mike Taylor]

LGTM1

On 2/2/24 11:17 AM, Jonathan Hao wrote:



Contact emails

p...@chromium.org


Explainer

https://github.com/WICG/private-network-access/blob/main/explainer.md


Specification

https://wicg.github.io/private-network-access


Design docs


https://docs.google.com/document/d/1UqkJsc2VZ4bXmZkVxh-EPyBFEtdxX9p2zX4sxzAj754/edit?usp=sharing&resourcekey=0-7cfhrTo57AElxA6M9EVScg 




Summary

Before a website A navigates to another site B in the user's private 
network, this feature does the following:

1. Checks whether the request has been initiated from a secure context
2. Sends a preflight request, and checks whether B responds with a 
header that allows private network access.


The above checks are made to protect the user's private network. There 
are already features for subresources and workers, but this one is for 
navigation requests specifically.



Since this feature is the "warning-only" mode, we do not fail the 
requests if any of the checks fails.  Instead, a warning will be shown 
in the DevTools, to help developers prepare for the coming enforcement.




Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess 




Motivation

To prevent malicious websites from pivoting through the user agent's 
network position to attack devices and services which reasonably 
assumed they were unreachable from the Internet at large, by virtue of 
residing on the user’s local intranet or the user's machine.




Initial public proposal

https://discourse.wicg.io/t/transfer-cors-rfc1918-and-hsts-priming-to-wicg/1726


TAG review

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


TAG review status

Issues addressed


Risks



Interoperability and Compatibility

Since we don't enforce the checks and only show warnings, there isn't 
any compatibility risks on the client side. On the server side, it 
shouldn't pose any risk either as the server can ignore the preflight 
requests.




/Gecko/: Positive 
(https://github.com/mozilla/standards-positions/issues/143)
https://mozilla.github.io/standards-positions/#cors-and-rfc1918 makes it 
a bit clearer that this is indeed positive (vs the issue).


/WebKit/: Positive 
(https://github.com/WebKit/standards-positions/issues/163) Safari 
disagrees with the spec name and header names, but still overall positive.


/Web developers/: Mixed signals Anecdotal evidence so far suggests 
that most web developers are OK with this new requirement, though some 
do not control the target endpoints and would be negatively impacted.


/Other signals/:


Security

This change aims to be security-positive, preventing CSRF attacks 
against soft and juicy targets such as router admin interfaces. DNS 
rebinding threats were of particular concern during the design of this 
feature: 
https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit#heading=h.189j5gnadts9




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

Relevant information (client and resource IP address space) is already 
piped into the DevTools network panel. Deprecation warnings and errors 
will be surfaced in the DevTools issues panel explaining the problem 
when it arises.




Is this feature fully tested by web-platform-tests

?

Yes

https://wpt.fyi/results/fetch/private-network-access?q=fetch%2Fprivate-network-access&run_id=5090117631868928&run_id=6245938696814592&run_id=5769215446351872&run_id=5679819023974400 





Flag name on chrome://flags

None


Finch feature name

PrivateNetworkAccessForNavigations, 
PrivateNetworkAccessForNavigationsWarningOnly



Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1524350


Estimated milestones

Shipping on desktop 124

Shipping on Android 124



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4869685172764672

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.

Re: [blink-dev] Intent to Ship: 'pagereveal' event

[Mike Taylor]

LGMT2 - no concerns about lack of a response from TAG.

On 2/2/24 1:18 AM, Domenic Denicola wrote:

LGTM1

On Fri, Feb 2, 2024 at 6:53 AM David Bokan  wrote:


Contact emails

bo...@chromium.org, khushalsa...@chromium.org,
nrosent...@chromium.org, vmp...@chromium.org


Explainer

https://github.com/WICG/view-transitions/blob/main/cross-doc-explainer.md


Specification

https://html.spec.whatwg.org/#reveal


Design docs


https://github.com/WICG/view-transitions/blob/main/cross-doc-explainer.md


Summary

The `pagereveal` event is fired on a Document's window object at
the first render opportunity after a Document is: initially
loaded, restored from the back-forward cache, or activated from a
prerender. It can be used by a page author to set up a page entry
UX - such as a ViewTransition from a previous state. This feature
is split out from the larger Cross Document View Transition project.



Blink component

Blink>ViewTransitions




Search tags

transition ,
firstrender ,
reveal , event
, viewtransition



TAG review

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

Note: TAG review was for Cross-Document View Transitions which
included this event as a piece. I asked TAG whether they'd like to
do a separate review but didn't receive a response.


I'll note that the ask was in 2023-09-28, with two other pings since 
then, so I think this is very fair. (And I also agree that this was 
covered by the original review request.)



TAG review status

Issues addressed


Risks



Interoperability and Compatibility

This is a new event so shouldn't have any compatibility risks.
Usual interop risk of other engines not adopting it exists but
this should be low since it's had input and discussion[1] from
engineers of both WebKit and Mozilla and is a dependency of
cross-document view transitions which has received a positive
signal from at least Mozilla[2] (waiting to hear from Apple[3]).
[1] https://github.com/whatwg/html/issues/9315 [2]
https://github.com/mozilla/standards-positions/issues/677

[3] https://github.com/WebKit/standards-positions/issues/302



/Gecko/: Positive
(https://github.com/mozilla/standards-positions/issues/677) See:

https://github.com/mozilla/standards-positions/issues/677#issuecomment-1904541389

/WebKit/: No signal
(https://github.com/WebKit/standards-positions/issues/303)
Awaiting response.

/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?

No



Debuggability

None



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

Yes

This is a standard HTML event applicable to all platforms



Is this feature fully tested by web-platform-tests

?

Yes


https://wpt.fyi/results/html/browsers/browsing-the-web/history-traversal/pagereveal?label=experimental&label=master&aligned




Can you un-tentative these tests?



Flag name on chrome://flags

chrome://flags/#enable-experimental-web-platform-features


Finch feature name

PageRevealEvent


Requires code in //chrome?

False


Tracking bug

https://crbug.com/1466250


Estimated milestones

Shipping on desktop 123
DevTrial on desktop 120

Shipping on Android 123
DevTrial on Android 120

Shipping on WebView 123



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/5205586941837312


Links 

Re: [blink-dev] Request for Deprecation Trial : HTMLVideoElement-specific Prefixed Fullscreen API

[Mike Taylor]

LGTM3

On 2/2/24 1:03 AM, Domenic Denicola wrote:
LGTM2. Please be sure to update Chrome Status with the deprecation 
trial timelines and removal milestones so that data gets fed into the 
feature dashboard, beta blog posts, etc.


On Fri, Feb 2, 2024 at 7:35 AM Thomas Guilbert 
 wrote:


Thank you!

I will be adding an enterprise policy to re-enable the APIs if
necessary, as part of the enterprise review. Deprecating the
enterprise policy will become the new objective after the proper
amount of time has elapsed, before the code can be deleted for good.

I will keep updating this thread as I make it further in the
launch process.

On Thu, Feb 1, 2024 at 2:24 PM Philip Jägenstedt
 wrote:

Thank you Thomas!

As far as I'm aware that's all of the paperwork completed, so
LGTM1 to disable the APIs by default and at the same time
start a reverse origin trial to re-enable them for 6 months.
If you hear feedback requesting an extension towards the end
of those 6 months, please request an extension for another 6
months.

On Thu, Feb 1, 2024 at 12:43 AM Thomas Guilbert
 wrote:

Thanks for marking it for review!

I submitted a request to review this change to the
chromium enterprise mailing list.

Thanks,
Thomas

On Wed, Jan 31, 2024 at 1:08 PM Mike Taylor
 wrote:

Yep - seems that's the cause of confusion. In your
first email,
https://chromestatus.com/feature/5259513871466496 is
linked from the bottom, so our review tooling is
presenting that to us. But I've just flagged the new
one so it will show up as well.

thanks!

On 1/31/24 2:41 PM, Thomas Guilbert wrote:

I requested privacy/security/debuggability on the
video element fullscreen API deprecation feature

<https://chromestatus.com/feature/5111638103687168?gate=5204167302053888> last
week. Privacy and debuggability are approved, just
waiting on security.

Mike, are you talking about requesting those gates on
the original Prefixed Fullscreen API feature
<https://chromestatus.com/feature/5259513871466496>?
I don't have edit rights on that Chrome status entry,
and upon closer look, it relates to
`webkitRequestFullscreen`, which is not covered by
this deprecation intent.

> [...] requesting enterprise signoff [...]
Is this a field on the chrome status entry? It
doesn't show up for me. Or is this about emailing the
list mentioned here

<https://www.chromium.org/developers/enterprise-changes/#1-give-enterprises-visibility>?

Thanks,
Thomas



On Wed, Jan 31, 2024 at 8:54 AM Philip Jägenstedt
 wrote:

Apologies in advance for excessive paperwork, but
can you also put
https://chromestatus.com/feature/5111638103687168
through the process, requesting enterprise
signoff in particular? Enterprise folks could
depend on this and might need to take some extra
action, and a "Feature deprecation" entry is the
only way we can flag that.

    On Wed, Jan 31, 2024 at 5:44 PM Mike Taylor
 wrote:

Gentle reminder to follow up on requesting
privacy/security/debuggability approvals in
chromestatus (which is currently blocking LGTMs).

On Wednesday, January 24, 2024 at 7:23:28 AM
UTC-5 Mike Taylor wrote:

Would you mind requesting reviews for the
various gates (privacy, security,
debuggability) for an OT/DT in your
chromestatus entry?

On 1/19/24 10:43 PM, Thomas Guilbert wrote:



Contact emails

tguilb...@chromium.org


Explainer

None


Specification


https://fullscreen.spec.whatwg.org/#dom-document-fullscreenenabled


Summary

There was an attempt in 2014

<https://groups.google.com/a/chromium.org/g/blink-dev/c/Bxe7DnDVRZ0/m/5K61H

Re: [blink-dev] Request for Deprecation Trial : HTMLVideoElement-specific Prefixed Fullscreen API

[Mike Taylor]

Yep - seems that's the cause of confusion. In your first email, 
https://chromestatus.com/feature/5259513871466496 is linked from the 
bottom, so our review tooling is presenting that to us. But I've just 
flagged the new one so it will show up as well.


thanks!

On 1/31/24 2:41 PM, Thomas Guilbert wrote:
I requested privacy/security/debuggability on the video element 
fullscreen API deprecation feature 
<https://chromestatus.com/feature/5111638103687168?gate=5204167302053888> last 
week. Privacy and debuggability are approved, just waiting on security.


Mike, are you talking about requesting those gates on the original 
Prefixed Fullscreen API feature 
<https://chromestatus.com/feature/5259513871466496>? I don't have edit 
rights on that Chrome status entry, and upon closer look, it relates 
to `webkitRequestFullscreen`, which is not covered by this deprecation 
intent.


> [...] requesting enterprise signoff [...]
Is this a field on the chrome status entry? It doesn't show up for me. 
Or is this about emailing the list mentioned here 
<https://www.chromium.org/developers/enterprise-changes/#1-give-enterprises-visibility>?


Thanks,
Thomas



On Wed, Jan 31, 2024 at 8:54 AM Philip Jägenstedt 
 wrote:


Apologies in advance for excessive paperwork, but can you also put
https://chromestatus.com/feature/5111638103687168 through the
process, requesting enterprise signoff in particular? Enterprise
folks could depend on this and might need to take some extra
action, and a "Feature deprecation" entry is the only way we can
    flag that.

On Wed, Jan 31, 2024 at 5:44 PM Mike Taylor
 wrote:

Gentle reminder to follow up on requesting
privacy/security/debuggability approvals in chromestatus
(which is currently blocking LGTMs).

On Wednesday, January 24, 2024 at 7:23:28 AM UTC-5 Mike Taylor
wrote:

Would you mind requesting reviews for the various gates
(privacy, security, debuggability) for an OT/DT in your
chromestatus entry?

On 1/19/24 10:43 PM, Thomas Guilbert wrote:



Contact emails

tguilb...@chromium.org


Explainer

None


Specification

https://fullscreen.spec.whatwg.org/#dom-document-fullscreenenabled


Summary

There was an attempt in 2014

<https://groups.google.com/a/chromium.org/g/blink-dev/c/Bxe7DnDVRZ0/m/5K61HQPrNK4J>
to deprecate and remove the HTMLVideoElement-specific
Prefixed Fullscreen APIs. This meant removing the
following APIs from HTMLVideoElement:

readonly attribute boolean webkitSupportsFullscreen;
readonly attribute boolean webkitDisplayingFullscreen;
void webkitEnterFullscreen();
void webkitExitFullscreen();
// Note the different capitalization of the "S" in
FullScreen.
void webkitEnterFullScreen();
void webkitExitFullScreen();

The overall usage of these APIs is low, and has trended
downwards over time. Here are the latest usage numbers,
as a % of total page loads:

PrefixedVideoSupportsFullscreen: 0.025%
PrefixedVideoDisplayingFullscreen: 0.082%
PrefixedVideoEnterFullscreen: 0.001%
PrefixedVideoExitFullscreen: 0.010%
PrefixedVideoEnterFullScreen: 0.001%
PrefixedVideoExitFullScreen: 0.000%


There has been an unfortunate uptick in the past 2 years
for the two following APIs, which means that it's best to
remove them now, before they see a wider adoption. These
numbers might be going up because the prefixed APIs are
also present on iOS.

https://chromestatus.com/metrics/feature/timeline/popularity/166
https://chromestatus.com/metrics/feature/timeline/popularity/167

There is an alternative set of APIs supported by all
browsers that web authors can use.

The full history of the removal attempt is here:
crbug.com/ <http://crbug.com/>346236


Goals for experimentation

The primary goal of the deprecation trial is to reduce
the amount of broken user-visible experiences as the
prefixed fullscreen APIs are removed, and to give time to
web authors to transition to the modern API (which has
been available for 5 years).


The un-prefixed fullscreen APIs have been available since
Chrome M71.


Experiment timeline

TBD, with a proposed 3 months duration


Blink component

Bl

Re: [blink-dev] Request for Deprecation Trial : HTMLVideoElement-specific Prefixed Fullscreen API

[Mike Taylor]

Gentle reminder to follow up on requesting privacy/security/debuggability 
approvals in chromestatus (which is currently blocking LGTMs).

On Wednesday, January 24, 2024 at 7:23:28 AM UTC-5 Mike Taylor wrote:

> Would you mind requesting reviews for the various gates (privacy, 
> security, debuggability) for an OT/DT in your chromestatus entry?
> On 1/19/24 10:43 PM, Thomas Guilbert wrote:
>
> Contact emails 
>
> tguilb...@chromium.org
>
> Explainer 
>
> None
>
> Specification 
>
> https://fullscreen.spec.whatwg.org/#dom-document-fullscreenenabled
>
> Summary 
> There was an attempt in 2014 
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/Bxe7DnDVRZ0/m/5K61HQPrNK4J>
>  
> to deprecate and remove the HTMLVideoElement-specific Prefixed Fullscreen 
> APIs. This meant removing the following APIs from HTMLVideoElement:
>
> readonly attribute boolean webkitSupportsFullscreen;
> readonly attribute boolean webkitDisplayingFullscreen;
> void webkitEnterFullscreen();
> void webkitExitFullscreen();
> // Note the different capitalization of the "S" in FullScreen.
> void webkitEnterFullScreen();
> void webkitExitFullScreen();
>
> The overall usage of these APIs is low, and has trended downwards over 
> time. Here are the latest usage numbers, as a % of total page loads: 
>
> PrefixedVideoSupportsFullscreen: 0.025%
> PrefixedVideoDisplayingFullscreen: 0.082%
> PrefixedVideoEnterFullscreen: 0.001%
> PrefixedVideoExitFullscreen: 0.010%
> PrefixedVideoEnterFullScreen: 0.001%
> PrefixedVideoExitFullScreen: 0.000%
>
>
> There has been an unfortunate uptick in the past 2 years for the two 
> following APIs, which means that it's best to remove them now, before they 
> see a wider adoption. These numbers might be going up because the prefixed 
> APIs are also present on iOS.
>
> https://chromestatus.com/metrics/feature/timeline/popularity/166
> https://chromestatus.com/metrics/feature/timeline/popularity/167
>
> There is an alternative set of APIs supported by all browsers that web 
> authors can use.
>
> The full history of the removal attempt is here: crbug.com/346236
>
>
> Goals for experimentation 
>
> The primary goal of the deprecation trial is to reduce the amount of 
> broken user-visible experiences as the prefixed fullscreen APIs are 
> removed, and to give time to web authors to transition to the modern API 
> (which has been available for 5 years).
>
>
> The un-prefixed fullscreen APIs have been available since Chrome M71.
>
> Experiment timeline 
>
> TBD, with a proposed 3 months duration
>
> Blink component 
>
> Blink>Fullscreen
> Blink>Media>Video
>
> TAG review 
>
> None
>
> TAG review status 
>
> Not applicable
>
> Risks 
> Interoperability and Compatibility 
>
> Web Compatibility:
>
> Removing non-standard APIs should overall help web compatibility, and 
> encourage web authors to use the unprefixed APIs. Some experiences might be 
> broken by this change, thus justifying this deprecation trial. The API has 
> been deprecated for a significant amount of time however, and usage has 
> gone down.
>
> This would only be an issue for websites that *only* support the prefixed 
> APIs.
>
>
> Interoperability:
>
>
> All browsers have shipped the new APIs, most of them using an unprefixed 
> version (Safari on iOS being the only remaining prefixed-only API). See 
> also 
> https://developer.mozilla.org/en-US/docs/Web/API/Element/requestFullscreen#browser_compatibility
>
>
> Gecko: 
>
>
> WebKit: 
>
> Web developers:
>
> Other signals:
>
> Activation 
>
> Impact on the Ads ecosystem:
>
> N/A
>
>
> 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?
>
> Potentially. The deprecation trial should give a heads up and appropriate 
> time for apps to switch over to the unprefixed APIs.
>
>
>
> Ongoing technical constraints 
>
> None
>
>
> Debuggability 
>
> N/A
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, Chrome OS, Android, and Android WebView)? 
>
> Yes - the prefixed API will be removed across all platforms.
>
> Is this feature fully tested by web-platform-tests 
> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
> ? 
>
> Yes
>
> WPTs testing the prefixes are removed: 
> https://github.com/web-platform-tests/wpt/blob/master/fullscreen/api/historical.html
>
> WPTs testing the new API: 
> https://

Re: [blink-dev] Intent to Ship: CSS light-dark() Color Function

[Mike Taylor]

LGTM2

On 1/30/24 1:11 PM, Chris Harrelson wrote:

LGTM1

On Tue, Jan 30, 2024 at 10:08 AM Rune Lillesveen 
 wrote:



Contact emails

futh...@chromium.org


Explainer

None


Specification

https://drafts.csswg.org/css-color-5/#light-dark


Summary

Allows authors to provide separate colors for light and dark
color-schemes on a per element basis. System colors and UA form
controls are rendered with different colors depending on the
color-scheme set on an element. Authors can have the same
possibility through the light-dark() function: #target {
background-color: light-dark(lime, green); } The #target element
will have a green background if the used color-scheme for the
element is 'dark'. Otherwise, the background will be lime.



Blink component

Blink>CSS



TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: Shipped/Shipping
(https://bugzilla.mozilla.org/show_bug.cgi?id=1856999) Shipped in 120

/WebKit/: Shipped/Shipping
(https://bugs.webkit.org/show_bug.cgi?id=262914) Enabled by
default: https://github.com/WebKit/WebKit/pull/23364

/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

Colors in the light-dark() function can be edited like it is
currently possible for the color-mix() function. No changes needed.



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

Existing tests:
https://wpt.fyi/results/css/css-color/light-dark-basic.html
https://wpt.fyi/results/css/css-color/light-dark-currentcolor.html
https://wpt.fyi/results/css/css-color/light-dark-inheritance.html
To be added by Chromium implementation:
https://wpt.fyi/results/css/css-color/light-dark-currentcolor-in-color.html

(https://chromium-review.googlesource.com/c/chromium/src/+/5245470/5/third_party/blink/web_tests/external/wpt/css/css-color/light-dark-currentcolor-in-color.html)




Flag name on chrome://flags

None


Finch feature name

CSSLightDarkColors


Requires code in //chrome?

False


Tracking bug

https://crbug.com/1490618


Estimated milestones

Shipping on desktop 123

Shipping on Android 123

Shipping on WebView 123



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/4909742688567296

This intent message was generated by Chrome Platform Status
.

-- 
Rune Lillesveen


-- 
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/CACuPfeRdn47UWS8NzHSxokHbkEwkyXbqqceBJg50QSGh3Q4sQg%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/CAOMQ%2Bw8UVSF9e0BeJE1dVaksDHJ4QGniGa8rqEkn401JtYDDjg%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

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

[Mike Taylor]

On 1/29/24 2:44 AM, 'Noam Rosenthal' via blink-dev wrote:


On Friday, January 26, 2024 at 5:15:28 PM UTC Vladimir Levin wrote:

On Fri, Jan 26, 2024 at 4:27 AM Noam Rosenthal
 wrote:


Finch feature nameNone

Non-finch justification

It's a web-API, exposing it gradually doesn't make sense.


I'm always unsure about this, but I believe "Finch feature name"
is the flag you'd put in runtime_enabled_features.json5. It can be
used by Finch as a kill-switch in case the feature causes some
regression in the wild. For this feature, the chrome:://flags flag
isn't there though (correct me if I'm wrong)


According to these guidelines: 
https://chromium.googlesource.com/chromium/src/+/main/third_party/blink/renderer/platform/RuntimeEnabledFeatures.md#guidelines-for-setting-feature-status
Finch + base:: features are used only for things that can cause compat 
issues, not so much for new web APIs.
I was following this guideline, if something else is required here I'd 
be happy to follow up.


See 
https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md#when-is-a-flag-required. 
The new guidance (since Aug 2022) is to add a flag for ~mostly everything.


--
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/fc780a9b-78e0-4d79-892a-181786a5201b%40chromium.org.

Re: [blink-dev] PSA: Protected Audience k-Anonymity Enforcement

[Mike Taylor]

Thanks - it looks like there are no real compatibility concerns from 
perspective of sites _breaking_ for users. Given that, a PSA for this 
change sounds fine to me.


later,
Mike

On 1/26/24 10:38 AM, Russ Hamilton wrote:
Most users should not notice a difference. The main difference is 
going to be which ads are allowed to win Protected Audience auctions. 
Some non-k-anonymous ads that would have previously won the Protected 
Audience auction will not win and the auction will return a different, 
k-anonymous ad as the winner. In the case where there are no 
k-anonymous bids in an auction then that auction will return without a 
winner. Protected Audience auctions already return with no winner in 
some cases, such as when there are no bids, so this does not introduce 
a new behavior.


On Fri, Jan 26, 2024 at 4:24 AM Mike Taylor  
wrote:


Hi Russ,

Can you say more about the compatibility implications for such a
change? AFAIU, things shouldn't "break" for users or throw errors
behind the scenes, correct?

thanks,
Mike

On 1/26/24 12:59 AM, 'Russ Hamilton' via blink-dev wrote:

We plan to start enabling the k-anonymity

<https://github.com/WICG/turtledove/blob/main/FLEDGE_k_anonymity_server.md#what-is-k-anonymity>enforcement
feature for the Protected Audience API
<https://github.com/WICG/turtledove/blob/main/FLEDGE.md>(Intent
to Ship

<https://groups.google.com/a/chromium.org/g/blink-dev/c/igFixT5n7Bs/m/ZNrDcQ2dDQAJ>).
K-anonymity enforcement has long been a part of the Protected
Audience API’s plan for improving user privacy by limiting ads
that can win Protected Audience auctions to those ads that are
k-anonymous. The k-anonymity enforcement feature limits the
ability of advertisers to target specific users by requiring each
ad be shown to a minimum number of users. This enforcement will
initially apply to up to 20% of unlabeled traffic only, meaning
the groups that are part of Chrome-facilitated testing

<https://developers.google.com/privacy-sandbox/setup/web/chrome-facilitated-testing>for
third-party cookie deprecation will not be enforced for
k-anonymity during the testing period. After the testing period,
enforcement will apply to all traffic (see timeline details at

https://developers.google.com/privacy-sandbox/relevance/protected-audience-api/k-anonymity

<https://developers.google.com/privacy-sandbox/relevance/protected-audience-api/k-anonymity>).
-- 
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/CAAG-DU2%3DfH8Q5gDDVms%2BajMA4WzS%3DvQBRPQj8jaiVzJkCdCz7g%40mail.gmail.com

<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAG-DU2%3DfH8Q5gDDVms%2BajMA4WzS%3DvQBRPQj8jaiVzJkCdCz7g%40mail.gmail.com?utm_medium=email&utm_source=footer>.




--
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/0a547272-52c9-47a0-b12d-d6125edf0968%40chromium.org.

Re: [blink-dev] Intent to Ship: Private Network Access permission to relax mixed content

[Mike Taylor]

Hi!

Could you please request the various approval bits for the review gates 
in your chromestatus entry?


On 1/26/24 11:07 AM, 'Yifan Luo' via blink-dev wrote:



Contact emails

l...@chromium.org, cl...@chromium.org


Explainer

https://github.com/WICG/private-network-access/blob/main/permission_prompt/explainer.md


Specification

https://wicg.github.io/private-network-access


Design docs


https://docs.google.com/document/d/1Q18g4fZoDIYQ9IuxlZTaItgkzfiz_tCqaEAI8J3Y1WY/edit
https://github.com/WICG/private-network-access/blob/main/permission_prompt/security_privacy_self_review.md


Summary

In order to establish connections to devices on a local network that 
do not have globally unique names, and therefore cannot obtain TLS 
certificates, this feature introduces a new option to `fetch()` to 
declare a developers' intent to talk to such a device, a new 
policy-controlled feature to gate each sites' access to this 
capability, and new headers for the server's preflight response to 
provide additional metadata.




Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess 




TAG review

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


TAG review status

Issues addressed


Chromium Trial Name

PrivateNetworkAccessPermissionPrompt


Origin Trial documentation link

https://github.com/WICG/private-network-access/blob/main/permission_prompt/explainer.md


WebFeature UseCounter name

kPrivateNetworkAccessPermissionPrompt


Risks



Interoperability and Compatibility



/Gecko/: No signal

/WebKit/: No signal

/Web developers/: Positive 
(https://github.com/WICG/private-network-access/issues/23)


/Other signals/:


Ergonomics

This new feature requires users to click on the new permission. This 
may lead users to spamming on some websites. However, this is an 
intentional move to encourage the websites to provide security 
context. The origin trial also aimed to measure the frequency of users 
getting the permissions.




Activation

No. This feature attempt to bring developers an easier way to restrict 
Private Network Access with secure context.




Security

This is a security positive feature.



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

Relevant information (client and resource IP address space) is already 
piped into the DevTools network panel. We’ll likely also represent the 
permission state in the settings pages.




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

No

Mac, Windows, Linux, Chrome OS, Fuchsia, Android, WebLayer. Not 
Android WebView because of the absence of deprecation trial 
integration (though that may be changing soon, see 
https://crbug.com/1308425). Not iOS because this requires changes in 
Blink and the network service, neither of which are used on iOS.




Is this feature fully tested by web-platform-tests

?

No

https://wpt.fyi/results/fetch/private-network-access/mixed-content-fetch.tentative.https.window.html?label=master&label=experimental&aligned&q=private-network-access 





Flag name on chrome://flags



Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

True


Tracking bug

https://crbug.com/1338439


Sample links


https://drive.google.com/file/d/1pnyQfIsXdtJnZoCBVSt4xim0yXjZ0Aqc/view?usp=sharing


Estimated milestones

Shipping on desktop 123
OriginTrial desktop last122
OriginTrial desktop first   120
DevTrial on desktop 120



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/5954091755241472


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/6MczoSFGiHo/m/IigYuhu7AwAJ Intent 
to Experiment: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG-zKU_ZS1ibT9H7e5UmoUF2OfCUq5ocsDHaCoJ2rShmPmAe

Re: [blink-dev] Intent to Ship: Support in Chrome for the VoiceIsolation getUserMedia constraint

[Mike Taylor]

Hi Per,

On 1/26/24 8:27 AM, Per Åhgren wrote:



Contact emails

p...@chromium.org


Explainer

None


Specification

https://w3c.github.io/mediacapture-extensions/#voiceisolation-constraint


Summary

This is about adding support in Chrome for the VoiceIsolation 
getUserMedia constraint 
(https://w3c.github.io/mediacapture-extensions/#voiceisolation-constraint). 
The constraint only takes effect on platforms where there is low-level 
support for voice-isolation style denoising. Currently this is limited 
to a selected number of ChromeOS devices, but further platforms will 
be added.




Blink component

Blink>WebRTC 




TAG review

None


TAG review status

Issues addressed
This is somewhat at odds with the previous response. :) Did you intend 
to link a TAG review and forget?



Risks



Interoperability and Compatibility

None



/Gecko/: No signal

/WebKit/: No signal

Could we please request signals?


/Web developers/: No signals
I assume this was added because it would be useful for certain video and 
voice web applications - are we aware of any signals from developers who 
have asked for it, or given feedback? You mention specific partners 
below - anything you can share?


/Other signals/:


Ergonomics

This will not have any impact on the performance of Chrome as it 
control system level effects, which already today are controllable at 
a system level.




Activation

No risks percieved.



Security

No risks percieved.



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



Debuggability

None



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

Yes

The constraint is supported on all platforms, but the actual platform 
support depends on where there are available matching effects at a 
system level. Initially, the only such platform is ChromeOS, where a 
subset of the devices




Is this feature fully tested by web-platform-tests

?

Yes

https://wpt.fyi/results/mediacapture-streams/GUM-non-applicable-constraint.https.html?label=experimental&label=master&aligned 
 
https://wpt.fyi/results/mediacapture-streams/MediaStreamTrack-getCapabilities.https.html?label=experimental&label=master&aligned 
 
https://wpt.fyi/results/mediacapture-streams/MediaStreamTrack-getSettings.https.html?label=experimental&label=master&aligned 
 
https://wpt.fyi/results/mediacapture-streams/MediaDevices-getSupportedConstraints.https.html?label=experimental&label=master&aligned 





Flag name on chrome://flags

None


Finch feature name

MediaCaptureVoiceIsolation


Requires code in //chrome?

False


Availability expectation

Feature is available in ChromeOS in M123


Adoption expectation

Feature is used by specific partner(s) to provide functionality within 
12 months of launch in Chrome.



Sample links


https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/mediacapture-streams/MediaStreamTrack-getSettings.https.html
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/mediacapture-streams/MediaStreamTrack-getCapabilities.https.html
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/mediacapture-streams/MediaDevices-getSupportedConstraints.https.html
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/mediacapture-streams/GUM-non-applicable-constraint.https.html


Estimated milestones

Shipping on desktop 123



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/5

Re: [blink-dev] PSA: Protected Audience k-Anonymity Enforcement

[Mike Taylor]

Hi Russ,

Can you say more about the compatibility implications for such a change? 
AFAIU, things shouldn't "break" for users or throw errors behind the 
scenes, correct?


thanks,
Mike

On 1/26/24 12:59 AM, 'Russ Hamilton' via blink-dev wrote:
We plan to start enabling the k-anonymity 
enforcement 
feature for the Protected Audience API 
(Intent to 
Ship 
). 
K-anonymity enforcement has long been a part of the Protected Audience 
API’s plan for improving user privacy by limiting ads that can win 
Protected Audience auctions to those ads that are k-anonymous. The 
k-anonymity enforcement feature limits the ability of advertisers to 
target specific users by requiring each ad be shown to a minimum 
number of users. This enforcement will initially apply to up to 20% of 
unlabeled traffic only, meaning the groups that are part of 
Chrome-facilitated testing 
for 
third-party cookie deprecation will not be enforced for k-anonymity 
during the testing period. After the testing period, enforcement will 
apply to all traffic (see timeline details at 
https://developers.google.com/privacy-sandbox/relevance/protected-audience-api/k-anonymity 
).

--
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/CAAG-DU2%3DfH8Q5gDDVms%2BajMA4WzS%3DvQBRPQj8jaiVzJkCdCz7g%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/ec9feedd-c538-4e18-b9ee-b69d635880e8%40chromium.org.

Re: [blink-dev] Re: Intent to experiment - WebAssembly JavaScript Promise Integration (update)

[Mike Taylor]

Yep - that is an official positive signal, thanks!

On 1/24/24 7:40 PM, Francis McCabe wrote:
Does this: 
https://mozilla.github.io/standards-positions/#wasm-js-promise-integration 
count as an official positive signal?


Francis

On Wed, Jan 24, 2024 at 3:09 AM Yoav Weiss (@Shopify) 
 wrote:




On Friday, January 5, 2024 at 7:25:28 PM UTC+1 Francis McCabe wrote:

This is an update to the previous intent-to-experiment (filled
out a few more fields)

Contact emails...@chromium.org


Explainerhttps://github.com/WebAssembly/js-promise-integration/blob/main/proposals/js-promise-integration/Overview.md




Specificationhttps://github.com/WebAssembly/js-promise-integration/blob/main/proposals/js-promise-integration/Overview.md



Summary

Stack Switching denotes a technology that allows programs to
suspend and resume computation. This is an active area that is
part of the WebAssembly standards track. See
https://github.com/WebAssembly/stack-switching
 and
https://github.com/WebAssembly/meetings/tree/main/stack
.
This particular feature refers to the integration between
JavaScript Promises and stack switching. This is described in
more detail in

https://docs.google.com/document/d/16Us-pyte2-9DECJDfGm5tnUpfngJJOc8jbj54HMqE9Y/edit#





Blink componentBlink>JavaScript>WebAssembly



Search tagsstack switching
,
Promise , JSPI


TAG reviewhttps://github.com/w3ctag/design-reviews/issues/809


TAG review statusPending

Risks


Interoperability and Compatibility

This spec is backed by a standardization effort. We do not
plan to ship the JSPI until it has been standardized by the
W3C Wasm WG. However, post standardization, we will depend on
all browsers implementing the standard.



/Gecko/: Positive
(https://bugzilla.mozilla.org/show_bug.cgi?id=1850627
)
Mozilla have started their own imlementation


That doesn't count as a positive signal. Please file for official
signals  (but that is not blocking
for this OT).


/WebKit/: No signal

/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?



Goals for experimentationThis specification is getting close
to finalization. We would like feedback from a wider audience
as to the utility and convenience of using the API.

In addition, we are interested in performance benchmarking in
production applications.

Ongoing technical constraints

None.



Debuggability

Developers can piggyback on existing DevTools support for
Promises to help with debugging JSPI applications. In
particular the existing mechanisms for constructing extended
stack traces from so-called Promise chains will also include
stack traces from JSPI applications.



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


I'm guessing it will be covered by tests, at least eventually?



Flag name on
chrome://flagsenable-experimental-webassembly-stack-switching

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Tracking

bughttps://bugs.chromium.org/p/v8/issues/detail?id=12191&q=owner%3Ame&can=2



Estimated milestonesOriginTrial desktop last130OriginTrial
desktop first122OriginTrial Android last130OriginTrial Android
first122OriginTrial webView las

Re: [blink-dev] Intent to Ship: Protected Audience Ad slot size in real-time bidding signals fetch and update more interest group fields

[Mike Taylor]

LGTM2

On 1/24/24 4:10 PM, Rick Byers wrote:
Great, thank you! Yep, looks like the PR is about to land to me, I'm 
satisfied. LGTM1


On Wed, Jan 24, 2024 at 10:02 AM Paul Jensen  
wrote:


That spec PR has now been reviewed and approved by the Protected
Audience team and our spec mentor.  Once a couple nits are
addressed, I imagine it'll land shortly.

On Wed, Jan 10, 2024 at 10:24 AM Rick Byers 
wrote:

Hi Paul,
This looks like a minor addition to me. My only concern is
that this spec PR
 hasn't been
reviewed yet, and we generally prefer for all tests to land
before approval. Would it be reasonable to get those done
before we approve this?

Thanks,
   Rick



On Fri, Jan 5, 2024 at 1:05 PM Paul Jensen
 wrote:


Contact emails

pauljen...@chromium.org


Explainer

Ad slot size in real-time bidding signals fetch:
https://github.com/WICG/turtledove/pull/928


Update more interest group fields: Already covered by
explainer




Specification

Ad slot size in real-time bidding signals fetch:
https://github.com/WICG/turtledove/pull/954


Update more interest group fields:
https://github.com/WICG/turtledove/pull/907

https://github.com/WICG/turtledove/pull/953



Summary

Ad slot size in real-time bidding signals fetch:

Protected Audience ad selection auctions allow buyers to
fetch real-time signals from their key-value server. 
Besides being used for calculating bid prices, these
signals can also be used for prioritizing and filtering
potential ad candidates.  The more ad candidate filtration
and prioritization that we can enable, the more performant
the auction is (e.g. less browser resource utilization)
and the higher the quality of the chosen ad candidates is.
This feature extends the signals about the page where the
ad will be displayed from just its domain name, to also
include the size of the ad slots on the page, which is a
very useful signal for filtering out ads that cannot be
rendered in that slot size.


Allow updating interest group’s userBiddingSignals and
executionMode:

Protected Audience has always supported updating interest
group fields, but for historical reasons did not support
updating the interest group field named
userBiddingSignals, and for no obvious reason did not
support updating executionMode. This change is a small
extension to Protected Audience interest group updating to
support updating these fields, making the API more useful
by being able to update/refresh the fields with more up to
date information.


Blink component

Blink>InterestGroups




TAG review

The parent proposal, Protected Audience, is still pending:
https://github.com/w3ctag/design-reviews/issues/723



TAG review status

Pending


Risks


Interoperability and Compatibility

These are both optional new features so we do not expect
them to cause compatibility breakage.


Gecko & WebKit: No signal on parent proposal, Protected
Audience.  Asked in the Mozilla forumhere
,
and in the Webkit forum here
.


Web developers:

Ad slot size in real-time bidding signals fetch: Interest
from multiple adtechs here
.

Update more interest group fields: Interest from adtech
here .


Debuggability

Ad slot size in real-time bidding signals fetch

Re: [blink-dev] Intent to Ship: Long Animation Frame Timing

[Mike Taylor]

LGTM1

On 1/17/24 9:32 AM, 'Noam Rosenthal' via blink-dev wrote:

Updating that Mozilla gave an official positive signal:
https://github.com/mozilla/standards-positions/pull/962

Updated the corresponding chromestatus field.

On Monday, January 15, 2024 at 10:34:19 AM UTC Noam Rosenthal wrote:



Regarding the spec, I see that it's monkeypatching WebIDL, DOM
and HTML. This feels odd in a WG-adopted spec.
Have you tried to PR these changes upstream?


Was planning to upstream the monkey-patches once we have formal
positive signals from Gecko/WebKit.

--
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/1fe0c37e-d02c-474e-824f-498d7866c598n%40chromium.org 
.


--
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/63bf8b4c-c76f-4061-9f5b-dfd639bb2743%40chromium.org.

Re: [blink-dev] Request for Deprecation Trial : HTMLVideoElement-specific Prefixed Fullscreen API

[Mike Taylor]

Would you mind requesting reviews for the various gates (privacy, 
security, debuggability) for an OT/DT in your chromestatus entry?


On 1/19/24 10:43 PM, Thomas Guilbert wrote:



Contact emails

tguilb...@chromium.org


Explainer

None


Specification

https://fullscreen.spec.whatwg.org/#dom-document-fullscreenenabled


Summary

There was an attempt in 2014 
 
to deprecate and remove the HTMLVideoElement-specific Prefixed 
Fullscreen APIs. This meant removing the following APIs from 
HTMLVideoElement:


readonly attribute boolean webkitSupportsFullscreen;
readonly attribute boolean webkitDisplayingFullscreen;
void webkitEnterFullscreen();
void webkitExitFullscreen();
// Note the different capitalization of the "S" in FullScreen.
void webkitEnterFullScreen();
void webkitExitFullScreen();

The overall usage of these APIs is low, and has trended downwards over 
time. Here are the latest usage numbers, as a % of total page loads:


PrefixedVideoSupportsFullscreen: 0.025%
PrefixedVideoDisplayingFullscreen: 0.082%
PrefixedVideoEnterFullscreen: 0.001%
PrefixedVideoExitFullscreen: 0.010%
PrefixedVideoEnterFullScreen: 0.001%
PrefixedVideoExitFullScreen: 0.000%


There has been an unfortunate uptick in the past 2 years for the two 
following APIs, which means that it's best to remove them now, before 
they see a wider adoption. These numbers might be going up because the 
prefixed APIs are also present on iOS.


https://chromestatus.com/metrics/feature/timeline/popularity/166
https://chromestatus.com/metrics/feature/timeline/popularity/167

There is an alternative set of APIs supported by all browsers that web 
authors can use.


The full history of the removal attempt is here: crbug.com/ 
346236



Goals for experimentation

The primary goal of the deprecation trial is to reduce the amount of 
broken user-visible experiences as the prefixed fullscreen APIs are 
removed, and to give time to web authors to transition to the modern 
API (which has been available for 5 years).



The un-prefixed fullscreen APIs have been available since Chrome M71.


Experiment timeline

TBD, with a proposed 3 months duration


Blink component

Blink>Fullscreen
Blink>Media>Video



TAG review

None


TAG review status

Not applicable


Risks


Interoperability and Compatibility

Web Compatibility:

Removing non-standard APIs should overall help web
compatibility, and encourage web authors to use the unprefixed
APIs. Some experiences might be broken by this change, thus
justifying this deprecation trial. The API has been deprecated
for a significant amount of time however, and usage has gone down.

This would only be an issue for websites that *only* support
the prefixed APIs.


Interoperability:


All browsers have shipped the new APIs, most of them using an 
unprefixed version (Safari on iOS being the only remaining 
prefixed-only API). See also 
https://developer.mozilla.org/en-US/docs/Web/API/Element/requestFullscreen#browser_compatibility



Gecko:


WebKit:


Web developers:


Other signals:


Activation

Impact on the Ads ecosystem:

N/A



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?


Potentially. The deprecation trial should give a heads up and 
appropriate time for apps to switch over to the unprefixed APIs.





Ongoing technical constraints

None



Debuggability

N/A


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

Yes - the prefixed API will be removed across all platforms.


Is this feature fully tested by web-platform-tests

?

Yes

WPTs testing the prefixes are removed: 
https://github.com/web-platform-tests/wpt/blob/master/fullscreen/api/historical.html


WPTs testing the new API: 
https://github.com/web-platform-tests/wpt/tree/master/fullscreen/api




Flag name on chrome://flags

None


Finch feature name

PrefixedVideoFullscreen


Non-finch justification

None


Requires code in //chrome?

False


Launch bug

None


Estimated milestones

DevTrial on desktop



123


DevTrial on Android



123



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5259513871466496

--
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...

Re: [blink-dev] Re: Intent to Ship: Allow for WebAuthn credential creation in a cross-origin iframe

[Mike Taylor]

LGTM3

On 1/24/24 11:24 AM, Yoav Weiss (@Shopify) wrote:

LGTM2

On Tuesday, January 23, 2024 at 4:40:55 PM UTC+1 Rick Byers wrote:

It would be great to get an official response from WebKit and
Mozilla to make sure we understand their position, but I don't
think we should block further on it. I understand why they might
have concerns given their engine's preference for embeds being
anonymous. In Chromium we've been consistent in working to
preserve personalized / authenticated embeds (and so the rich
composition of web pages) where we can ensure it doesn't conflict
with our privacy goals around clear user transparency and control
over sharing of information (fenced frames
<https://developers.google.com/privacy-sandbox/relevance/fenced-frame>
being the most obvious example). We know that avoiding popups and
redirects helps reduce drop-off in any authentication or commerce
flow, and combined with Stripe's public statement of support, I'm
convinced this is a valuable capability.

Everything else looks great to me, so LGTM1

On Tue, Jan 23, 2024 at 10:23 AM Stephen McGruer
 wrote:

Fyi; I've retargeted this launch to M123 since it seems clear
it won't get the necessary Blink approvals in time for M122
(which has already branched).

On Wednesday, January 17, 2024 at 11:07:56 AM UTC-5 Stephen
McGruer wrote:

Sounds great:

https://github.com/WebKit/standards-positions/issues/304
<https://github.com/WebKit/standards-positions/issues/304>
https://github.com/mozilla/standards-positions/issues/964
<https://github.com/mozilla/standards-positions/issues/964>

Will update if we get any reply :)

On Wed, 17 Jan 2024 at 10:25, Mike Taylor
 wrote:

I think erring on the side of requesting a signal here
is a good idea. :)

On 1/17/24 8:33 AM, Stephen Mcgruer wrote:

API owners: It wasn't clear to me if I should still
be formally requesting signals from WebKit and Gecko
in the case of a change to an API (WebAuthn) where
the change has been ratified + landed by the
associated Working Group. The change is in some ways
'minor', but in other ways it is significant new
behavior (allowing use of part of the API in
cross-origin iframes, where it wasn't allowed before)
and so perhaps requesting signals is warranted? Let
me know please :D

On Wed, 17 Jan 2024 at 08:31, Stephen Mcgruer
 wrote:


Contact emails

smcgr...@chromium.org


Explainer

None


Specification


https://w3c.github.io/webauthn/#publickey-credentials-create-feature

<https://w3c.github.io/webauthn/#publickey-credentials-create-feature>


Summary

This feature allows web developers to create
WebAuthn[0] credentials (that is, "publickey"
credentials, aka passkeys) in cross-origin
iframes. Two conditions are required for this new
ability: 1. The iframe has a
publickey-credentials-create-feature permission
policy. 2. The iframe has transient user
activation. This will allow developers to create
passkeys in embedded scenarios, such as after an
identity step-up flow where the Relying Party is
providing a federated identity experience. [0]:
https://w3c.github.io/webauthn/
<https://w3c.github.io/webauthn/>


Blink component

Blink>WebAuthentication

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebAuthentication>


TAG review

None


TAG review status

Not applicable


Risks


Interoperability and Compatibility

There is only minor interoperability risk if
other browsers do not adopt this change. In a
browser that does not support credential creation
inside a cross-origin iframe, attempting to call
navigator.credentials.create results in an
asynchronous-but-immediate error message
indic

Re: [blink-dev] Intent to Extend Experiment: Soft Navigation Heuristics

[Mike Taylor]

LGTM to extend to 123 inclusive.

On 1/22/24 10:00 PM, Ian Clelland wrote:



Contact emails

iclell...@chromium.org


Explainer

https://bit.ly/soft-navigation
https://docs.google.com/document/d/1eUyQg3YLEmYjrTMC3p-F1MilECwCynhM6WIbIo05SPU/edit


Specification

https://wicg.github.io/soft-navigations


Summary

Exposes the (experimental) soft navigation heuristics [1] to web 
developers, using both PerformanceObserver and the performance 
timeline. [1] https://bit.ly/soft-navigation




Blink component

Blink>PerformanceAPIs 




TAG review

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


TAG review status

Issues addressed


Chromium Trial Name

SoftNavigationHeuristics


Link to origin trial feedback summary

https://github.com/WICG/soft-navigations/issues


Origin Trial documentation link

https://github.com/WICG/soft-navigations#soft-navigations


Risks



Interoperability and Compatibility

None



/Gecko/: No signal 
(https://github.com/mozilla/standards-positions/issues/854)


/WebKit/: No signal 
(https://github.com/WebKit/standards-positions/issues/235)


/Web developers/: Strongly positive 
https://github.com/WICG/proposals/issues/71#issuecomment-1325856231 
https://twitter.com/yoavweiss/status/1575191332775026688


/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



Reason this experiment is being extended

We are still collecting feedback from partners, who are evaluating the 
suitability of this API to replace existing ad-hoc methods of 
measuring soft navigations, including some who were only recently able 
to start experimenting. Additionally, we have made changes to the 
heuristics, in response to testing and feedback, to eliminate some 
false-positive detections, and better match the behaviour of 
real-world single-page apps. Some of these changes initially went out 
in Chrome 120, and were refined in Chrome 121; some will be released 
with Chrome 122. We'd like to give developers a chance to experiment 
with these changes, to help inform any future adjustments that need to 
be made. After Chrome 123, we intend to pause the experiment while we 
act on all of the feedback, and decide whether further changes to the 
heuristics are necessary, or if the API is in good enough shape to 
consider shipping.




Ongoing technical constraints

None.



Debuggability

None



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

No


Is this feature fully tested by web-platform-tests

?

Yes


Flag name on chrome://flags

None


Finch feature name

SoftNavigationHeuristics


Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1338390


Estimated milestones

OriginTrial desktop last123
OriginTrial desktop first   117

OriginTrial Android last123
OriginTrial Android first   117

OriginTrial webView last123
OriginTrial webView first   117



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5144837209194496


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfV3qRFx0i-eGJFSzqE8bnbX8XYJCvXAj0LfvO0icPo_jA%40mail.gmail.com Intent 
to Experiment: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUb_Gn_5gGy8SnChg5KH2JN57Gv0NhnHN7Q_kH0Aa17CQ%40mail.gmail.com
Intent to Extend Experiment: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfULP5d3fNCAqeO2gLP56R3HCytmaNk%2B9kpYsC2dj4%3DqoQ%40mail.gmail.com
Intent to Ship: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfULP5d3fNCAqeO2gLP56R3HCytmaNk%2B9kpYsC2dj4%3DqoQ%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/CAK_TSXKaXYQ8hYmRvkmMEYNm_Fddpr9EotUPy5-0bu8gaQbwQw%40mail.gmail.com 
.


--
You received this message because you are subscribed to the Go

Re: [blink-dev] Intent to Ship: Allow Cross-Origin Subframes to Send Automatic Beacons

[Mike Taylor]

Thanks Liam. This seems fine to me given that both parties need to opt in.

LGTM1

On 1/22/24 6:10 PM, Liam Brady wrote:

Hi Mike,

"crossOrigin=true" is just a typo. "crossOrigin" was the original 
naming convention for "crossOriginExposed". It was renamed during code 
review, but I forgot to update the I2S wording to match that.


We chose to not go with Permissions-Policy for a few reasons. First is 
that for fenced frames created through something like Protected 
Audience, they have a fixed list of permissions that must be enabled 
for the frame to load, so refactoring that to support one permissions 
policy that can be either enabled or enabled would be a lot of effort. 
Doing that would also allow 1 bit of information to leak from the 
embedder to the fenced frame, which is the whole reason we locked down 
permissions policies in the first place. We also didn't want the 
embedder to have any control over how this header is set (such as 
having an embedder opt in on the frame's behalf), and since 
permissions policies are based on inheritance, that was something we 
needed to avoid.
On Friday, January 19, 2024 at 3:43:44 PM UTC-5 mike...@chromium.org 
wrote:


Hi Liam,

On 1/16/24 3:49 PM, 'Liam Brady' via blink-dev wrote:


Contact emails

lbr...@google.com, shiva...@chromium.org, jka...@chromium.org


Explainer(s)

https://github.com/WICG/turtledove/pull/904



Spec(s)

https://github.com/WICG/fenced-frame/pull/133



Summary

As part of the Privacy Sandbox experiment, we introduced a way
for beacons to be sent automatically if a top-level navigation is
initiated from within an ad frame

.
At the time, we restricted this feature to frames and subframes
that were same-origin to the root ad frame. However, there is a
use case that this is not able to handle. With third-party ad
serving (3PAS), the actual contents of the ad (including
links/click handlers) are loaded in a cross-origin subframe.
Because it is cross-origin, the frame does not get access to the
automatic beacon API, and therefore is not able to report a
top-level navigation when a user clicks on the ad.


A cross-origin subframe can now opt in to sending automatic
beacons by setting a new response header:
"Allow-Fenced-Frame-Automatic-Beacons". The cross-origin frame
still cannot set automatic beacon data; instead, the main ad
frame will set the automatic beacon data, but opt in to having
the data be used for cross-origin automatic beacons using a new
"crossOrigin=true" parameter. When these 2 criteria are met, the
cross-origin subframe will send an automatic beacon when a
top-level navigation happens.


Is "crossOrigin=true" different than the "crossOriginExposed"
boolean defined in the spec? Or just a typo?

Another question: is there any reason you chose to create a new
HTTP header, rather than use something like Permissions-Policy?
(Maybe that's not supported for fenced frames?)



This feature will also fix a separate issue
brought
up externally and allow for ad components to opt into sending
automatic beacons without needing to invoke
setReportEventDataForAutomaticBeacons(); they instead will just
need to supply the "Allow-Fenced-Frame-Automatic-Beacons"
response header. This will not remove the existing way for ad
components to opt into sending beacons.


Blink component

Blink>FencedFrames




TAG reviews and status

Fenced frames existing TAG review appended with these spec
changes https://github.com/w3ctag/design-reviews/issues/838#




Link to Origin Trial feedback summary

No Origin Trial performed


Is this feature supported on all six Blink platforms (Windows,
Mac, Linux, Chrome OS, Android, and Android WebView)?

Supported on all the above platforms except Android WebView.


Debuggability

Additional debugging capabilities are not necessary for these
feature changes.


Risks


Compatibility

This is an added functionality and is backward compatible.


Interoperability

There are no interoperability risks as no other browsers have
decided to implement these features yet.


Is this feature fully tested by web-platform-tests

?
Link to test suite results from wpt.fyi .

Yes. New automatic beacon tests have been added to test
cross-

Re: [blink-dev] New API owner: Domenic Denicola

[Mike Taylor]

+1 - congrats! I look forward to Domenic bringing his decade plus of web 
and standards experience to the group.


(I think it was somewhere between 2010-2012 that I first saw Domenic 
give a talk at the NYC.js meetup and have been a fan since).


On 1/21/24 4:24 AM, Yuki Shiino wrote:

Congratulations!!!


2024年1月20日(土) 17:44 Mathias Bynens :

Thanks and congratulations, Domenic!

On Fri, Jan 19, 2024 at 9:59 PM Rick Byers 
wrote:

Hi blink-dev,
+Domenic Denicola  has
volunteered to donate his time and considerable web platform
expertise to reviewing intent threads as an API owner. Domenic
is very active in the web standards community including as an
HTML editor, runs our spec mentors
 program and has
contributed helpfully to a wide variety of intent discussions
over the past year. His nomination

was reviewed and approved
 by the existing
API owners today.

Thank you Domenic!
   Rick
-- 
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/CAFUtAY-Zq2WDWz0_UhfweWd4e4c1dr8OTaCaLXiW289pNKfDDg%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/CADizRgadwW%2B6a-G9nycsuWdbzKpCFQcW%3Dj%3DutS48%2B6ULMWvC4w%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/CAN0uC_TG%2BchJr8dEBBPczJVKPtb4Pdc1OV0WQd-cFG-2EDbsww%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/3f88c852-9c36-4090-a64a-3d4019afec83%40chromium.org.

[blink-dev] Re: Intent to Ship: New ALPS code point

[Mike Taylor]

In our OWNERS meeting this week, there was some confusion on what's 
being proposed here (which is understandable, this isn't quite a typical 
intent for web exposed feature). Here's a summary of what we're trying 
to accomplish:


1) We shipped support for the ACCEPT_CH frame over h2 and h3 back in 
M96, which relies on the TLS ALPS protocol extension.
2) There are 2 parts to this: the client being able to understand 
ALPS/ACCEPT_CH (and in return do something useful), and the server being 
able to send it.
3) Because of a (long fixed) bug present in Chromium's implementation, 
it's risky for a server to send too much data via ACCEPT_CH, so it's 
usefulness is potentially limited.
4) In order to guarantee that older clients don't have this bug, we 
propose to rev the version (aka, code point) at the protocol layer. This 
way, if a server sends the new code point and the client understands it, 
it can send a larger payload without triggering the bug (which may 
result in sad things like a connection being refused).
5) This is sort of web observable, but right now if servers that support 
the old code point continue to send the old code point - nothing will 
break. Chromium will support both for now, with hopes to deprecate and 
remove the older one in the future when we're confident it won't result 
in performance regressions for servers sending ACCEPT_CH (since this is 
a performance optimization).


I hope that helps clear it up, and I'm sure Victor or David will chime 
in if I'm getting something wrong. :)


And to be clear - this isn't a request for a deprecation or removal 
(yet), but for shipping the new code point.


On 1/17/24 11:16 AM, Victor Tan wrote:
If the server received the new code point, while it doesn't support, 
the ALPS extension will ignore. This also mean client might not know 
the server's client hints preferences before the first request. 
Currently, only few sites using the ALPS extension.  As TLS extension 
is negotiated, the server need to support both code points during the 
transition period, after some time, the server can drop the old one.


On Wednesday, January 17, 2024 at 11:00:13 AM UTC-5 Yoav Weiss wrote:

On Saturday, January 13, 2024 at 12:08:33 AM UTC+1 Victor Tan wrote:

Contact emails

victor...@chromium.org ,
miketa...@chromium.org ,
david...@chromium.org 


Explainer


https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md




Specification

https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability



https://tools.ietf.org/html/draft-vvv-httpbis-alps


https://tools.ietf.org/html/draft-vvv-tls-alps


Summary

Shipping a new code point (17613) for TLS ALPS extension to
allow adding more data in the ACCEPT_CH HTTP/2 and HTTP/3
frame. The ACCEPT_CH HTTP/2 frame with the existing TLS ALPS
extension code point (17513) had an arithmetic overflow bug
in the Chrome ALPS decoder. It
limits the capability to add more than 128 bytes data (in
theory, the problem range is 128 bytes to 255 bytes) to the
ACCEPT_CH frame. With the new ALPS code point, we can fully
mitigate the issue.


Blink component

Blink>Network>ClientHints




TAG review

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



TAG review status

Closed


Risks
Interoperability and Compatibility

This is switching to a new code point for the TLS ALPS
extension. It won’t change the design of ALPS and ACCEPT_CH
mechanism implementation.  The main source of compatibility
risk is that it causes conflicts with ALPS negotiation since
some clients could still use the old code point while others
are switching to use the new code point.  The ALPS extension
could be ignored if the code point doesn’t match during
negotiation, which means the server's client hints preferences
won’t be delivered in the ACCEPT_CH HTTP/2 and HTTP/3 frame. 
We mitigate this by enabling servers to support both code
points, monitoring both code points usage and removing the old
ALPS code point support in a future intent once the usage is
low enough. We also split the rollout into two phases: we
first start to en

Re: [blink-dev] Intent to Ship: Allow Cross-Origin Subframes to Send Automatic Beacons

[Mike Taylor]

Hi Liam,

On 1/16/24 3:49 PM, 'Liam Brady' via blink-dev wrote:


Contact emails

lbr...@google.com , shivani...@chromium.org 
, jkar...@chromium.org 




Explainer(s)

https://github.com/WICG/turtledove/pull/904 




Spec(s)

https://github.com/WICG/fenced-frame/pull/133 




Summary

As part of the Privacy Sandbox experiment, we introduced a way for 
beacons to be sent automatically if a top-level navigation is 
initiated from within an ad frame 
. 
At the time, we restricted this feature to frames and subframes that 
were same-origin to the root ad frame. However, there is a use case 
that this is not able to handle. With third-party ad serving (3PAS), 
the actual contents of the ad (including links/click handlers) are 
loaded in a cross-origin subframe. Because it is cross-origin, the 
frame does not get access to the automatic beacon API, and therefore 
is not able to report a top-level navigation when a user clicks on the ad.



A cross-origin subframe can now opt in to sending automatic beacons by 
setting a new response header: "Allow-Fenced-Frame-Automatic-Beacons". 
The cross-origin frame still cannot set automatic beacon data; 
instead, the main ad frame will set the automatic beacon data, but opt 
in to having the data be used for cross-origin automatic beacons using 
a new "crossOrigin=true" parameter. When these 2 criteria are met, the 
cross-origin subframe will send an automatic beacon when a top-level 
navigation happens.


Is "crossOrigin=true" different than the "crossOriginExposed" boolean 
defined in the spec? Or just a typo?


Another question: is there any reason you chose to create a new HTTP 
header, rather than use something like Permissions-Policy? (Maybe that's 
not supported for fenced frames?)




This feature will also fix a separate issue 
brought 
up externally and allow for ad components to opt into sending 
automatic beacons without needing to invoke 
setReportEventDataForAutomaticBeacons(); they instead will just need 
to supply the "Allow-Fenced-Frame-Automatic-Beacons" response header. 
This will not remove the existing way for ad components to opt into 
sending beacons.



Blink component

Blink>FencedFrames 




TAG reviews and status

Fenced frames existing TAG review appended with these spec changes 
https://github.com/w3ctag/design-reviews/issues/838# 




Link to Origin Trial feedback summary

No Origin Trial performed


Is this feature supported on all six Blink platforms (Windows, Mac, 
Linux, Chrome OS, Android, and Android WebView)?


Supported on all the above platforms except Android WebView.


Debuggability

Additional debugging capabilities are not necessary for these feature 
changes.



Risks


Compatibility

This is an added functionality and is backward compatible.


Interoperability

There are no interoperability risks as no other browsers have decided 
to implement these features yet.



Is this feature fully tested by web-platform-tests 
? 
Link to test suite results from wpt.fyi .


Yes. New automatic beacon tests have been added to test cross-origin 
beacons.


automatic-beacon-cross-origin-false.https.html (test 
) 
(results 
)


automatic-beacon-cross-origin-navigation.https.html (test 
) 
(results 
)


automatic-beacon-cross-origin-no-data.https.html (test 
) 
(results 
)


automatic-beacon-cross-origin-no-opt-in.https.html (test 
) 
(results 
)


automatic-beacon-use-ancestor-data.https.html (test 
) 
(results 

Re: [blink-dev] Intent to Ship: RTCRtpSender setParameters() extensions for requesting the generation of a key frame

[Mike Taylor]

LGTM2

On 1/19/24 12:41 PM, Chris Harrelson wrote:

LGTM1

On Fri, Jan 19, 2024 at 7:36 AM 'Vladimir Levin' via blink-dev 
 wrote:


Thank you for the detailed explanation. It's hard to decipher from
meeting notes whether a discussion is bikeshedding or serious
objections :)

Based on your description, it does seem like there is good consensus

Thanks,
Vlad

On Fri, Jan 19, 2024 at 5:14 AM Henrik Boström 
wrote:

Having participated in both the WG meeting and the following
editors meetings where the editors merged the PR, my memory
too is that there was wide support for this.

To make sure I'm not misremembering, I rewatching the
recording
 just
now. I don't hear anybody challenging the use case, it's
mostly discussions about whether this should be considered a
"parameter" or not. Philipp explains why it needs to be set at
the same time as the other parameters even though it's not a
traditional parameter, Harald expresses a need for
getParameters and setParameters to work with the same params
and Florent suggests a way to solve this by introducing a
second argument to the method. There are some questions about
whether the use case might already be covered by the "active"
flag, a point first made by Jan-Ivar, but there are problems
with that IMO and ultimately we ran out of time. So there was
some ambiguity if this was just bike shedding or if there were
legitimately other options, but most voices were supporting
this and the recorded outcome was to "refine the PR". So these
discussions continued in follow-ups.

The follow-ups happened during the editors meeting where the
PR  was
refined, approved by Jan-Ivar (Mozilla), Bernard (Microsoft)
and myself (Google) and merged. We went with Florent's
suggestion of a second argument which avoided the parameter
issue that Harald initially raised. My understanding is that
everyone was happy with it, but I can't speak for other people.
On Wednesday, January 17, 2024 at 6:02:06 PM UTC+1
vmp...@google.com wrote:

Based on the WG discussion (meeting notes:
https://www.w3.org/2023/05/16-webrtc-minutes.html#t04) it
didn't seem that there is a very strong consensus that
this is a right spot to add an extra parameter. There are
also no signals on the RFPs, but the spec PR has landed.
How would you assess the vendor support for this change?

Thanks,
Vlad

On Fri, Jan 12, 2024 at 3:10 AM 'Harald Alvestrand' via
blink-dev  wrote:

This extension has consensus in the WEBRTC WG, and CLs
are approved by the Chrome WebRTC folks.


On Fri, Jan 12, 2024 at 8:01 AM 'Philipp Hancke' via
blink-dev  wrote:


Contact emails

phan...@microsoft.com, ma...@microsoft.com


Explainer


https://fippo.github.io/webrtc-explainers/rtcrtpsender-setparameters




Specification


https://w3c.github.io/webrtc-extensions/#rtcrtpsender-setparameters-keyframe




Summary

Adds an optional second parameter to WebRTC's
RTCRtpSender.setParameters call which can be used
to ask the associated encoder to generate a key frame.


Blink component

Blink>WebRTC>PeerConnection




TAG review

None, small addition to WebRTC


TAG review status

Not applicable


Risks


Interoperability and Compatibility

None


Gecko: No signal
(https://github.com/mozilla/standards-positions/issues/858
)


WebKit: No signal
(https://github.com/WebKit/standards-positions/issues/237
)


Web developers: Positive Microsoft Teams is quite
interested in the feature.


 

Re: [blink-dev] Intent to Ship: PointerEvent.deviceId for Mult-Pen Inking

[Mike Taylor]

Forgive my ignorance around this API generally, but is there any reason 
the spec can't require a single value? If not, why not?


On 1/18/24 3:05 PM, 'Sahir Vellani' via blink-dev wrote:
Appreciate the feedback! Yes the PR was reviewed by WG members for any 
major concerns; but I believe there will be more comprehensive 
feedback once the Level 3 spec lands. Regarding your concern, the 
language is based on that of PointerEvent.pointerId. The ultimate goal 
here is to differentiate between devices, and like pointerId, the way 
the ids are assigned has been left to the UA. I think web developers 
should be able to rely on PointerEvent.pointerType to confirm whether 
the pointer event comes from the primary mouse device. In Chromium, we 
transmit 1 for the mouse for PointerEvent.deviceId.


On Wednesday, January 17, 2024 at 7:39:48 AM UTC-8 
yoav...@chromium.org wrote:


On Wednesday, January 17, 2024 at 3:51:59 PM UTC+1
vmp...@google.com wrote:

On Thu, Jan 11, 2024 at 6:08 PM 'Sahir Vellani' via blink-dev
 wrote:

Hi all, good news!

Reviving this thread because we have accomplished:
1. TAG Review Completion: Extending the PointerEvent with
Unique DeviceId Attribute · Issue #880 ·
w3ctag/design-reviews (github.com)
<https://github.com/w3ctag/design-reviews/issues/880> Resolution:
Satisfied
2. WICG Repository for standardization discussions. Link
to explainer in WICG Repo:
pointer-event-extensions/pointer-event-device-id-explainer.md
at main · WICG/pointer-event-extensions (github.com)

<https://github.com/WICG/pointer-event-extensions/blob/main/pointer-event-device-id-explainer.md>
3. A PR against the PointerEvent spec with proposed
changes: Add deviceId to PointerEvent spec by sahirv ·
Pull Request #495 · w3c/pointerevents (github.com)
<https://github.com/w3c/pointerevents/pull/495/files> We
will be waiting for Spec Level 3 to come out before this
can be merged; but this provides an official starting
point for the standardized description of this feature.
Based on the feedback received, I don't anticipate any
major changes to the design.


Thanks for the PR! Was it reviewed by other WG members?
For example, "User agents MAY reserve a generic `deviceId` value
of `0` or `1` for events generated by the primary mouse device."
seems risky from an interop perspective. E.g. developers may rely
on some UAs doing that and fail when others don't.


For posterity, I was initially unsure why this wasn't an issue
on the w3c/pointerevents, but it does seem like the discussion
happened there and folks agreed to move this in WICG:
https://github.com/w3c/pointerevents/issues/353
<https://github.com/w3c/pointerevents/issues/353> \o/


Reviewers, can we please get another review for shipping
this feature?

On Wednesday, October 18, 2023 at 8:55:43 AM UTC-7
sligh...@chromium.org wrote:

I agree that this needs a spec PR and the explainer
should at least migrate to WICG before we agree to
ship. Also, can you please link to the TAG review?

Best,

Alex

On Tuesday, October 17, 2023 at 4:16:41 AM UTC-7 Yoav
    Weiss wrote:

On Tue, Oct 17, 2023 at 12:42 AM Mike Taylor
 wrote:

LGTM1

On 10/15/23 11:07 AM, 'Sahir Vellani' via
blink-dev wrote:

Thanks for the feedback, I wasn't aware they
were mandatory. The steps have been started,
just awaiting feedback from Security and
Privacy reviewers. I've received LGTMs for
all other areas. After our response to
WebKit's question, they did not have any
further follow-up questions. So I'm assuming
all is well.

On Wednesday, October 11, 2023 at 4:59:15 AM
UTC-7 Daniel Bratell wrote:

I see that various mandatory steps in
chromestatus
(privacy,security,enterprise,debuggability,testing)
seems to be unstarted. It is possible
they were made mandatory after you create
the entry, but it would be good if you
could get them started now at least.

 

Re: [blink-dev] Intent to Ship: Scroll To Text Fragment

[Mike Taylor]

If you believe you've found a bug, please file a new issue at 
crbug.com/new. This is not a support forum.


thanks,
Mike

On 1/17/24 7:30 PM, Adam Semenenko wrote:
Unfortunately the opt-out feature no longer seems to work, and now 
Chrome is randomly highlighting text and scrolling halfway through a 
page even when no highlighting was requested.


The colours are getting even more garish over time too.

Is there any other way to disable the highlighting?

On Wed, 25 Oct 2023 at 09:53, Adam Semenenko 
 wrote:


Sorry, this is just an email isn't it? The thread was closed. I've
heard many things from different people, but I'm still
experiencing the problem. I'm not sure who any of you are either,
is there some sort of guide for who's in charge of who I can
email? It'd be nice if the OP was could reply to their thread,
instead of just cherry picking praise and running away with an
idea that could be improved.

It's not a Chrome product feedback by the way, as I understand
there's the same problem in other browsers.

On Thu, 19 Oct 2023, 06:04 K. Moon,  wrote:

Please stop posting this kind of feedback to this thread;
you've been informed multiple times by multiple individuals
that this is not the right forum for Chrome product feedback.

Continuing to persist in doing so may lead to intervention,
like blocking your ability to post entirely.

On Tue, Oct 17, 2023, 10:15 PM Adam Semenenko
 wrote:

Here's another example of useless and distracting
highlighting. What is it about the first two sentences
that need highlighting? Is their position not significant
enough?

On Thu, 5 Oct 2023, 11:40 Adam Semenenko,
 wrote:

Is it still not possible to disable this distraction
yet? I found a wonderfully ironic example today - see
attached screenshot.

There seem to be only two ways that this feature is used:

1. The first sentence of a page is highlighted, which
is completely redundant and patronising. Yes Chrome,
thank you for highlighting the very first sentence.
However could I cope without you.

2. A random sentence halfway through the page is
highlighted. This is never what I want: I always want
to read the page so that I can understand the sentence
in context.



On Wed, 5 May 2021, 06:40 Adam Semenenko,
 wrote:

Hi all,

Do you know if there's a consistent and easy way
to disable this yet? It's really distracting for
me. When I google something and click on a result,
I like consistent behaviour and to see the whole
page from the start. I feel disrupted when I'm
randomly dropped into the middle of a page with a
garish colour jumping out at me.

Cheers,
Adam

On Mon, 26 Apr 2021 at 21:54, 'Grant Wang' via
blink-dev  wrote:

Hi all,

It’s been roughly nine months since we first
utilized Scroll To Text Fragment in featured
snippets in Google Search. In that time, we’ve
seen that Scroll To Text Fragment links help
us towards our goal to get users the
information they need.  In particular:

 1. We find that Scroll To Text Fragment links
increase engagement -- users are less
likely to visit a page and then quickly
hit the back button, because they can more
readily understand how relevant the page
is to their search after arriving at the page.

 2. In user surveys, we find that users prefer
being scrolled to the relevant section of
a page that’s in a featured snippet. Users
who were scrolled to the relevant section
preferred the experience at a rate of 2:1;
even users who were not scrolled in the
control group preferred the option of
being scrolled to the relevant section at
the same 2:1 rate.

Besides their usage on Google Search, we’ve
noticed scroll to text fragments links during
our crawls of the web.  One of the best use
cases has b

Re: [blink-dev] Re: Intent to Experiment: Captured Surface Control

[Mike Taylor]

Oops, missed Chris' email on this. But you're double approved now. :)

On 1/17/24 8:32 PM, Mike Taylor wrote:


LGTM to experiment from M122 to M127 inclusive.

On 1/17/24 9:09 AM, 'Elad Alon' via blink-dev wrote:
A quick clarification, btw, that we have a partner in mind that's 
eager to start origin trial as soon as m122.
We also heard interest from other parties during Screen Capture CG 
meetings.


On Wednesday, January 17, 2024 at 2:47:43 PM UTC+1 Elad Alon wrote:


Contact emails

elad...@chromium.org


Explainer

https://github.com/screen-share/captured-surface-control/blob/main/README.md


Specification

TBD, but will be hosted on
https://screen-share.github.io/captured-surface-control once
produced.
For the time being, please refer to the explainer

<https://github.com/screen-share/captured-surface-control/blob/main/README.md>,
which has a detailed description of the API as well as sample use
of it.
A demo <https://captured-surface-control.glitch.me/> is also
available. (Some of the functionality is still being landed in
Chromium atm.)


Design docs


https://docs.google.com/document/d/10UojDvTJ6ojBEOP7cgBIIaE7WZEfes_Qv1eN3A2A0nM/edit?usp=sharing


Summary

Web API that allows Web applications to: 1. Produce wheel events
in a captured tab or window. 2. Read/write the zoom level of a
captured tab.



Blink component

Blink>GetDisplayMedia

<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EGetDisplayMedia>


TAG review

Not started.


TAG review status

Pending. We expect that developer feedback during the origin
trial might lead to non-trivial changes to the API shape, and
would therefore like to hold off on TAG review until after those
changes.


Risks



Interoperability and Compatibility



/Gecko/: No signal

/WebKit/: No signal

/Web developers/: No signals

/Other signals/:


Security


https://github.com/screen-share/captured-surface-control?tab=readme-ov-file#security-and-privacy-concerns



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?



Goals for experimentation

Validate the API shape with Web developers and gather feedback on
such topics as:

  * Usefulness of the API as currently implemented.
  * Usefulness of allowing the API to be invoked while the
capturing page is not focused (currently, the capturing page
must be focused).
  * Possible pain points with scrolling as currently specified
and implemented. (Is more fine-grained control necessary? Is
scrolling too janky as currently specified and implemented?)


Ongoing technical constraints

None


Debuggability

N/A


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

No (Supported on all desktop platforms. Screen-sharing is not
currently supported on mobile platforms.)


Is this feature fully tested by web-platform-tests

<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?

No (but we're working on it)


Flag name on chrome://flags

captured-surface-control


Finch feature name

CapturedDisplaySurface


Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1466247


Launch bug

https://launch.corp.google.com/launch/4268170


Estimated milestones

OriginTrial desktop last127
OriginTrial desktop first   122
DevTrial on desktop 122



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5092615678066688


Links to previous Intent discussions

Intent to prototype:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMO6jDPSgR3kX39drHd9t-JvTKBk%2B7Dg03O6dvowzw-LjQ__1A%40mail.gmail.com

This intent message was generated by Chrome Platform Status
<https://chromestatus.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/f6f5c1b3-d203-4fa5-bdef-394e4c04ab02n%40chromium.org 
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f6f5c1b3-d203-4fa5-bdef-394e4c04ab02n%40chro

Re: [blink-dev] Re: Intent to Experiment: Captured Surface Control

[Mike Taylor]

LGTM to experiment from M122 to M127 inclusive.

On 1/17/24 9:09 AM, 'Elad Alon' via blink-dev wrote:
A quick clarification, btw, that we have a partner in mind that's 
eager to start origin trial as soon as m122.
We also heard interest from other parties during Screen Capture CG 
meetings.


On Wednesday, January 17, 2024 at 2:47:43 PM UTC+1 Elad Alon wrote:


Contact emails

elad...@chromium.org


Explainer

https://github.com/screen-share/captured-surface-control/blob/main/README.md


Specification

TBD, but will be hosted on
https://screen-share.github.io/captured-surface-control once
produced.
For the time being, please refer to the explainer

,
which has a detailed description of the API as well as sample use
of it.
A demo  is also
available. (Some of the functionality is still being landed in
Chromium atm.)


Design docs


https://docs.google.com/document/d/10UojDvTJ6ojBEOP7cgBIIaE7WZEfes_Qv1eN3A2A0nM/edit?usp=sharing


Summary

Web API that allows Web applications to: 1. Produce wheel events
in a captured tab or window. 2. Read/write the zoom level of a
captured tab.



Blink component

Blink>GetDisplayMedia




TAG review

Not started.


TAG review status

Pending. We expect that developer feedback during the origin trial
might lead to non-trivial changes to the API shape, and would
therefore like to hold off on TAG review until after those changes.


Risks



Interoperability and Compatibility



/Gecko/: No signal

/WebKit/: No signal

/Web developers/: No signals

/Other signals/:


Security


https://github.com/screen-share/captured-surface-control?tab=readme-ov-file#security-and-privacy-concerns



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?



Goals for experimentation

Validate the API shape with Web developers and gather feedback on
such topics as:

  * Usefulness of the API as currently implemented.
  * Usefulness of allowing the API to be invoked while the
capturing page is not focused (currently, the capturing page
must be focused).
  * Possible pain points with scrolling as currently specified and
implemented. (Is more fine-grained control necessary? Is
scrolling too janky as currently specified and implemented?)


Ongoing technical constraints

None


Debuggability

N/A


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

No (Supported on all desktop platforms. Screen-sharing is not
currently supported on mobile platforms.)


Is this feature fully tested by web-platform-tests

?

No (but we're working on it)


Flag name on chrome://flags

captured-surface-control


Finch feature name

CapturedDisplaySurface


Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1466247


Launch bug

https://launch.corp.google.com/launch/4268170


Estimated milestones

OriginTrial desktop last127
OriginTrial desktop first   122
DevTrial on desktop 122



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5092615678066688


Links to previous Intent discussions

Intent to prototype:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMO6jDPSgR3kX39drHd9t-JvTKBk%2B7Dg03O6dvowzw-LjQ__1A%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/f6f5c1b3-d203-4fa5-bdef-394e4c04ab02n%40chromium.org 
.


--
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 i

Re: [blink-dev] Intent to Ship: WebGPU: separate Read-only depth-stencil

[Mike Taylor]

LGTM2

On 1/17/24 7:45 PM, Chris Harrelson wrote:
LGTM1 (as noted in the other intent, tests are needed but we aren't 
blocking approval on them in this case)


On Wed, Jan 10, 2024 at 11:02 AM Corentin Wallez 
 wrote:


Hey Rick,

The spec PRs for all of these intents are landed but you're
correct that all the tests are. Tests aren't blocked, they just
need someone to get to it (myself for this particular feature) and
we won't turn the feature on until they are finished. I didn't
realize that LGTMs waited on tests to be finished. We have a
pretty strong focus on testing in WebGPU and will definitely not
let a feature get enabled without tests being completed so
hopefully it's ok to LGTM without them? We totally expect some of
these recent I2S to slip to M123 because tests are still needed,
we just don't know which ones yet.

Cheers,

Corentin

On Wed, Jan 10, 2024 at 4:00 PM Rick Byers 
wrote:

Hi Corentin,
This looks minor and probably pretty easy. But we do normally
like to see spec PRs and tests land (or have a discussion
around why they're blocked) before approving. Thoughts?

Rick

On Fri, Jan 5, 2024 at 8:18 AM Corentin Wallez
 wrote:


Contact emails

cwal...@google.com


Explainer

None


Specification

https://github.com/gpuweb/gpuweb/pull/4331


Summary

Functionality added to the WebGPU/WGSL spec after its
first shipment in a browser. Loosens a restriction where
using readonly depth-stencil attachments in a render pass
required both aspects (depth and stencil) to be readonly.
This was too strict, and prevent use-cases where for
example the depth is used readonly for contact shadow
tracing, while the stencil buffer is written to do
identify pixels for further processing. (Both Unity and
Unreal do things with mixed depth-stencil readonliness).



Blink component

Blink>WebGPU




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

Separate RODS has not yet been implemented in any browser,
but has been approved by the GPU for the Web Community
Group, with representatives from Chrome, Firefox, and Safari.



/Gecko/: No signal
(https://github.com/mozilla/standards-positions/issues/953)

/WebKit/: Positive

(https://github.com/WebKit/standards-positions/issues/294#issuecomment-1877411933)
Note that this is a blanket approval from Safari for
additions to the v1 WebGPU/WGSL spec.

/Web developers/: Positive Requested by multiple
developers including for ports of the Unity and Unreal
engines to WebGPU.

/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 at the moment, WebGPU currently does not ship on
Android WebView.



Debuggability

None



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

No

All platforms will eventually have support. Will
immediately be available on Android, ChromeOS, Mac, and
Windows, since those platforms already support WebGPU.
Linux is planned to have WebGPU support in the future, so
this feature will become available when WebGPU does.



Is this feature fully tested by web-platform-tests

?

Yes

WebGPU/WGSL have a conformance test suite
(https://github.com/gpuweb/cts) that is regularly pulled
into Chromium and part of the testing of Dawn/Tint in
Chromium. Note that tests are still being written, but the
feature will not be launched until it is fully tested.



Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

https://bu

Re: [blink-dev] Intent to Ship: WGSL: pointer composite access

[Mike Taylor]

LGTM2

On 1/17/24 7:46 PM, Chris Harrelson wrote:
LGTM1 (as noted in the other intent, tests are needed but we aren't 
blocking approval on them in this case)


On Fri, Jan 5, 2024 at 5:17 AM 'Corentin Wallez' via blink-dev 
 wrote:



Contact emails

cwal...@google.com


Explainer

None


Specification

https://gpuweb.github.io/gpuweb/wgsl/#:~:text=pointer_composite_access


Summary

Functionality added to the WebGPU/WGSL spec after its first
shipment in a browser. Provides better ergonomics for accessing
member of a composite through a pointer. For example `(*ptr).i`
can now be written `ptr.i`.



Blink component

Blink>WebGPU




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

Pointer composite access has not yet been implemented in any
browser, but has been approved by the GPU for the Web Community
Group, with representatives from Chrome, Firefox, and Safari.



/Gecko/: No signal
(https://github.com/mozilla/standards-positions/issues/950)

/WebKit/: Positive

(https://github.com/WebKit/standards-positions/issues/294#issuecomment-1877411933)
Note that this is a blanket approval from Safari for addition to
the v1 WebGPU/WGSL spec.

/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 at the moment, WebGPU currently does not ship on Android WebView.



Debuggability

None



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

No

All platforms will eventually have support. Will immediately be
available on Android, ChromeOS, Mac, and Windows, since those
platforms already support WebGPU. Linux is planned to have WebGPU
support in the future, so this feature will become available when
WebGPU does.



Is this feature fully tested by web-platform-tests

?

Yes

WebGPU/WGSL have a conformance test suite
(https://github.com/gpuweb/cts) that is regularly pulled into
Chromium and part of the testing of Dawn/Tint in Chromium. Note
that tests are still being written, but the feature will not be
launched until it is fully tested.



Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/tint/issues/detail?id=2110


Availability expectation

Feature is available only in Chromium browsers for the near
future, on the order of months. Other browsers intend to ship
WebGPU support, but don't have specified timelines.


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?

No


Estimated milestones

No milestones specified



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/5133060700110848

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/CAGdfWNPSGBSAVQ0p7Bua4G4dO%3DJ7VOdZ452aAjL5_HzX1be%2B-Q%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.

Re: [blink-dev] Intent to Ship: WebGPU: render to slice of 3D texture

[Mike Taylor]

LGTM2

On 1/17/24 7:50 PM, Chris Harrelson wrote:
LGTM1 (as noted in the other intent, tests are needed but we aren't 
blocking approval on them in this case)



On Fri, Jan 5, 2024 at 5:18 AM Corentin Wallez  
wrote:



Contact emails

cwal...@google.com


Explainer

None


Specification

https://gpuweb.github.io/gpuweb/#dom-gpurenderpasscolorattachment-depthslice


Summary

Functionality added to the WebGPU/WGSL spec after its first
shipment in a browser. Adds support using a render pass to render
to slices of 3D textures in addition to rendering to 2D textures.
This is used in graphical algorithm to do voxelization between others.



Blink component

Blink>WebGPU




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

Read-write storage textures have not yet been implemented in any
browser, but have been approved by the GPU for the Web Community
Group, with representatives from Chrome, Firefox, and Safari.



/Gecko/: No signal
(https://github.com/mozilla/standards-positions/issues/952)

/WebKit/: Positive

(https://github.com/WebKit/standards-positions/issues/294#issuecomment-1877411933)
Note that this is a blanket approval from Safari for additions to
the v1 WebGPU/WGSL spec.

/Web developers/: Positive This feature has been requested by
developers multiple times.

/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 at the moment, WebGPU currently does not ship on Android WebView.



Debuggability

None



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

No

All platforms will eventually have support. Will immediately be
available on Android, ChromeOS, Mac, and Windows, since those
platforms already support WebGPU. Linux is planned to have WebGPU
support in the future, so this feature will become available when
WebGPU does.



Is this feature fully tested by web-platform-tests

?

Yes

WebGPU/WGSL have a conformance test suite
(https://github.com/gpuweb/cts) that is regularly pulled into
Chromium and part of the testing of Dawn/Tint in Chromium. Note
that tests are still being written, but the feature will not be
launched until it is fully tested.



Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/dawn/issues/detail?id=1020


Availability expectation

Feature is available only in Chromium browsers for the near
future, on the order of months. Other browsers intend to ship
WebGPU support, but don't have specified timelines.


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?

No


Estimated milestones

No milestones specified



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/5196871364771840

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/CAGdfWNOcdCrMEuv3atOcbRw8K_xywF%2BVo-8q-hn1Y87bHk91iw%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 
a

Re: [blink-dev] Intent to Ship: WebGPU: read-write storage textures

[Mike Taylor]

LGTM2

On 1/17/24 7:49 PM, Chris Harrelson wrote:
LGTM1 (as noted in the other intent, tests are needed but we aren't 
blocking approval on them in this case)



On Mon, Jan 8, 2024 at 2:04 AM 'François Beaufort' via blink-dev 
 wrote:




On Mon, Jan 8, 2024 at 11:01 AM Yoav Weiss
 wrote:



On Fri, Jan 5, 2024, 14:19 Corentin Wallez
 wrote:


Contact emails

cwal...@google.com


Explainer

None


Specification


https://gpuweb.github.io/gpuweb/#dom-gpustoragetextureaccess-read-write


Is there a way for developers to feature detect support for
this extra value?


Yes. All they have to do is check wgslLanguageFeatures
 as below.

if

(navigator.gpu.wgslLanguageFeatures.has("readonly_and_readwrite_storage_textures"))
{
  // Read-only and read-write storage textures are supported!
}


Summary

Functionality added to the WebGPU/WGSL spec after its
first shipment in a browser. Adds support for (read-only
and) read-write storage textures which allow more general
access to texture memory for GPU computation and can
unlock more advanced graphical algorithms. This feature
has been request by developers very often.



Blink component

Blink>WebGPU




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

Read-write storage textures have not yet been implemented
in any browser, but have been approved by the GPU for the
Web Community Group, with representatives from Chrome,
Firefox, and Safari.



/Gecko/: No signal
(https://github.com/mozilla/standards-positions/issues/948)

/WebKit/: Positive

(https://github.com/WebKit/standards-positions/issues/294#issuecomment-1877411933)
Note that this is a blanket approval from Safari for
additions to the v1 WebGPU/WGSL spec.

/Web developers/: Strongly positive One of the most
requested additional features for WebGPU.

/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 at the moment, WebGPU currently does not ship on
Android WebView.



Debuggability

None



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

No

All platforms will eventually have support. Will
immediately be available on Android, ChromeOS, Mac, and
Windows, since those platforms already support WebGPU.
Linux is planned to have WebGPU support in the future, so
this feature will become available when WebGPU does.



Is this feature fully tested by web-platform-tests

?

Yes

WebGPU/WGSL have a conformance test suite
(https://github.com/gpuweb/cts) that is regularly pulled
into Chromium and part of the testing of Dawn/Tint in
Chromium. Note that tests are still being written, but the
feature will not be launched until it is fully tested.



Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/dawn/issues/detail?id=1972


Availability expectation

Feature is available only in Chromium browsers for the
near future, on the order of months. Other browsers intend
to ship WebGPU support, but don't have specified timelines.


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?

No


Estimated milestones

No milestones specified



Anticipated spec changes

Open questions about a f

Re: [blink-dev] Re: Intent to Ship: WGSL: packed 4x8 integer dot product (DP4)

[Mike Taylor]

LGTM3

On 1/17/24 7:49 PM, Chris Harrelson wrote:
LGTM2 (as noted in the other intent, tests are needed but we aren't 
blocking approval on them in this case)



On Wed, Jan 10, 2024 at 7:39 AM Yoav Weiss  wrote:

Oops! For this intent as well, can you tick the other review boxes
in chromestatus?

On Wednesday, January 10, 2024 at 4:37:48 PM UTC+1 Yoav Weiss wrote:

LGTM1 (once tests land)

On Friday, January 5, 2024 at 2:16:52 PM UTC+1 Corentin Wallez
wrote:


Contact emails

cwal...@google.com


Explainer

None


Specification


https://gpuweb.github.io/gpuweb/wgsl/#:~:text=packed_4x8_integer_dot_product


Summary

Functionality added to the WebGPU/WGSL spec after its
first shipment in a browser. Adds support new WGSL
builtins to work with 4 8-bit numbers packed in a u32. The
new dot product functionality is especially useful for
executing machine learning models that work on 8-bit weights.



Blink component

Blink>WebGPU




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

DP4 WGSL builtins have not yet been implemented in any
browser, but have been approved by the GPU for the Web
Community Group, with representatives from Chrome,
Firefox, and Safari.



/Gecko/: No signal
(https://github.com/mozilla/standards-positions/issues/949)

/WebKit/: Positive

(https://github.com/WebKit/standards-positions/issues/294#issuecomment-1877411933)
Note that this is a blanket approval from Safari for
addition to the v1 WebGPU/WGSL spec.

/Web developers/: Positive Multiple ML frameworks are
looking to use this (ONNX runtime, TF.js, etc)

/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 at the moment, WebGPU currently does not ship on
Android WebView.



Debuggability

None



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

No

All platforms will eventually have support. Will
immediately be available on Android, ChromeOS, Mac, and
Windows, since those platforms already support WebGPU.
Linux is planned to have WebGPU support in the future, so
this feature will become available when WebGPU does.



Is this feature fully tested by web-platform-tests

?

Yes

WebGPU/WGSL have a conformance test suite
(https://github.com/gpuweb/cts) that is regularly pulled
into Chromium and part of the testing of Dawn/Tint in
Chromium. Note that tests are still being written, but the
feature will not be launched until it is fully tested.



Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/tint/issues/detail?id=1497


Availability expectation

Feature is available only in Chromium browsers for the
near future, on the order of months. Other browsers intend
to ship WebGPU support, but don't have specified timelines.


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?

No


Estimated milestones

No milestones specified



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 

Re: [blink-dev] Re: Intent to Ship: WGSL: unrestricted pointer parameters

[Mike Taylor]

LGTM3

On 1/17/24 3:40 PM, Yoav Weiss wrote:

LGTM2

On Wed, Jan 17, 2024 at 9:04 PM Corentin Wallez  
wrote:


Thanks a lot!

On Wed, Jan 17, 2024 at 8:11 PM Chris Harrelson
 wrote:

Got it, thanks for clarifying and the quick response!

The API owners reviewed today and we're comfortable with not
blocking our LGTMs on landing the tests, since your team is
committed to adding them before shipping.

On Wed, Jan 17, 2024 at 8:53 AM Corentin Wallez
 wrote:

Thanks! Tests for other intents are still WIP, though it'd
be nice to get the LGTMs so we don't need to come back
once they are :) We require tests to be complete (and
passing!) in our own process before shipping anyway.

On Wed, Jan 17, 2024 at 5:49 PM Chris Harrelson
 wrote:

Great - LGTM1!

Does your comment about tests also apply to the other
intents?

On Wed, Jan 17, 2024 at 8:46 AM Corentin Wallez
 wrote:

API owners, PTAL: the tests have been implemented,
and all review boxes are green!

On Friday, January 5, 2024 at 2:17:56 PM UTC+1
Corentin Wallez wrote:


Contact emails

cwal...@google.com


Explainer

None


Specification


https://gpuweb.github.io/gpuweb/wgsl/#:~:text=unrestricted_pointer_parameters


Summary

Functionality added to the WebGPU/WGSL spec
after its first shipment in a browser. Loosens
restrictions on which pointers can be passed
to WGSL functions such that pointers to
storage/uniform/workgroup address spaces are
allowed.



Blink component

Blink>WebGPU




Search tags

webgpu



TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

Unrestricted pointer access has not yet been
implemented in any browser, but has been
approved by the GPU for the Web Community
Group, with representatives from Chrome,
Firefox, and Safari.



/Gecko/: No signal

(https://github.com/mozilla/standards-positions/issues/951)

/WebKit/: Positive

(https://github.com/WebKit/standards-positions/issues/294#issuecomment-1877411933)
Note that this is a blanket approval from
Safari for addition to the v1 WebGPU/WGSL spec.

/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 at the moment, WebGPU currently does not
ship on Android WebView.



Debuggability

None



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

No

All platforms will eventually have support.
Will immediately be available on Android,
ChromeOS, Mac, and Windows, since those
platforms already support WebGPU. Linux is
planned to have WebGPU support in the future,
so this feature will become available when
WebGPU does.



Is this feature fully tested by
web-platform-tests

?

Yes

W