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

,
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 

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

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

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 

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 
an 

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 

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] Intent to Ship: WebGPU: render to slice of 3D texture

[Chris Harrelson]

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 emailscwal...@google.com
>
> ExplainerNone
>
> 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 componentBlink>WebGPU
> 
>
> TAG reviewNone
>
> TAG review statusNot 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://flagsNone
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/dawn/issues/detail?id=1020
>
> Availability expectationFeature 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 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%2Bw_3WD5d%3Dy%3Dw8EtBLNj%2BvSg0AysH0q7vRmiL%2BQTFeg5-Yg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: WebGPU: read-write storage textures

[Chris Harrelson]

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 <
blink-dev@chromium.org> wrote:

>
>
> On Mon, Jan 8, 2024 at 11:01 AM Yoav Weiss  wrote:
>
>>
>>
>> On Fri, Jan 5, 2024, 14:19 Corentin Wallez  wrote:
>>
>>> Contact emailscwal...@google.com
>>>
>>> ExplainerNone
>>>
>>> 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 componentBlink>WebGPU
>>> 
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot 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://flagsNone
>>>
>>> Finch feature nameNone
>>>
>>> Non-finch justificationNone
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://bugs.chromium.org/p/dawn/issues/detail?id=1972
>>>
>>> Availability expectationFeature 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/6469283075063808
>>>
>>> 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
>>> 

Re: [blink-dev] Re: Intent to Ship: WGSL: packed 4x8 integer dot product (DP4)

[Chris Harrelson]

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 emailscwal...@google.com
>>>
>>> ExplainerNone
>>>
>>> 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 componentBlink>WebGPU
>>> 
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot 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://flagsNone
>>>
>>> Finch feature nameNone
>>>
>>> Non-finch justificationNone
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://bugs.chromium.org/p/tint/issues/detail?id=1497
>>>
>>> Availability expectationFeature 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/6457584892772352
>>>
>>> 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/218fe6d2-b667-4210-8320-17b28693eeb0n%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 

Re: [blink-dev] Re: Intent to Experiment: Captured Surface Control

[Chris Harrelson]

LGTM to experiment M122 - M127

On Wed, Jan 17, 2024 at 6:09 AM 'Elad Alon' via blink-dev <
blink-dev@chromium.org> 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 emailselad...@chromium.org
>>
>> Explainer
>> https://github.com/screen-share/captured-surface-control/blob/main/README.md
>>
>> SpecificationTBD, 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 componentBlink>GetDisplayMedia
>> 
>>
>> TAG reviewNot started.
>>
>> TAG review statusPending. 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://flagscaptured-surface-control
>>
>> Finch feature nameCapturedDisplaySurface
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1466247
>>
>> Launch bughttps://launch.corp.google.com/launch/4268170
>>
>> Estimated milestones
>> OriginTrial desktop last 127
>> 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 discussionsIntent 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 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%2Bw-s%3D0xPioUtSK%2B5bGai1wULaw%3D%2BVe30Ecx0785MtOaVoQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: WGSL: pointer composite access

[Chris Harrelson]

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 <
blink-dev@chromium.org> wrote:

> Contact emailscwal...@google.com
>
> ExplainerNone
>
> 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 componentBlink>WebGPU
> 
>
> TAG reviewNone
>
> TAG review statusNot 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://flagsNone
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/tint/issues/detail?id=2110
>
> Availability expectationFeature 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.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9H1_e1pMqjs5u4jdocw_XYUqwd%2BEn%3DNSbw8VLmcwxBtg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: WebGPU: separate Read-only depth-stencil

[Chris Harrelson]

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 emailscwal...@google.com
>>>
>>> ExplainerNone
>>>
>>> Specificationhttps://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 componentBlink>WebGPU
>>> 
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot 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://flagsNone
>>>
>>> Finch feature nameNone
>>>
>>> Non-finch justificationNone
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://bugs.chromium.org/p/dawn/issues/detail?id=2146
>>>
>>> Availability expectationFeature 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 

Re: [blink-dev] Re: Intent to Prototype: document.caretPositionFromPoint API

['Siye Liu' via blink-dev]

Blink has similar concept called "affinity" when placing caret at wrapped 
line. 
definition: 
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/editing/visible_position.h;l=39-54

Thanks,
Siye

On Wednesday, January 17, 2024 at 6:35:14 AM UTC-8 Daniel Bratell wrote:

> This is not directly related to this one function but more to the whole 
> API. I quickly skimmed the spec and I could not find out how it handles 
> line breaks which make caret positions ambigious?
>
> When you press the END key at one line, and the HOME key at the following 
> line your caret DOM position can be the same, but the visual caret 
> positions should be different, and so should certain actions like 
> arrow-down and arrow-up.
>
> When developing code to handle this in Opera, I solved it by letting 
> carets know if they were connected forward or backwards (basically a bool) 
> in the dom element, but maybe this is solved in some other way now?
>
> /Daniel
> On 2024-01-16 18:31, 'Siye Liu' via blink-dev wrote:
>
> Hi Brian, 
>
> To answer your question,
> 1. This prototype only covers the main dom scenario (
> https://crbug.com/388976). Shadow dom scenario is tracked in 
> https://crbug.com/1514810.
> 2. The prototype should have similar behavior as caretRangeFromPoint's 
> implementation in Blink (when the point is over an input element, the 
> returned CaretPosition should be the nearest ancestor of the input element) 
> because I expect both APIs share same hit testing logic under the hood.
>
> Once the prototype is ready for dev trial, we can discuss further about 
> improving current implementation in both caretRangeFromPoint and 
> caretPositionFromPoint in Blink.
>
>
> Thanks,
> Siye
>
> On Friday, January 12, 2024 at 5:23:25 PM UTC-8 Brian Birtles wrote:
>
> Hi,
>
> Will this also cover the behavioral differences between 
> caretPositionFromPoint as implemented in Gecko and caretRangeFromPoint as 
> implemented in Blink such as:
>
> 1. caretPositionFromPoint in Gecko digs into shadow DOM elements whereas 
> caretRangeFromPoint in Blink does not.
> 2. When the point is over a text input element, caretPositionFromPoint in 
> Gecko returns the text input element and offset into it but 
> caretRangeFromPoint in Blink returns the nearest ancestor of the text input 
> element. (Note that caretRangeFromPoint in Webkit returns the text input 
> element but always returns a zero offset into it.)
>
> Thanks,
>
> Brian
>
> 2024年1月13日土曜日 3:35:59 UTC+9 si...@microsoft.com:
>
> Contact emails 
> si...@microsoft.com, sa...@microsoft.com
>
> Explainer
> None
>
> Specification
> https://www.w3.org/TR/cssom-view-1/#dom-document-caretpositionfrompoint
>
> Summary 
>
> This new API allows users to get current caret position from a given 
> screen point. The API returns a CaretPosition object which represents the 
> caret position indicating current text insertion point including the 
> containing DOM node, caret's character offset, and the client rectangle of 
> caret range. 
>
>
> Blink component
> Blink>CSS 
> 
>
> Motivation 
>
> document.caretPositionFromPoint API is in CSSOM View and is already 
> implemented by Gecko. WebKit/Blink has similar document.caretRangeFromPoint 
> API which returns a text range indicating the text insertion point. The 
> existing API was in CSSOM View at the time it was implemented: 
> https://bugs.webkit.org/show_bug.cgi?id=27046 
> http://web.archive.org/web/20090708002518/http://dev.w3.org/csswg/cssom-view/#the-documentview-interface
>  
> The existing API was replaced by the new API later: 
> https://hg.csswg.org/drafts/rev/4c7b6f843171. The switch happened around 
> 2009 and we don't have the historical context about the decision. Given how 
> long it has been since the spec was updated, we believe it's best that 
> Blink complies with the spec so that future innovations with the API can be 
> spec compliant and have lower interop/compat risk.
>
>
> Initial public proposal
> None
>
> TAG review
> None
>
> TAG review status
> Not applicable
>
> Risks 
>
>
> Interoperability and Compatibility 
>
> Gecko already implemented the API. Webkit/Blink didn't implement it. The 
> interop risk is that it's unclear at this moment about Webkit's position on 
> this. We won't be able to achieve full interop with this API if Webkit 
> isn't willing to support this API. There is a compat risk too if we decided 
> to deprecate the old API: https://crbug.com/690599
>
>
> *Gecko*: Shipped/Shipping
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/301)
>
> *Web developers*: Positive (
> https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c34) Web 
> developers are asking to have document.caretPositionFromPoint API 
> implemented in Blink: 
> https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c28 
> 

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

Re: [blink-dev] Re: Intent to Ship: WGSL: unrestricted pointer parameters

[Yoav Weiss]

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 emailscwal...@google.com
>>
>> ExplainerNone
>>
>> 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 componentBlink>WebGPU
>> 
>>
>> Search tagswebgpu 
>>
>> TAG reviewNone
>>
>> TAG review statusNot 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
>>
>> 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://flagsNone
>>
>> Finch feature nameNone
>>
>> Non-finch justificationNone
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/tint/issues/detail?id=2053
>>
>> Availability expectationFeature 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 

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

[Ari Chivukula]

Two additional explainers (each of which is an extension to Storage Access
API (SAA) to non-cookie storage
) have been published!
Both of these are slated for inclusion in the existing origin trial
(hopefully as part of M123).

Explainer: Extending Storage Access API (SAA) to omit unpartitioned cookies

The current Storage Access API requires that unpartitioned cookie access is
granted if any unpartitioned storage access is needed. This forces
unpartitioned cookies to be included in network requests which may not need
them, having impacts on network performance and security. Before the
extension ships, we have a chance to fix this behavior without a
compatibility break.

Explainer: Extending Storage Access API (SAA) to Shared Workers

There has been increasing developer and implementer interest in first-party
workers being available in third-party contexts the same way that
third-party cookies already can be. In the absence of such a solution, we
leave developers without a robust way to manage cross-tab state for frames
loading the same origin. This explainer proposes a solution for developers
to regain third-party access to Shared Workers in select instances to avoid
user-facing breakage in browsers shipping storage partitioning.

~ Ari Chivukula (Their/There/They're)


On Tue, Jan 9, 2024 at 3:03 PM Ari Chivukula  wrote:

> Based on a report from an external developer
> 
>  a
> bug was found that caused the session/local storage on the SAA handle to
> sometimes be partitioned (instead of unpartitioned). The fix
>  will
> be included in M122.
>
> Please report any further issues to
> https://github.com/arichiv/saa-non-cookie-storage/issues, thanks!
>
> ~ Ari Chivukula (Their/There/They're)
>
>
> On Mon, Dec 4, 2023 at 9:54 AM Ari Chivukula  wrote:
>
>> A blog post on how to participate in the OT is here:
>> https://developer.chrome.com/blog/saa-non-cookie-storage/
>>
>> Chrome 120 includes local storage, session storage, indexed db, and web
>> locks.
>>
>> Chrome 121 adds cache storage, origin private filesystem, quota, blob
>> storage, and broadcast channel.
>>
>> Shared Workers will be re-examined in a future extension, I hope to
>> publish more on this within a month.
>>
>> ~ Ari Chivukula (Their/There/They're)
>>
>>
>> On Thu, Oct 26, 2023 at 11:21 AM Ari Chivukula 
>> wrote:
>>
>>> Contact emails
>>>
>>> aric...@chromium.org, wanderv...@chromium.org, johann...@chromium.org,
>>> hele...@google.com
>>>
>>>
>>> Specification
>>>
>>> https://arichiv.github.io/saa-non-cookie-storage/
>>>
>>>
>>> Feedback
>>>
>>> https://github.com/arichiv/saa-non-cookie-storage/issues
>>>
>>>
>>> Intent to Prototype
>>>
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/inRN8tI49O0
>>>
>>>
>>> Summary
>>>
>>> An origin trial
>>> ,
>>> StorageAccessAPIBeyondCookies, will be made available which enables the
>>> proposed extension of the Storage Access API
>>> 
>>> (backwards compatible) to allow access to unpartitioned (cookie and
>>> non-cookie) storage in a third-party context. The current API only provides
>>> access to cookies, which have different use-cases than non-cookie storage
>>> (discussed more in the Motivation section). The API can be used as follows
>>> (JS running in an embedded iframe):
>>>
>>>
>>> // Request a new storage handle via rSA (this should prompt the user)
>>>
>>> let handle = await document.requestStorageAccess({all: true});
>>>
>>> // Write some 1P context sessionstorage
>>>
>>> handle.sessionStorage.setItem("userid", "1234");
>>>
>>> // Write some 1P context localstorage
>>>
>>> handle.localStorage.setItem("preference", "A");
>>>
>>> // Open or create an indexedDB that is shared with the 1P context
>>>
>>> let messageDB = handle.indexedDB.open("messages");
>>>
>>> // Use locks shared with the 1P context
>>>
>>> await handle.locks.request(“example”, …);
>>>
>>>
>>> The same flow would be used by iframes to get a storage handle when
>>> their top-level ancestor successfully called rSAFor
>>> , just that in
>>> this case the storage-access permission was already granted and thus the
>>> rSA call would not require a user gesture or show a prompt, allowing for
>>> “hidden” iframes accessing storage.
>>>
>>>
>>> Beyond calling this additional extension, access to non-cookie storage
>>> would match the current requirements for cookie access through the Storage
>>> Access API. For example, in Chrome, no prompt is shown when the origins are
>>> in the same RWS (Related 

Re: [blink-dev] PSA: Extending Storage Access API (SAA) to non-cookie storage Explainer

[Ari Chivukula]

Two additional explainers (each of which is an extension to Storage Access
API (SAA) to non-cookie storage
) have been published!

Explainer: Extending Storage Access API (SAA) to omit unpartitioned cookies

The current Storage Access API requires that unpartitioned cookie access is
granted if any unpartitioned storage access is needed. This forces
unpartitioned cookies to be included in network requests which may not need
them, having impacts on network performance and security. Before the
extension ships, we have a chance to fix this behavior without a
compatibility break.

Explainer: Extending Storage Access API (SAA) to Shared Workers

There has been increasing developer and implementer interest in first-party
workers being available in third-party contexts the same way that
third-party cookies already can be. In the absence of such a solution, we
leave developers without a robust way to manage cross-tab state for frames
loading the same origin. This explainer proposes a solution for developers
to regain third-party access to Shared Workers in select instances to avoid
user-facing breakage in browsers shipping storage partitioning.


On Fri, Sep 8, 2023 at 9:52 AM Ari Chivukula  wrote:

> *Contact Emails*
> aric...@chromium.org, hele...@google.com, johann...@chromium.org,
> wanderv...@chromium.org
>
> *Explainer*
> https://arichiv.github.io/saa-non-cookie-storage/
>
> *Summary*
> To prevent certain types of cross-site tracking, storage and communication
> APIs in third party contexts are being partitioned or deprecated (read more
> about storage partitioning
> 
> and cookie deprecation efforts
> 
> in Chrome and Firefox
> ).
> This breaks use cases that depend on cookie and non-cookie storage and
> communication surfaces in cross-site contexts. Several solutions (like
> Chrome’s Privacy Sandbox
> ) have been
> proposed to address use cases that rely on third-party cookies, including
> the Storage Access API 
> (shipping with multi-browser support), which facilitates limited access to
> third-party cookies in specific scenarios to mitigate user-facing breakage.
> This explainer proposes to extend that same mechanism to non-cookie
> storage/communication mediums.
>
>

-- 
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/CAGpy5DLtd5NbPE11DZDO2%2BM96Ze08AUhAx%3DB5ezStZqoJbxqMA%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: WGSL: unrestricted pointer parameters

[Corentin Wallez]

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 emailscwal...@google.com
>
> ExplainerNone
>
> 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 componentBlink>WebGPU
> 
>
> Search tagswebgpu 
>
> TAG reviewNone
>
> TAG review statusNot 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
>
> 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://flagsNone
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/tint/issues/detail?id=2053
>
> Availability expectationFeature 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/5181311436455936
>
> This intent 

Re: [blink-dev] Re: Intent to Ship: WGSL: unrestricted pointer parameters

[Chris Harrelson]

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 emailscwal...@google.com

 ExplainerNone

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

 Search tagswebgpu 

 TAG reviewNone

 TAG review statusNot 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

 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://flagsNone

 Finch feature nameNone

 Non-finch justificationNone

 Requires code in //chrome?False

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

 Availability expectationFeature 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/5181311436455936

 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 

Re: [blink-dev] Intent to Experiment: Web app scope extensions

[Chris Harrelson]

Sounds good to me. LGTM!

On Wed, Jan 17, 2024 at 10:38 AM 'Lu Huang' via blink-dev <
blink-dev@chromium.org> wrote:

> New update (Jan 17th, 2024):
> We found and
> fixed a
> flag check bug in M121 Chrome Beta that prevented this feature from working
> correctly.
>
> With M121 being past the point of accepting merges, we would like to
> change the OT to run from M122-127 (instead of the previously approved
> M121-126) please.
> Any objections?
> On Thursday, October 26, 2023 at 5:37:55 PM UTC-7 Chris Harrelson wrote:
>
>> Yes, LGTM! Sorry for forgetting to email.
>>
>> On Thu, Oct 26, 2023 at 5:24 PM 'Lu Huang' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> We have a LGTM from Chris in the chromestatus page "API Owners" section
>>> (see attached screenshot). I think this means we are ok to proceed, but
>>> please let me know if I am mistaken and we need an explicit LGTM in this
>>> thread. Thanks!
>>>
>>> On Monday, October 16, 2023 at 11:09:07 AM UTC-7 Lu Huang wrote:
>>>
 In this case, I want to make sure there's enough time for app partners
 to enroll in January when M121 reaches Stable and for us to help them
 troubleshoot the configuration needed. This feature requires more
 server-side configuration ( of /.well-known/web-app-origin-association)
 that could take time to troubleshoot than other web app manifest features
 in the past.

 If things go well and we get the desired feedback in time, we could try
 to move forward from OT before the 6 months are up.

 On Monday, October 16, 2023 at 10:32:28 AM UTC-7 sligh...@chromium.org
 wrote:

> I'm supportive of this, but curious why 6 milestones. If there are
> partners signed up to provide feedback, can we summarize that input sooner
> than 6 months?
>
> Best,
>
> Alex
>
> On Mon, Oct 16, 2023 at 9:00 AM 'Lu Huang' via blink-dev <
> blin...@chromium.org> wrote:
>
>> Quick update:
>> We would like to push the start back to M121, and request that it run
>> for 6 milestones initially.
>> First milestone: 121.
>> Last milestone: 126.
>>
>> On Thursday, October 12, 2023 at 10:11:29 AM UTC-7
>> mike...@chromium.org wrote:
>>
>>> Jason, could you please work with Lu to figure out why he can't post
>>> comments in the chromestatus entry (but can request a review)?
>>>
>>> thanks.
>>> On 10/11/23 5:25 PM, 'Lu Huang' via blink-dev wrote:
>>>
>>> For the 3 review categories in chromestatus (security, privacy, and
>>> debuggability), I have clicked on request review but have not found a 
>>> way
>>> to post comments from the UI.
>>>
>>> For security and privacy, we have a self-review at:  
>>> manifest-incubations/scope_extensions-security-privacy-questionnaire.md
>>> at gh-pages · WICG/manifest-incubations (github.com)
>>> 
>>> For debuggability, here are the survey responses until I find out
>>> how to add to the comments at chromestatus:
>>>
>>> (1) Does the introduction of the new Web Platform feature break
>>> Chrome DevTools' existing developer experience? No. (2) Does Chrome
>>> DevTools' existing set of tooling features interact with the new Web
>>> Platform feature in an expected way?
>>> Yes. (3) Would the new Web Platform feature's acceptance and/or
>>> adoption benefit from adding a new developer workflow to Chrome 
>>> DevTools? Yes.
>>> If adopted, this new feature would benefit from new UI and tooling in 
>>> the
>>> Application Page of Chrome DevTools. DevTools support can help 
>>> developers
>>> determine if they have set up the web app association configuration
>>> correctly and if their specified scope_extensions are valid.
>>>
>>> On Wednesday, October 11, 2023 at 2:12:09 PM UTC-7 Lu Huang wrote:
>>>
 We would like to start running this experiment from 120 through 123
 inclusive, but may have to delay start to 121 running through 124.



 On Wednesday, October 11, 2023 at 7:54:51 AM UTC-7 Chris Harrelson
 wrote:

> Please also fill out the 3 other review categories (security,
> privacy, debuggability) in chromestatus.
>
>
> On Wed, Oct 11, 2023 at 7:13 AM Mike Taylor 
> wrote:
>
>> Hi there,
>>
>> Could you clarify which milestones you would like to run the
>> experiment on?
>>
>> thanks,
>> Mike
>> On 10/11/23 6:05 AM, 'Lu Huang' via blink-dev wrote:
>>
>> Contact emails
>> lu...@microsoft.com, luig...@microsoft.com, 

Re: [blink-dev] Intent to Ship: Long Animation Frame Timing

[Noam Rosenthal]

Gotcha thanks!
I totally missed those buttons... will file a UI bug on chromestatus, maybe
their discoverability can be improved.

On Wed, Jan 17, 2024 at 11:53 AM Manuel Rego Casasnovas 
wrote:

>
>
> On 15/01/2024 11:31, Noam Rosenthal wrote:
> >
> > Link to entry on the Chrome Platform Status
> >
> > https://chromestatus.com/feature/6118675067699200
> > 
> >
> >
> > Can you tick the other review boxes on the entry?
> >
> > Not sure I understand what boxes?
>
> Yoav refers to the buttons to request other reviews (apart from the API
> owners review that happens here).
>
> In "Prepare to ship" section you can find buttons for the following
> reviews:
> * Privacy
> * Security
> * Enterprise
> * Debuggability
> * Testing
>
> You should click those to request a review from the different parties.
>
> 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/CAJn%3DMYar5ouvmBMMgdsJT4MD_DZ_wGQ1TrYLPV1rXKdmZFLADA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Interoperable mousemove default action

[Mustaq Ahmed]

A quick update: our use-counter on Chrome 122 Canary/Dev came out higher
than we expected---it is suggesting that at most 0.11% page loads are
affected.

We will expand the finch trail to 50% Beta plus 1% Stable now to get more
data, and then look into other directions like adding UKM or fine tuning
the use-counter.


On Thu, Dec 7, 2023 at 10:14 AM Rick Byers  wrote:

>
>
> On Wed, Dec 6, 2023 at 5:08 PM Mustaq Ahmed  wrote:
>
>> > I assume cancelling the mousedown (but not the mousemove) still
>> prevents selection and drag-and-drop in all browsers, is that right? That's
>> the pattern I'd expect is most common. Also, what's the behavior of
>> pointermove for mice today and after this change?
>>
>> I just confirmed  that
>> Chrome (and Firefox and Safari too) already prevents both selection and
>> drag-and-drop when mousedown or pointerdown is cancelled.  So sites
>> canceling all the mouse events will work fine.
>>
>
> Great, thanks! That definitely lowers my concern.
>
> > We have landed a metric which specifically checks for cases where the
>> mousemove is preventDefaulted but a selection starts (i.e. selectstart
>> wasn't prevented, there was no user-select: none, and so the selection does
>> change). Right now this is a UMA but we could also add UKM and get sites
>> from this. Mustaq WDYT about adding UKM for this and running the 1%
>> finch trial?
>>
>> Adding UKM and running a 1% finch trial sounds good.
>>
>> Perhaps we can run a Canary/Dev/Beta trial even now (on M121)?
>>
>
> Yep, you can do whatever you want for canary/dev and you have API owner
> approval for Beta and Stable up to 1% if you want it. Perhaps beta data
> alone would be compelling enough for API owners to approve this (with an
> understanding, like always, that we'd kill-switch it on reports of
> non-trivial stable breakage).
>
> On Wed, Dec 6, 2023 at 12:34 PM Robert Flack  wrote:
>>
>>> On Wed, Dec 6, 2023 at 12:18 PM Rick Byers  wrote:
>>>
 API owners met and discussed this one briefly today. There was
 agreement that more work needs to be done to demonstrate the compat risk is
 low enough to ship this breaking change. A few points:

- If you'd like to do a finch trial to gather data (up to stable
1%) we're supportive of that.
- Mike Taylor argued that you're not likely to learn too much
useful from a finch trial since people seem not to report bugs for 
 things
that fail for a seemingly random 1% of their users, and perhaps the 
 idea of
surveying a few sites would be more effective at finding real breakage. 
 Of
course UKM + Finch might be a good way to find URLs to test.

 We have landed a metric which specifically checks for cases where the
>>> mousemove is preventDefaulted but a selection starts (i.e. selectstart
>>> wasn't prevented, there was no user-select: none, and so the selection does
>>> change). Right now this is a UMA but we could also add UKM and get sites
>>> from this. Mustaq WDYT about adding UKM for this and running the 1% finch
>>> trial?
>>>
>>
> Ah that makes sense. Sorry I only took a quick glance at the code for the
> UseCounter and missed that. That's indeed much more relevant than I was
> thinking, maybe it won't be so high after all and that can give us good
> confidence to ship?
>
>>
- Mike also argued that in his experience, he'd expect sites like
mapping apps to have engine-specific conditional code around their event
handling, so that increases the risk.
- Philip and I discussed that if there is evidence of real breakage
we can't accept, we should propose changing the spec here - it seems 
 like
it would be very reasonable if cancelling the first mousemove event in a
sequence canceled text selection (just like cancelling the first 
 touchmove
prevents scrolling). But if we have reasonable evidence that it's
non-breaking, we're happy to just align with WebKit and Gecko for 
 improved
interoperability.

 Agreed, though it may be breaking for other engines to change behavior
>>> too though, right? E.g. we are in a similar situation with
>>> overscroll-behavior on the root element (crbug.com/954423
>>> )
>>> where changing either behavior to the other will have compat risk.
>>>
>>
> Oh good point. And breaking intended selection is arguably worse than
> allowing unintended selection. Ok, that's a further argument for us
> accepting more risk here, thanks.
>
>>
- All agreed we're willing to take some risk here to achieve
interop quickly and don't want to impose too much of a burden of proof,
especially since the severity of breakage is likely low. We just need 
 some
more evidence that the risk is manageable.

 Perhaps the most 

Re: [blink-dev] Intent to Experiment: Web app scope extensions

['Lu Huang' via blink-dev]

New update (Jan 17th, 2024):
We found and 
fixed 
a flag 
check bug in M121 Chrome Beta that prevented this feature from working 
correctly.

With M121 being past the point of accepting merges, we would like to change 
the OT to run from M122-127 (instead of the previously approved M121-126) 
please.
Any objections? 
On Thursday, October 26, 2023 at 5:37:55 PM UTC-7 Chris Harrelson wrote:

> Yes, LGTM! Sorry for forgetting to email.
>
> On Thu, Oct 26, 2023 at 5:24 PM 'Lu Huang' via blink-dev <
> blin...@chromium.org> wrote:
>
>> We have a LGTM from Chris in the chromestatus page "API Owners" section 
>> (see attached screenshot). I think this means we are ok to proceed, but 
>> please let me know if I am mistaken and we need an explicit LGTM in this 
>> thread. Thanks! 
>>
>> On Monday, October 16, 2023 at 11:09:07 AM UTC-7 Lu Huang wrote:
>>
>>> In this case, I want to make sure there's enough time for app partners 
>>> to enroll in January when M121 reaches Stable and for us to help them 
>>> troubleshoot the configuration needed. This feature requires more 
>>> server-side configuration ( of /.well-known/web-app-origin-association) 
>>> that could take time to troubleshoot than other web app manifest features 
>>> in the past. 
>>>
>>> If things go well and we get the desired feedback in time, we could try 
>>> to move forward from OT before the 6 months are up. 
>>>
>>> On Monday, October 16, 2023 at 10:32:28 AM UTC-7 sligh...@chromium.org 
>>> wrote:
>>>
 I'm supportive of this, but curious why 6 milestones. If there are 
 partners signed up to provide feedback, can we summarize that input sooner 
 than 6 months?

 Best,

 Alex

 On Mon, Oct 16, 2023 at 9:00 AM 'Lu Huang' via blink-dev <
 blin...@chromium.org> wrote:

> Quick update: 
> We would like to push the start back to M121, and request that it run 
> for 6 milestones initially.
> First milestone: 121. 
> Last milestone: 126.
>
> On Thursday, October 12, 2023 at 10:11:29 AM UTC-7 
> mike...@chromium.org wrote:
>
>> Jason, could you please work with Lu to figure out why he can't post 
>> comments in the chromestatus entry (but can request a review)?
>>
>> thanks.
>> On 10/11/23 5:25 PM, 'Lu Huang' via blink-dev wrote:
>>
>> For the 3 review categories in chromestatus (security, privacy, and 
>> debuggability), I have clicked on request review but have not found a 
>> way 
>> to post comments from the UI.
>>
>> For security and privacy, we have a self-review at:  
>> manifest-incubations/scope_extensions-security-privacy-questionnaire.md 
>> at gh-pages · WICG/manifest-incubations (github.com) 
>> 
>> For debuggability, here are the survey responses until I find out how 
>> to add to the comments at chromestatus:
>>
>> (1) Does the introduction of the new Web Platform feature break 
>> Chrome DevTools' existing developer experience? No. (2) Does Chrome 
>> DevTools' existing set of tooling features interact with the new Web 
>> Platform feature in an expected way? 
>> Yes. (3) Would the new Web Platform feature's acceptance and/or 
>> adoption benefit from adding a new developer workflow to Chrome 
>> DevTools? Yes. 
>> If adopted, this new feature would benefit from new UI and tooling in 
>> the 
>> Application Page of Chrome DevTools. DevTools support can help 
>> developers 
>> determine if they have set up the web app association configuration 
>> correctly and if their specified scope_extensions are valid.
>>
>> On Wednesday, October 11, 2023 at 2:12:09 PM UTC-7 Lu Huang wrote:
>>
>>> We would like to start running this experiment from 120 through 123 
>>> inclusive, but may have to delay start to 121 running through 124. 
>>>
>>>
>>>
>>> On Wednesday, October 11, 2023 at 7:54:51 AM UTC-7 Chris Harrelson 
>>> wrote:
>>>
 Please also fill out the 3 other review categories (security, 
 privacy, debuggability) in chromestatus. 


 On Wed, Oct 11, 2023 at 7:13 AM Mike Taylor  
 wrote:

> Hi there,
>
> Could you clarify which milestones you would like to run the 
> experiment on?
>
> thanks,
> Mike
> On 10/11/23 6:05 AM, 'Lu Huang' via blink-dev wrote:
>
> Contact emails 
> lu...@microsoft.com, luig...@microsoft.com, alanc...@chromium.org
>
> Explainer
>
> https://github.com/WICG/manifest-incubations/blob/gh-pages/scope_extensions-explainer.md
>
> Specification
> None

Re: [blink-dev] Intent to Ship: RTCRtpSender setParameters() extensions for requesting the generation of a key frame

['Vladimir Levin' via blink-dev]

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 <
blink-dev@chromium.org> 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 <
> blink-dev@chromium.org> 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
>>
>> RisksInteroperability 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.
>>
>> 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
>>
>> See WPT added as part of
>> https://chromium-review.googlesource.com/c/chromium/src/+/4643591
>>
>> 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=1354101
>>
>> Estimated milestones
>>
>> Shipping on desktop
>>
>> 122
>>
>>
>> Anticipated spec changes
>>
>> None
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5161082937409536
>>
>> This intent message was generated by Chrome Platform Status
>>  and then copy-pasted around
>>
>> --
>> 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/CADxkKiJ0%3D-O%2BQoJoXfEWO1KBrLNHWnzTUGxXJSJOpm8BJTQEjw%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/CAOqqYVEd14tYEaUdAUCeQGDqEKEJ7EiR1ikENhy%2B5G9sLEu1dA%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/CADsXd2PqZYvwPqD_koe7ay%2BsJs6bSs%2B_2RDPZRXRzPLKRG4T%2BQ%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: WGSL: unrestricted pointer parameters

[Corentin Wallez]

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 emailscwal...@google.com
>>>
>>> ExplainerNone
>>>
>>> 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 componentBlink>WebGPU
>>> 
>>>
>>> Search tagswebgpu 
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot 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
>>>
>>> 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://flagsNone
>>>
>>> Finch feature nameNone
>>>
>>> Non-finch justificationNone
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://bugs.chromium.org/p/tint/issues/detail?id=2053
>>>
>>> Availability expectationFeature 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/5181311436455936
>>>
>>> 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/ba42a6ec-585c-4a85-b9a6-dca5dc1bcd06n%40chromium.org
>> 
>> .
>>
>

-- 
You received this message because you 

Re: [blink-dev] Re: Intent to Ship: WGSL: unrestricted pointer parameters

[Chris Harrelson]

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 emailscwal...@google.com
>>
>> ExplainerNone
>>
>> 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 componentBlink>WebGPU
>> 
>>
>> Search tagswebgpu 
>>
>> TAG reviewNone
>>
>> TAG review statusNot 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
>>
>> 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://flagsNone
>>
>> Finch feature nameNone
>>
>> Non-finch justificationNone
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/tint/issues/detail?id=2053
>>
>> Availability expectationFeature 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/5181311436455936
>>
>> 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/ba42a6ec-585c-4a85-b9a6-dca5dc1bcd06n%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/CAOMQ%2Bw8_Y0Nuseso-x4ZwN7C%2BBjJ5OPNNfwRmp9-4i_Ki50sVA%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: WGSL: unrestricted pointer parameters

[Corentin Wallez]

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 emailscwal...@google.com
>
> ExplainerNone
>
> 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 componentBlink>WebGPU 
> 
>
> Search tagswebgpu 
>
> TAG reviewNone
>
> TAG review statusNot 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
>
> 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://flagsNone
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/tint/issues/detail?id=2053
>
> Availability expectationFeature 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/5181311436455936
>
> 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/ba42a6ec-585c-4a85-b9a6-dca5dc1bcd06n%40chromium.org.

Re: [blink-dev] Intent to Ship: New ALPS code point

[Victor Tan]

> TAG review is from 2021, has anything changed since then or is it still 
the same feature/spec that is shipping now?

It's the same feature already shipping in the Blink. I don't think we have 
change anything for the ALPS. This intend is only a TLS extension code 
point change. 
what we do is trying to mitigate a bug in the old code point, not to 
re-active or de-active any feature. 




On Wednesday, January 17, 2024 at 11:16:47 AM UTC-5 Manuel Rego wrote:

>
>
> On 13/01/2024 00:08, Victor Tan wrote:
> > TAG review
> > 
> > https://github.com/w3ctag/design-reviews/issues/549 
> > 
>
> TAG review is from 2021, has anything changed since then or is it still 
> the same feature/spec that is shipping now?
>
> > Firefox: Pending 
> https://github.com/mozilla/standards-positions/issues/510
> > 
>
> That's also quite old. Could you do a ping there, explaining the 
> willingness to ship in Blink, trying to reactivate it?
>
> > Safari: Pending 
> > https://lists.webkit.org/pipermail/webkit-dev/2021-April/031768.html 
> > 
>
> For WebKit I think we should fill a new standards position request at:
> https://github.com/WebKit/standards-positions/issues
>
> Thanks,
> 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/e2359a13-6661-4346-8677-1081e9f709b3n%40chromium.org.

Re: [blink-dev] Intent to Ship: New ALPS code point

[Chris Harrelson]

Please also fill out the various review gates (Privacy, Security, etc) in
the chromestatus entry.

On Wed, Jan 17, 2024 at 8:16 AM Manuel Rego Casasnovas 
wrote:

>
>
> On 13/01/2024 00:08, Victor Tan wrote:
> > TAG review
> >
> > https://github.com/w3ctag/design-reviews/issues/549
> > 
>
> TAG review is from 2021, has anything changed since then or is it still
> the same feature/spec that is shipping now?
>
> > Firefox: Pending
> https://github.com/mozilla/standards-positions/issues/510
> > 
>
> That's also quite old. Could you do a ping there, explaining the
> willingness to ship in Blink, trying to reactivate it?
>
> > Safari: Pending
> > https://lists.webkit.org/pipermail/webkit-dev/2021-April/031768.html
> > 
>
> For WebKit I think we should fill a new standards position request at:
> https://github.com/WebKit/standards-positions/issues
>
> Thanks,
>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/7ee096c8-22c1-4fcc-a2b4-c52de0010e5d%40igalia.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%2Bw8OiRE-mHrGFc3PAF4X8RFL9jQ-65JpBf9Xkix%2Bu_GakA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: New ALPS code point

[Manuel Rego Casasnovas]

On 13/01/2024 00:08, Victor Tan wrote:

TAG review

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



TAG review is from 2021, has anything changed since then or is it still 
the same feature/spec that is shipping now?



Firefox: Pending https://github.com/mozilla/standards-positions/issues/510



That's also quite old. Could you do a ping there, explaining the 
willingness to ship in Blink, trying to reactivate it?


Safari: Pending 
https://lists.webkit.org/pipermail/webkit-dev/2021-April/031768.html 



For WebKit I think we should fill a new standards position request at:
https://github.com/WebKit/standards-positions/issues

Thanks,
  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/7ee096c8-22c1-4fcc-a2b4-c52de0010e5d%40igalia.com.

[blink-dev] Re: Intent to Ship: New ALPS code point

[Victor Tan]

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 enable the new 
> ALPS code point for ACCEPT_CH  with HTTP/3 frame in a slow rollout, and 
> then eventually enable the new code point with HTTP/2 frame.
>
>
> Does the server have an indication if the client in question supports the 
> newer code point?
> If not, what would we expect servers that support the newer code point to 
> do?
>
>  
>
>
> Edge: No signals
>
> Firefox: Pending https://github.com/mozilla/standards-positions/issues/510
> Safari: Pending https://lists.webkit.org/pipermail/webkit-dev/2021-
> April/031768.html
>
> Web/Framework developers: https://twitter.com/Sawtaytoes/status/
> 1369031447940526080 https://twitter.com/_jayphelps/status/
> 1369023028735148032
>
> Activation
>
> The site’s TLS and HTTP serving application would need to be updated to 
> support this new code point. We aren’t aware of many sites using this 
> feature yet, however.
>
> Debuggability
>
> No special DevTools support needed. The effects of the code point change 
> of ACCEPT_CH frame will be visible in the DevTools’ network tab. Also, the 
> NetLog will record the ACCEPT_CH frame value if TLS ALPS extension is 
> negotiated successfully. 
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, Chrome OS, Android, and Android WebView)?
>
> Yes
>
> Is this feature fully tested by web-platform-tests 
> 
> ?
>
> No, this feature is tested with browser-side tests. We can’t test 
> TLS-adjacent features currently through web-platform-tests. See this issue: 
> https://github.com/web-platform-tests/wpt/issues/20159   
>
> Flag name
>
> UseNewAlpsCodepointHttp2
>
> UseNewAlpsCodepointQUIC
>
> Tracking bug
>
> b/289087287 
>
> Launch bug
>
> https://launch.corp.google.com/launch/4299022 
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5149147365900288 
>
>

-- 
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/1d4cd923-5487-4cdf-a167-4da7b6a0a84cn%40chromium.org.

Re: [blink-dev] Intent to Prototype and Ship: MessagePort.onclose

[Chris Harrelson]

LGTM3

On Wed, Jan 17, 2024 at 7:25 AM Mike Taylor  wrote:

> LGTM2
> On 1/17/24 10:24 AM, Yoav Weiss (@Shopify) wrote:
>
> LGTM1
>
> On Friday, January 12, 2024 at 9:13:56 AM UTC+1 Nonoka Muraki wrote:
>
>> spec PR was merged.(https://github.com/whatwg/html/pull/9933)
>>
>> On Friday, January 12, 2024 at 12:41:31 AM UTC+9 Mike Taylor wrote:
>>
>>> Thanks Rakina - right now the biggest blocker is the unlanded spec PR.
>>> Things should move pretty quickly once that's resolved.
>>> On 1/10/24 11:15 PM, Rakina Zata Amni wrote:
>>>
>>> > Hoping that the design doc can become an GH explainer with the usual
>>> format, as the design doc doesn't answer questions in the strucutre we like
>>> to see
>>>
>>> Can you clarify which part isn't answered yet in the explainer
>>> 
>>> ?
>>>
>>> From the list in your link:
>>>
>>>- The user-facing problem which needs to be solved;
>>>- Covered by this section
>>>   
>>> 
>>>   .
>>>- The proposed approach to solving the problem;
>>>- Covered by this section
>>>   
>>> 
>>>   .
>>>- The way the proposed solution may be used in practice to address
>>>the intended use cases, via example code;
>>>- Pretty much covered by this section
>>>   
>>> 
>>>  although
>>>   there's no actual code example. We will add the code example 
>>> (basically
>>>   just an event listener using the close event)
>>>- Any other venues (such as mailing list, pull requests or issue
>>>threads external to the location of the explainer) where the reader may
>>>catch up on discussions regarding the proposed feature or features;
>>>- The issue  is linked
>>>   from the explainer.
>>>- The alternatives which have already been considered and why they
>>>were not chosen;
>>>- Covered by this section
>>>   
>>> 
>>>   .
>>>- Accessibility, security and privacy implications which have been
>>>considered as part of the design process.
>>>- Security & Privacy is covered by this sectio
>>>   
>>> n,
>>>   and there is no accessibility implication introduced by the new event.
>>>
>>>
>>> Please let us know if there are any parts that need further
>>> clarification.
>>>
>>> (BTW just to update the thread, the TAG review
>>>  has been
>>> requested last month)
>>>
>>> On Thu, Jan 4, 2024 at 1:49 AM Alex Russell 
>>> wrote:
>>>
 +1 to Yoav's excitement about this. Thank you for pushing it forward.

 On TAG review, we're living in hope that the newly-expanded TAG will
 have more bandwidth and focus for reviews, but as Mike says, we're
 increasingly timing out. Filing for review at I2P time is always the
 pro-move, and I it's a bad look for us to be leaving it to late regardless.

 Hoping that the design doc can become an GH explainer with the usual
 format, as the design doc doesn't answer questions in the strucutre we like
 to see:

 https://w3ctag.org/explainers/

 Best,

 Alex

 On Wednesday, December 13, 2023 at 8:46:20 AM UTC-8 Mike Taylor wrote:

> Gentle reminder to request approvals for the other review gates in
> chromestatus, thanks.
> On 12/1/23 1:05 PM, Mike Taylor wrote:
>
> On 11/30/23 10:56 PM, Fergal Daly wrote:
>
> On Wednesday, November 29, 2023 at 2:23:12 PM UTC+9 Yoav Weiss wrote:
>
>
> On Tue, 28 Nov 2023 at 12:31, Nonoka Muraki 
> wrote:
> TAG review
>
> Not needed because This is a small feature where we just dispatch a
> new event.
>
>
> Unfortunately that's not a criteria for skipping a TAG review. Can you
> file one?
>
>
> I'm concerned by this because every TAG review I've seen in the last
> couple of years has taken months to get a response. If our own privacy
> review is positive and we have agreement with other vendors would we block
> on the TAG review?
>
> In practice, we don't block on TAG reviews, but we like to give them a
> chance to review or comment within a reasonable time period (typically a
> week or two).
>
> --
> 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 Ship: Allow for WebAuthn credential creation in a cross-origin iframe

[Stephen Mcgruer]

Sounds great:

https://github.com/WebKit/standards-positions/issues/304
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
>>
>> 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/
>>
>> Blink component Blink>WebAuthentication
>> 
>>
>> 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 indicating that
>> creation cannot happen. This means that a developer can create a fallback
>> flow of: 1. Have some button for the user, e.g. "register passkey", in the
>> iframe 2. When the user clicks it, attempt to create a credential 3. If it
>> fails due to an incompatible browser, instead use the click to open a
>> pop-up window in which one *can* do the registration - a much poorer user
>> flow but one that works.
>>
>> *Gecko*: No signal
>>
>> *WebKit*: No signal No formal signal, but note that folks from Apple
>> were against the proposal when discussed in the WebAuthn WG
>>
>> *Web developers*: Positive developer feedback on
>> https://github.com/w3c/webauthn/issues/1656 (one example -
>> https://github.com/w3c/webauthn/issues/1656#issuecomment-890819845). No
>> known negative developer feedback
>>
>> *Other signals*:
>>
>> Security
>>
>> To avoid malicious iframes from creating credentials (attempting to trick
>> the user in some way), this feature requires both (a) a new permission
>> policy set on the frame, and (b) a user gesture (so the user must click or
>> interact with the iframe in some way).
>>
>> 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
>>
>> Existing devtools support suffices for this feature
>>
>> 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
>>
>> In review: https://github.com/web-platform-tests/wpt/pull/43729 (Chrome
>> Dev passes 5/5 added tests)
>>
>> Flag name on chrome://flags None
>>
>> Finch feature name WebAuthAllowCreateInCrossOriginFrame
>>
>> Requires code in //chrome? False
>>
>> Tracking bug
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1420639
>>
>> Estimated milestones
>> Shipping on desktop 122
>> DevTrial on desktop 122
>> Shipping on Android 122
>> DevTrial on Android 122
>> Anticipated spec changes
>>
>> Already landed in the spec, no remaining changes expected.
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5175677674586112
>>
>> Links to previous Intent discussions Intent to prototype:
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Maf7EmNUH1zYSi7DimKd5NfddYY3navNx3-ELPyeqHpPMw%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] Re: Intent to Ship: New ALPS code point

[Yoav Weiss (@Shopify)]

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 enable the new 
ALPS code point for ACCEPT_CH  with HTTP/3 frame in a slow rollout, and 
then eventually enable the new code point with HTTP/2 frame.


Does the server have an indication if the client in question supports the 
newer code point?
If not, what would we expect servers that support the newer code point to 
do?

 


Edge: No signals

Firefox: Pending https://github.com/mozilla/standards-positions/issues/510
Safari: Pending https://lists.webkit.org/pipermail/webkit-dev/2021-
April/031768.html

Web/Framework developers: https://twitter.com/Sawtaytoes/status/
1369031447940526080 https://twitter.com/_jayphelps/status/
1369023028735148032

Activation

The site’s TLS and HTTP serving application would need to be updated to 
support this new code point. We aren’t aware of many sites using this 
feature yet, however.

Debuggability

No special DevTools support needed. The effects of the code point change of 
ACCEPT_CH frame will be visible in the DevTools’ network tab. Also, the 
NetLog will record the ACCEPT_CH frame value if TLS ALPS extension is 
negotiated successfully. 

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

Yes

Is this feature fully tested by web-platform-tests 

?

No, this feature is tested with browser-side tests. We can’t test 
TLS-adjacent features currently through web-platform-tests. See this issue: 
https://github.com/web-platform-tests/wpt/issues/20159   

Flag name

UseNewAlpsCodepointHttp2

UseNewAlpsCodepointQUIC

Tracking bug

b/289087287 

Launch bug

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

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

-- 
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/111574be-7686-4003-90f4-ea1f607921b9n%40chromium.org.

Re: [blink-dev] Intent to Ship: PointerEvent.deviceId for Mult-Pen Inking

[Yoav Weiss (@Shopify)]

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 <
blink-dev@chromium.org> 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) 
 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) 

3. A PR against the PointerEvent spec with proposed changes:  Add deviceId 
to PointerEvent spec by sahirv · Pull Request #495 · w3c/pointerevents 
(github.com)  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 \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.

Also, it's unfortunate that TAG and standards positions requests have not 
resulted in anything, but that is hardly your fault. There were some 
questions in the WebKit request. Is all that ok now?

/Daniel
On 2023-10-06 20:10, 'Sahir Vellani' via blink-dev wrote:



On Friday, October 6, 2023 at 9:03:35 AM UTC-7 mike...@chromium.org wrote:


On 10/4/23 7:43 PM, 'Sahir Vellani' via blink-dev wrote:

Contact emails 
gerc...@microsoft.com, sahir@microsoft.com

Explainer 
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/
PointerEventDeviceId/explainer.md

Specification 
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/
PointerEventDeviceId/explainer.md


Is there a more formal spec for this?
Any support outside of Microsoft that would enable y'all to move this to 
the WICG?
 



Summary 

As devices with advanced pen input capabilities are becoming increasingly 
prevalent, it is important that the web platform continues to evolve to 
fully support these advanced features in order to unlock rich experiences 
for both end users and developers. One such advancement is the ability for 
a device's digitizer to recognize more than one pen device interacting with 
it simultaneously. This feature is an extension to the PointerEvent 
interface to include a new attribute, deviceId, that represents a 
session-persistent, document isolated, unique identifier that a developer 
can reliably use to identify individual pens interacting with the page.


Blink component 
Blink>Input 


TAG review 
https://github.com/w3ctag/design-reviews/issues/880

TAG review status 
Pending. TAG review has been pending for 2 months.

Risks 


Interoperability and Compatibility 


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

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

*Web developers*: No signals

*Other signals*:

WebView application risks 

*Does this intent deprecate or change 

Re: [blink-dev] Intent to Prototype and Ship: MessagePort.onclose

[Mike Taylor]

LGTM2

On 1/17/24 10:24 AM, Yoav Weiss (@Shopify) wrote:

LGTM1

On Friday, January 12, 2024 at 9:13:56 AM UTC+1 Nonoka Muraki wrote:

spec PR was merged.(https://github.com/whatwg/html/pull/9933
)

On Friday, January 12, 2024 at 12:41:31 AM UTC+9 Mike Taylor wrote:

Thanks Rakina - right now the biggest blocker is the unlanded
spec PR. Things should move pretty quickly once that's resolved.

On 1/10/24 11:15 PM, Rakina Zata Amni wrote:

> Hoping that the design doc can become an GH explainer with
the usual format, as the design doc doesn't answer questions
in the strucutre we like to see

Can you clarify which part isn't answered yet in the
explainer

?


From the list in your link:

  * The user-facing problem which needs to be solved;
  o Covered by this section

.
  * The proposed approach to solving the problem;
  o Covered by this section

.
  * The way the proposed solution may be used in practice to
address the intended use cases, via example code;
  o Pretty much covered by this section


 although
there's no actual code example. We will add the code
example (basically just an event listener using the
close event)
  * Any other venues (such as mailing list, pull requests or
issue threads external to the location of the explainer)
where the reader may catch up on discussions regarding
the proposed feature or features;
  o The issue
 is
linked from the explainer.
  * The alternatives which have already been considered and
why they were not chosen;
  o Covered by this section

.
  * Accessibility, security and privacy implications which
have been considered as part of the design process.
  o Security & Privacy is covered by this sectio

n,
and there is no accessibility implication introduced
by the new event.


Please let us know if there are any parts that need further
clarification.

(BTW just to update the thread, the TAG review
 has
been requested last month)

On Thu, Jan 4, 2024 at 1:49 AM Alex Russell
 wrote:

+1 to Yoav's excitement about this. Thank you for pushing
it forward.

On TAG review, we're living in hope that the
newly-expanded TAG will have more bandwidth and focus for
reviews, but as Mike says, we're increasingly timing out.
Filing for review at I2P time is always the pro-move, and
I it's a bad look for us to be leaving it to late regardless.

Hoping that the design doc can become an GH explainer
with the usual format, as the design doc doesn't answer
questions in the strucutre we like to see:

https://w3ctag.org/explainers/

Best,

Alex

On Wednesday, December 13, 2023 at 8:46:20 AM UTC-8 Mike
Taylor wrote:

Gentle reminder to request approvals for the other
review gates in chromestatus, thanks.

On 12/1/23 1:05 PM, Mike Taylor wrote:


On 11/30/23 10:56 PM, Fergal Daly wrote:


On Wednesday, November 29, 2023 at 2:23:12 PM UTC+9
Yoav Weiss wrote:


On Tue, 28 Nov 2023 at 12:31, Nonoka Muraki
 wrote:
TAG review

Not needed because This is a small feature
where we just dispatch a new event.


Unfortunately that's not a criteria for
skipping a TAG review. Can you file one?


I'm concerned by this because every TAG review I've
seen in the last couple of years has taken months
to get a response. If our own privacy review is
positive and we have agreement with other vendors

Re: [blink-dev] Re: Intent to Ship: Allow for WebAuthn credential creation in a cross-origin iframe

[Mike Taylor]

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


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/


Blink component

Blink>WebAuthentication




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 indicating that creation
cannot happen. This means that a developer can create a fallback
flow of: 1. Have some button for the user, e.g. "register
passkey", in the iframe 2. When the user clicks it, attempt to
create a credential 3. If it fails due to an incompatible browser,
instead use the click to open a pop-up window in which one *can*
do the registration - a much poorer user flow but one that works.


/Gecko/: No signal

/WebKit/: No signal No formal signal, but note that folks from
Apple were against the proposal when discussed in the WebAuthn WG

/Web developers/: Positive developer feedback on
https://github.com/w3c/webauthn/issues/1656 (one example -
https://github.com/w3c/webauthn/issues/1656#issuecomment-890819845).
No known negative developer feedback

/Other signals/:


Security

To avoid malicious iframes from creating credentials (attempting
to trick the user in some way), this feature requires both (a) a
new permission policy set on the frame, and (b) a user gesture (so
the user must click or interact with the iframe in some way).


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

Existing devtools support suffices for this feature


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

In review: https://github.com/web-platform-tests/wpt/pull/43729
(Chrome Dev passes 5/5 added tests)


Flag name on chrome://flags

None


Finch feature name

WebAuthAllowCreateInCrossOriginFrame


Requires code in //chrome?

False


Tracking bug

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


Estimated milestones

Shipping on desktop 122
DevTrial on desktop 122

Shipping on Android 122
DevTrial on Android 122


Anticipated spec changes

Already landed in the spec, no remaining changes expected.


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5175677674586112


Links to previous Intent discussions

Intent to prototype:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Maf7EmNUH1zYSi7DimKd5NfddYY3navNx3-ELPyeqHpPMw%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.

Re: [blink-dev] Intent to Prototype and Ship: MessagePort.onclose

[Yoav Weiss (@Shopify)]

LGTM1

On Friday, January 12, 2024 at 9:13:56 AM UTC+1 Nonoka Muraki wrote:

> spec PR was merged.(https://github.com/whatwg/html/pull/9933)
>
> On Friday, January 12, 2024 at 12:41:31 AM UTC+9 Mike Taylor wrote:
>
>> Thanks Rakina - right now the biggest blocker is the unlanded spec PR. 
>> Things should move pretty quickly once that's resolved.
>> On 1/10/24 11:15 PM, Rakina Zata Amni wrote:
>>
>> > Hoping that the design doc can become an GH explainer with the usual 
>> format, as the design doc doesn't answer questions in the strucutre we like 
>> to see
>>
>> Can you clarify which part isn't answered yet in the explainer 
>> 
>> ? 
>>
>> From the list in your link:
>>
>>- The user-facing problem which needs to be solved;
>>- Covered by this section 
>>   
>> 
>>   . 
>>- The proposed approach to solving the problem;
>>- Covered by this section 
>>   
>> 
>>   . 
>>- The way the proposed solution may be used in practice to address 
>>the intended use cases, via example code;
>>- Pretty much covered by this section 
>>   
>> 
>>  although 
>>   there's no actual code example. We will add the code example 
>> (basically 
>>   just an event listener using the close event) 
>>- Any other venues (such as mailing list, pull requests or issue 
>>threads external to the location of the explainer) where the reader may 
>>catch up on discussions regarding the proposed feature or features;
>>- The issue  is linked 
>>   from the explainer. 
>>- The alternatives which have already been considered and why they 
>>were not chosen;
>>- Covered by this section 
>>   
>> 
>>   . 
>>- Accessibility, security and privacy implications which have been 
>>considered as part of the design process.
>>- Security & Privacy is covered by this sectio 
>>   
>> n,
>>  
>>   and there is no accessibility implication introduced by the new event. 
>>
>>
>> Please let us know if there are any parts that need further clarification.
>>
>> (BTW just to update the thread, the TAG review 
>>  has been requested 
>> last month)
>>
>> On Thu, Jan 4, 2024 at 1:49 AM Alex Russell  
>> wrote:
>>
>>> +1 to Yoav's excitement about this. Thank you for pushing it forward. 
>>>
>>> On TAG review, we're living in hope that the newly-expanded TAG will 
>>> have more bandwidth and focus for reviews, but as Mike says, we're 
>>> increasingly timing out. Filing for review at I2P time is always the 
>>> pro-move, and I it's a bad look for us to be leaving it to late regardless.
>>>
>>> Hoping that the design doc can become an GH explainer with the usual 
>>> format, as the design doc doesn't answer questions in the strucutre we like 
>>> to see:
>>>
>>> https://w3ctag.org/explainers/
>>>
>>> Best,
>>>
>>> Alex
>>>
>>> On Wednesday, December 13, 2023 at 8:46:20 AM UTC-8 Mike Taylor wrote:
>>>
 Gentle reminder to request approvals for the other review gates in 
 chromestatus, thanks.
 On 12/1/23 1:05 PM, Mike Taylor wrote:

 On 11/30/23 10:56 PM, Fergal Daly wrote:

 On Wednesday, November 29, 2023 at 2:23:12 PM UTC+9 Yoav Weiss wrote:


 On Tue, 28 Nov 2023 at 12:31, Nonoka Muraki  
 wrote:
 TAG review 

 Not needed because This is a small feature where we just dispatch a new 
 event.


 Unfortunately that's not a criteria for skipping a TAG review. Can you 
 file one?


 I'm concerned by this because every TAG review I've seen in the last 
 couple of years has taken months to get a response. If our own privacy 
 review is positive and we have agreement with other vendors would we block 
 on the TAG review?

 In practice, we don't block on TAG reviews, but we like to give them a 
 chance to review or comment within a reasonable time period (typically a 
 week or two).



-- 
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/184aedde-7eb9-433f-b378-db2665df87cdn%40chromium.org.

Re: [blink-dev] Intent to Ship: PointerEvent.deviceId for Mult-Pen Inking

['Vladimir Levin' via blink-dev]

On Thu, Jan 11, 2024 at 6:08 PM 'Sahir Vellani' via blink-dev <
blink-dev@chromium.org> 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)
>  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)
> 
> 3. A PR against the PointerEvent spec with proposed changes:  Add
> deviceId to PointerEvent spec by sahirv · Pull Request #495 ·
> w3c/pointerevents (github.com)
>  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.
>

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 \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.
>
> Also, it's unfortunate that TAG and standards positions requests have
> not resulted in anything, but that is hardly your fault. There were some
> questions in the WebKit request. Is all that ok now?
>
> /Daniel
> On 2023-10-06 20:10, 'Sahir Vellani' via blink-dev wrote:
>
>
>
> On Friday, October 6, 2023 at 9:03:35 AM UTC-7 mike...@chromium.org
> wrote:
>
>
> On 10/4/23 7:43 PM, 'Sahir Vellani' via blink-dev wrote:
>
> Contact emails
> gerc...@microsoft.com, sahir@microsoft.com
>
> Explainer
>
> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md
>
> Specification
>
> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md
>
>
>>> Is there a more formal spec for this?
>>> Any support outside of Microsoft that would enable y'all to move this to
>>> the WICG?
>>>
>>>

>
> Summary
>
> As devices with advanced pen input capabilities are becoming
> increasingly prevalent, it is important that the web platform continues to
> evolve to fully support these advanced features in order to unlock rich
> experiences for both end users and developers. One such advancement is the
> ability for a device's digitizer to recognize more than one pen device
> interacting with it simultaneously. This feature is an extension to the
> PointerEvent interface to include a new attribute, deviceId, that
> represents a session-persistent, document isolated, unique identifier that
> a developer can reliably use to identify individual pens interacting with
> the page.
>
>
> Blink component
> Blink>Input
> 
>
> TAG review
> https://github.com/w3ctag/design-reviews/issues/880
>
> TAG review status
> Pending. TAG review has been pending for 2 months.
>
> Risks
>
>
> Interoperability and Compatibility
>
>
> *Gecko*: No signal (
> https://github.com/mozilla/standards-positions/issues/715)
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/102)
>
> 

Re: [blink-dev] Re: Intent to Prototype: document.caretPositionFromPoint API

[Daniel Bratell]

This is not directly related to this one function but more to the whole 
API. I quickly skimmed the spec and I could not find out how it handles 
line breaks which make caret positions ambigious?


When you press the END key at one line, and the HOME key at the 
following line your caret DOM position can be the same, but the visual 
caret positions should be different, and so should certain actions like 
arrow-down and arrow-up.


When developing code to handle this in Opera, I solved it by letting 
carets know if they were connected forward or backwards (basically a 
bool) in the dom element, but maybe this is solved in some other way now?


/Daniel

On 2024-01-16 18:31, 'Siye Liu' via blink-dev wrote:

Hi Brian,

To answer your question,
1. This prototype only covers the main dom scenario 
(https://crbug.com/388976). Shadow dom scenario is tracked in 
https://crbug.com/1514810.
2. The prototype should have similar behavior as caretRangeFromPoint's 
implementation in Blink (when the point is over an input element, the 
returned CaretPosition should be the nearest ancestor of the input 
element) because I expect both APIs share same hit testing logic under 
the hood.


Once the prototype is ready for dev trial, we can discuss further 
about improving current implementation in both caretRangeFromPoint and 
caretPositionFromPoint in Blink.



Thanks,
Siye

On Friday, January 12, 2024 at 5:23:25 PM UTC-8 Brian Birtles wrote:

Hi,

Will this also cover the behavioral differences between
caretPositionFromPoint as implemented in Gecko and
caretRangeFromPoint as implemented in Blink such as:

1. caretPositionFromPoint in Gecko digs into shadow DOM elements
whereas caretRangeFromPoint in Blink does not.
2. When the point is over a text input element,
caretPositionFromPoint in Gecko returns the text input element and
offset into it but caretRangeFromPoint in Blink returns the
nearest ancestor of the text input element. (Note that
caretRangeFromPoint in Webkit returns the text input element but
always returns a zero offset into it.)

Thanks,

Brian

2024年1月13日土曜日 3:35:59 UTC+9 si...@microsoft.com:

Contact emails
si...@microsoft.com, sa...@microsoft.com

Explainer
None

Specification
https://www.w3.org/TR/cssom-view-1/#dom-document-caretpositionfrompoint

Summary

This new API allows users to get current caret position from a
given screen point. The API returns a CaretPosition object
which represents the caret position indicating current text
insertion point including the containing DOM node, caret's
character offset, and the client rectangle of caret range.



Blink component
Blink>CSS



Motivation

document.caretPositionFromPoint API is in CSSOM View and is
already implemented by Gecko. WebKit/Blink has similar
document.caretRangeFromPoint API which returns a text range
indicating the text insertion point. The existing API was in
CSSOM View at the time it was implemented:
https://bugs.webkit.org/show_bug.cgi?id=27046

http://web.archive.org/web/20090708002518/http://dev.w3.org/csswg/cssom-view/#the-documentview-interface
The existing API was replaced by the new API later:
https://hg.csswg.org/drafts/rev/4c7b6f843171. The switch
happened around 2009 and we don't have the historical context
about the decision. Given how long it has been since the spec
was updated, we believe it's best that Blink complies with the
spec so that future innovations with the API can be spec
compliant and have lower interop/compat risk.



Initial public proposal
None

TAG review
None

TAG review status
Not applicable

Risks


Interoperability and Compatibility

Gecko already implemented the API. Webkit/Blink didn't
implement it. The interop risk is that it's unclear at this
moment about Webkit's position on this. We won't be able to
achieve full interop with this API if Webkit isn't willing to
support this API. There is a compat risk too if we decided to
deprecate the old API: https://crbug.com/690599



/Gecko/: Shipped/Shipping

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

/Web developers/: Positive
(https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c34)
Web developers are asking to have
document.caretPositionFromPoint API implemented in Blink:
https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c28
https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c34

/Other signals/:

WebView application risks

[blink-dev] Re: Intent to Experiment: Captured Surface Control

['Elad Alon' via blink-dev]

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 emailselad...@chromium.org
>
> Explainer
> https://github.com/screen-share/captured-surface-control/blob/main/README.md
>
> SpecificationTBD, 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 componentBlink>GetDisplayMedia 
> 
>
> TAG reviewNot started.
>
> TAG review statusPending. 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://flagscaptured-surface-control
>
> Finch feature nameCapturedDisplaySurface
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1466247
>
> Launch bughttps://launch.corp.google.com/launch/4268170
>
> Estimated milestones
> OriginTrial desktop last 127
> 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 discussionsIntent 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.

[blink-dev] Intent to Experiment: Captured Surface Control

['Elad Alon' via blink-dev]

Contact emailselada...@chromium.org

Explainer
https://github.com/screen-share/captured-surface-control/blob/main/README.md

SpecificationTBD, 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 componentBlink>GetDisplayMedia


TAG reviewNot started.

TAG review statusPending. 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://flagscaptured-surface-control

Finch feature nameCapturedDisplaySurface

Requires code in //chrome?False

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

Launch bughttps://launch.corp.google.com/launch/4268170

Estimated milestones
OriginTrial desktop last 127
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 discussionsIntent 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/CAMO6jDOS9KXm2ySOscYGskr%3DGak6w35iNkCNLt%2B%2BMxLhgxyqTA%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: Allow for WebAuthn credential creation in a cross-origin iframe

[Stephen Mcgruer]

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 emailssmcgr...@chromium.org
>
> ExplainerNone
>
> Specification
> 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/
>
> Blink componentBlink>WebAuthentication
> 
>
> TAG reviewNone
>
> TAG review statusNot 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 indicating that
> creation cannot happen. This means that a developer can create a fallback
> flow of: 1. Have some button for the user, e.g. "register passkey", in the
> iframe 2. When the user clicks it, attempt to create a credential 3. If it
> fails due to an incompatible browser, instead use the click to open a
> pop-up window in which one *can* do the registration - a much poorer user
> flow but one that works.
>
> *Gecko*: No signal
>
> *WebKit*: No signal No formal signal, but note that folks from Apple were
> against the proposal when discussed in the WebAuthn WG
>
> *Web developers*: Positive developer feedback on
> https://github.com/w3c/webauthn/issues/1656 (one example -
> https://github.com/w3c/webauthn/issues/1656#issuecomment-890819845). No
> known negative developer feedback
>
> *Other signals*:
>
> Security
>
> To avoid malicious iframes from creating credentials (attempting to trick
> the user in some way), this feature requires both (a) a new permission
> policy set on the frame, and (b) a user gesture (so the user must click or
> interact with the iframe in some way).
>
> 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
>
> Existing devtools support suffices for this feature
>
> 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
>
> In review: https://github.com/web-platform-tests/wpt/pull/43729 (Chrome
> Dev passes 5/5 added tests)
>
> Flag name on chrome://flagsNone
>
> Finch feature nameWebAuthAllowCreateInCrossOriginFrame
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1420639
>
> Estimated milestones
> Shipping on desktop 122
> DevTrial on desktop 122
> Shipping on Android 122
> DevTrial on Android 122
> Anticipated spec changes
>
> Already landed in the spec, no remaining changes expected.
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5175677674586112
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Maf7EmNUH1zYSi7DimKd5NfddYY3navNx3-ELPyeqHpPMw%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/CADY3MaeX7OPn44HzmaTraBj%3DYEaosz4Y-aYdDr4Y%2BT7mkm9A0Q%40mail.gmail.com.

[blink-dev] Intent to Ship: Allow for WebAuthn credential creation in a cross-origin iframe

[Stephen Mcgruer]

Contact emailssmcgr...@chromium.org

ExplainerNone

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

Blink componentBlink>WebAuthentication


TAG reviewNone

TAG review statusNot 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 indicating that
creation cannot happen. This means that a developer can create a fallback
flow of: 1. Have some button for the user, e.g. "register passkey", in the
iframe 2. When the user clicks it, attempt to create a credential 3. If it
fails due to an incompatible browser, instead use the click to open a
pop-up window in which one *can* do the registration - a much poorer user
flow but one that works.

*Gecko*: No signal

*WebKit*: No signal No formal signal, but note that folks from Apple were
against the proposal when discussed in the WebAuthn WG

*Web developers*: Positive developer feedback on
https://github.com/w3c/webauthn/issues/1656 (one example -
https://github.com/w3c/webauthn/issues/1656#issuecomment-890819845). No
known negative developer feedback

*Other signals*:

Security

To avoid malicious iframes from creating credentials (attempting to trick
the user in some way), this feature requires both (a) a new permission
policy set on the frame, and (b) a user gesture (so the user must click or
interact with the iframe in some way).

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

Existing devtools support suffices for this feature

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

In review: https://github.com/web-platform-tests/wpt/pull/43729 (Chrome Dev
passes 5/5 added tests)

Flag name on chrome://flagsNone

Finch feature nameWebAuthAllowCreateInCrossOriginFrame

Requires code in //chrome?False

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

Estimated milestones
Shipping on desktop 122
DevTrial on desktop 122
Shipping on Android 122
DevTrial on Android 122
Anticipated spec changes

Already landed in the spec, no remaining changes expected.

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Maf7EmNUH1zYSi7DimKd5NfddYY3navNx3-ELPyeqHpPMw%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/CADY3MacSSuysQWizFRwJv95%2BV9epzBDtyX-nf08RR-872TBPnQ%40mail.gmail.com.

Re: [blink-dev] Request for Deprecation Trial: Deprecate Third-Party Cookies

['Johann Hofmann' via blink-dev]

Hi all, a brief update that the team is still working on setting up the
first-party version of this Deprecation Trial.

In the meantime, if you're a developer experiencing breakage on your site
and are planning to apply to the first-party DT, please file a
breakage report via https://goo.gle/report-3pc-broken at your earliest
convenience to support faster processing once the DT registration opens.

Thanks,

Johann

On Tue, Dec 26, 2023 at 5:13 PM Chris Harrelson 
wrote:

> LGTM
>
> On Tue, Dec 26, 2023 at 8:11 AM 'Joshua Hood' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Hi Blink API owners,
>>
>> We would like to request your approval for adding a first-party version
>> of this Deprecation Trial. This will be helpful for top-level origins
>> that also need additional transition time, in cases where it is impossible,
>> impractical or unnecessary to sign the affected third-party (3P) providers
>> up for the 3P deprecation trial. This deprecation trial temporarily
>> provides cross-site cookie access for non-advertising use cases.
>>
>> This has been requested by web developers on threads such as the I2D
>> thread
>> 
>> for third-party cookies.
>>
>> Our proposed timelines for this trial remain unchanged:
>>
>> Registration opens the week of January 15, 2024 [1]
>>
>> The trial will end on December 27, 2024
>>
>> Effective in Chrome versions M120 through M132
>>
>> [1] As communicated previously, the grace period
>> 
>> that we are providing for the third-party deprecation trial also applies to
>> the first-party deprecation trial. Additionally, to minimize user impact
>> before registration for the trial opens, Chrome will provide temporary
>> access to third-party cookies for sites with reported
>>  user-facing breakage during this
>> grace period.
>>
>> On Tuesday, December 5, 2023 at 3:53:04 PM UTC-5 Ben Kelly wrote:
>>
>>> FYI, we are also planning to provide a grace period for sites registered
>>> and approved for the deprecation trial to give them time to deploy trial
>>> tokens.  See this updated section of the blog post:
>>>
>>>
>>> https://developers.google.com/privacy-sandbox/blog/third-party-cookie-deprecation-trial#:~:text=We%20acknowledge%20that,the%20grace%20period
>>> .
>>>
>>> On Tue, Dec 5, 2023 at 12:22 PM Ben Kelly  wrote:
>>>
 The deprecation trial is now open for registrations:


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

 Again, please be aware this trial will require a review process as
 outlined in the blog pos
 
 t.

 On Tue, Nov 21, 2023 at 2:53 PM Ben Kelly 
 wrote:

> FYI, please see this blog post for more information on this
> deprecation trial:
>
> https://developer.chrome.com/blog/third-party-cookie-deprecation-trial/
>
> On Fri, Nov 17, 2023 at 7:52 PM Mike Taylor 
> wrote:
>
>> LGTM for a deprecation trial from M120 to M132. For those of you who
>> have followed my career (all 2 of you), it shouldn't come as a surprise
>> that I appreciate the desire and efforts to minimize the compat
>> implications for sites that are earnestly moving towards this brave new
>> post-3rd-party cookies world.
>>
>> (Note: I don't work on third-party cookie deprecation but I would
>> have landed on a similarly recommended timeline for 
>> migration/deprecation.
>> Thanks for being accommodating and realistic to the complicated demands 
>> of
>> web development and deployment of different use-cases.)
>>
>> On 11/17/23 1:21 PM, Ben Kelly wrote:
>>
>> Contact emails
>>
>> joha...@chromium.org, wande...@chromium.org
>>
>> Explainer
>>
>> None
>>
>> Specification
>>
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-12#name-the-cookie-header-field
>>
>> Summary
>>
>> We intend to deprecate and remove default access to third-party (aka
>> cross-site) cookies as part of the Privacy Sandbox Timeline for the Web,
>> starting with an initial 1% testing period in Q1 2024, followed by a
>> gradual phaseout planned to begin in Q3 2024 after consultation with the
>> CMA. (The gradual phaseout is subject to addressing any remaining
>> competition concerns of the UK’s Competition and Markets Authority.)
>>
>> Phasing out third-party cookies (3PCs) is a central effort to the
>> Privacy Sandbox initiative, which aims to responsibly reduce cross-site
>> tracking on the web (and beyond) while supporting key use cases through 
>> new
>> technologies. Our phaseout plan was 

Re: [blink-dev] Intent to Ship: Long Animation Frame Timing

[Manuel Rego Casasnovas]

On 15/01/2024 11:31, Noam Rosenthal wrote:


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6118675067699200



Can you tick the other review boxes on the entry?

Not sure I understand what boxes?


Yoav refers to the buttons to request other reviews (apart from the API 
owners review that happens here).


In "Prepare to ship" section you can find buttons for the following reviews:
* Privacy
* Security
* Enterprise
* Debuggability
* Testing

You should click those to request a review from the different parties.

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/704e3d0e-e8cb-4802-8e20-e8cb01641b99%40igalia.com.

Re: [blink-dev] Intent to Ship: Long Animation Frame Timing

['Noam Rosenthal' via blink-dev]

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.