[blink-dev] Chromium Issue Tracker migration begins now!

['Joe Gregorio' via blink-dev]

Hi everyone,

The migration to the new Chromium Issue Tracker is beginning now (5pm
PT)! Please
expect downtime until the migration is complete (likely <48 hours).

To file bugs during downtime and get progress updates, please see:
g.co/dev/chromium-migration. For all non-critical issues, please wait until
the migration is complete to file in Chromium’s new issue tracker.

We will confirm via email once the migration is complete and the new Issue
Tracker is ready for use.

Please note: Any CLs merged during the migration, while all bug trackers
are read-only, will not have their corresponding bugs updated by
GitWatcher. This will have to be done manually.

Thanks,

Joe, on behalf of the Chromium Issue Tracker team

-- 
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/CAA6qSUBCNZrYjJA2qQR2EhedR_V70VmzSgTxvWrnZExu7Xmp-A%40mail.gmail.com.

[blink-dev] Intent to Prototype: 'pageconceal' event

['Khushal Sagar' via blink-dev]

Contact emailskhushalsa...@chromium.org, nrosent...@chromium.org

Explainer
https://github.com/WICG/view-transitions/blob/main/cross-doc-explainer.md#pageconceal

Specificationhttps://github.com/whatwg/html/pull/10002

Summary

The `pageconceal` event is fired on a Document's window object when a
navigation will replace this Document with a new Document. The event
provides activation info about the navigation (type, NavigationHistoryEntry
for the new Document). If the navigation has a cross-document
ViewTransition, the event is dispatched before capturing state for the old
Document. This allows the page-author to configure the old state captured
for the transition based on the navigation's activation info and the
current visual state of the old Document. This feature is split out from
the larger ViewTransition-on-Navigation project.


Blink componentBlink>ViewTransitions


Motivation

Cross-document ViewTransition need an event on the old Document so authors
can set up view-transition-names (or any other DOM state) to influence how
the Document is captured. This event needs to be fired: - After the final
response is received which provides the post redirect URL committed by the
navigation. - Before the last rendering opportunity for the Document (which
draws the frame cached by the browser) that runs after the navigation is
ready to commit. There is no existing event which aligns with the timing
requirements above. See discussion on
https://github.com/whatwg/html/issues/9702 for details. The event fires for
all cross-document navigation commits, with a nullable ViewTransition. This
allows authors to detect whether a cross-document navigation had a
transition.


Initial public proposalhttps://github.com/whatwg/html/issues/9702

TAG review
https://github.com/w3ctag/design-reviews/issues/851#issuecomment-1924730258

TAG review statusPending

Risks


Interoperability and Compatibility

None


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

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

*Web developers*: Strongly positive

*Other signals*:

WebView application risks

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

None


Debuggability

None


Is this feature fully tested by web-platform-tests

?No

Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Estimated milestones

No milestones specified


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

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/CAMLuWUyCjahhiLy_%2B3mXTfF9v8h0T7tuZRa2FujT1qn_%3DXfQpw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Support in Chrome for the VoiceIsolation getUserMedia constraint

[Per Åhgren]

> TAG review status

Issues addressed
> This is somewhat at odds with the previous response. :) Did you intend to
> link a TAG review and forget?
>
Sorry, my bad. I did not remove this from the template before sending it.
The intention was not to add any issues and there is no TAG review to link.

Could we please request signals?

Yes, signals have now been requested
https://github.com/mozilla/standards-positions/issues/982
https://github.com/WebKit/standards-positions/issues/314


> I assume this was added because it would be useful for certain video and
> voice web applications - are we aware of any signals from developers who
> have asked for it, or given feedback? You mention specific partners below -
> anything you can share?

This has been requested by WebRTC developers, partly as a means for Web
apps to achieve a clean microphone signal in ChromeOS but also
to allow web apps to utilize voice-isolation effects on ChromeOS in an
informed manner.




On Fri, Jan 26, 2024 at 11:19 AM Mike Taylor  wrote:

> Hi Per,
> On 1/26/24 8:27 AM, Per Åhgren wrote:
>
> Contact emails p...@chromium.org
>
> Explainer None
>
> Specification
> https://w3c.github.io/mediacapture-extensions/#voiceisolation-constraint
>
> Summary
>
> This is about adding support in Chrome for the VoiceIsolation getUserMedia
> constraint (
> https://w3c.github.io/mediacapture-extensions/#voiceisolation-constraint).
> The constraint only takes effect on platforms where there is low-level
> support for voice-isolation style denoising. Currently this is limited to a
> selected number of ChromeOS devices, but further platforms will be added.
>
>
> Blink component Blink>WebRTC
> 
>
> TAG review None
>
> TAG review status Issues addressed
>
> This is somewhat at odds with the previous response. :) Did you intend to
> link a TAG review and forget?
>
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> Could we please request signals?
>
>
> *Web developers*: No signals
>
> I assume this was added because it would be useful for certain video and
> voice web applications - are we aware of any signals from developers who
> have asked for it, or given feedback? You mention specific partners below -
> anything you can share?
>
>
> *Other signals*:
>
> Ergonomics
>
> This will not have any impact on the performance of Chrome as it control
> system level effects, which already today are controllable at a system
> level.
>
>
> Activation
>
> No risks percieved.
>
>
> Security
>
> No risks percieved.
>
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> No
>
>
> Debuggability
>
> None
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)? Yes
>
> The constraint is supported on all platforms, but the actual platform
> support depends on where there are available matching effects at a system
> level. Initially, the only such platform is ChromeOS, where a subset of the
> devices
>
>
> Is this feature fully tested by web-platform-tests
> 
> ? Yes
>
>
> https://wpt.fyi/results/mediacapture-streams/GUM-non-applicable-constraint.https.html?label=experimental=master
> https://wpt.fyi/results/mediacapture-streams/MediaStreamTrack-getCapabilities.https.html?label=experimental=master
> https://wpt.fyi/results/mediacapture-streams/MediaStreamTrack-getSettings.https.html?label=experimental=master
> https://wpt.fyi/results/mediacapture-streams/MediaDevices-getSupportedConstraints.https.html?label=experimental=master
>
>
> Flag name on chrome://flags None
>
> Finch feature name MediaCaptureVoiceIsolation
>
> Requires code in //chrome? False
>
> Availability expectation Feature is available in ChromeOS in M123
>
> Adoption expectation Feature is used by specific partner(s) to provide
> functionality within 12 months of launch in Chrome.
>
> Sample links
>
> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/mediacapture-streams/MediaStreamTrack-getSettings.https.html
>
> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/mediacapture-streams/MediaStreamTrack-getCapabilities.https.html
>
> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/mediacapture-streams/MediaDevices-getSupportedConstraints.https.html
>
> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/mediacapture-streams/GUM-non-applicable-constraint.https.html
>
> Estimated milestones
> Shipping on desktop 123
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web 

Re: [blink-dev] Intent to Prototype and Ship: Private network access checks for navigation requests: warning-only mode

[Mike Taylor]

Correction: LGTM1, conditioned on requesting Enterprise, Debuggability, 
and Testing bits in chromestatus. :)


On 2/2/24 5:09 PM, Mike Taylor wrote:


LGTM1

On 2/2/24 11:17 AM, Jonathan Hao wrote:



Contact emails

p...@chromium.org


Explainer

https://github.com/WICG/private-network-access/blob/main/explainer.md


Specification

https://wicg.github.io/private-network-access


Design docs


https://docs.google.com/document/d/1UqkJsc2VZ4bXmZkVxh-EPyBFEtdxX9p2zX4sxzAj754/edit?usp=sharing=0-7cfhrTo57AElxA6M9EVScg 




Summary

Before a website A navigates to another site B in the user's private 
network, this feature does the following:

1. Checks whether the request has been initiated from a secure context
2. Sends a preflight request, and checks whether B responds with a 
header that allows private network access.


The above checks are made to protect the user's private network. 
There are already features for subresources and workers, but this one 
is for navigation requests specifically.



Since this feature is the "warning-only" mode, we do not fail the 
requests if any of the checks fails.  Instead, a warning will be 
shown in the DevTools, to help developers prepare for the coming 
enforcement.




Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess 




Motivation

To prevent malicious websites from pivoting through the user agent's 
network position to attack devices and services which reasonably 
assumed they were unreachable from the Internet at large, by virtue 
of residing on the user’s local intranet or the user's machine.




Initial public proposal

https://discourse.wicg.io/t/transfer-cors-rfc1918-and-hsts-priming-to-wicg/1726


TAG review

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


TAG review status

Issues addressed


Risks



Interoperability and Compatibility

Since we don't enforce the checks and only show warnings, there isn't 
any compatibility risks on the client side. On the server side, it 
shouldn't pose any risk either as the server can ignore the preflight 
requests.




/Gecko/: Positive 
(https://github.com/mozilla/standards-positions/issues/143)
https://mozilla.github.io/standards-positions/#cors-and-rfc1918 makes 
it a bit clearer that this is indeed positive (vs the issue).


/WebKit/: Positive 
(https://github.com/WebKit/standards-positions/issues/163) Safari 
disagrees with the spec name and header names, but still overall 
positive.


/Web developers/: Mixed signals Anecdotal evidence so far suggests 
that most web developers are OK with this new requirement, though 
some do not control the target endpoints and would be negatively 
impacted.


/Other signals/:


Security

This change aims to be security-positive, preventing CSRF attacks 
against soft and juicy targets such as router admin interfaces. DNS 
rebinding threats were of particular concern during the design of 
this feature: 
https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit#heading=h.189j5gnadts9




WebView application risks

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


None



Debuggability

Relevant information (client and resource IP address space) is 
already piped into the DevTools network panel. Deprecation warnings 
and errors will be surfaced in the DevTools issues panel explaining 
the problem when it arises.




Is this feature fully tested by web-platform-tests

?

Yes

https://wpt.fyi/results/fetch/private-network-access?q=fetch%2Fprivate-network-access_id=5090117631868928_id=6245938696814592_id=5769215446351872_id=5679819023974400 





Flag name on chrome://flags

None


Finch feature name

PrivateNetworkAccessForNavigations, 
PrivateNetworkAccessForNavigationsWarningOnly



Requires code in //chrome?

False


Tracking bug

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


Estimated milestones

Shipping on desktop 124

Shipping on Android 124



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4869685172764672

This intent message was generated by Chrome Platform Status 
.

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

Re: [blink-dev] Intent to Prototype and Ship: Private network access checks for navigation requests: warning-only mode

[Mike Taylor]

LGTM1

On 2/2/24 11:17 AM, Jonathan Hao wrote:



Contact emails

p...@chromium.org


Explainer

https://github.com/WICG/private-network-access/blob/main/explainer.md


Specification

https://wicg.github.io/private-network-access


Design docs


https://docs.google.com/document/d/1UqkJsc2VZ4bXmZkVxh-EPyBFEtdxX9p2zX4sxzAj754/edit?usp=sharing=0-7cfhrTo57AElxA6M9EVScg 




Summary

Before a website A navigates to another site B in the user's private 
network, this feature does the following:

1. Checks whether the request has been initiated from a secure context
2. Sends a preflight request, and checks whether B responds with a 
header that allows private network access.


The above checks are made to protect the user's private network. There 
are already features for subresources and workers, but this one is for 
navigation requests specifically.



Since this feature is the "warning-only" mode, we do not fail the 
requests if any of the checks fails.  Instead, a warning will be shown 
in the DevTools, to help developers prepare for the coming enforcement.




Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess 




Motivation

To prevent malicious websites from pivoting through the user agent's 
network position to attack devices and services which reasonably 
assumed they were unreachable from the Internet at large, by virtue of 
residing on the user’s local intranet or the user's machine.




Initial public proposal

https://discourse.wicg.io/t/transfer-cors-rfc1918-and-hsts-priming-to-wicg/1726


TAG review

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


TAG review status

Issues addressed


Risks



Interoperability and Compatibility

Since we don't enforce the checks and only show warnings, there isn't 
any compatibility risks on the client side. On the server side, it 
shouldn't pose any risk either as the server can ignore the preflight 
requests.




/Gecko/: Positive 
(https://github.com/mozilla/standards-positions/issues/143)
https://mozilla.github.io/standards-positions/#cors-and-rfc1918 makes it 
a bit clearer that this is indeed positive (vs the issue).


/WebKit/: Positive 
(https://github.com/WebKit/standards-positions/issues/163) Safari 
disagrees with the spec name and header names, but still overall positive.


/Web developers/: Mixed signals Anecdotal evidence so far suggests 
that most web developers are OK with this new requirement, though some 
do not control the target endpoints and would be negatively impacted.


/Other signals/:


Security

This change aims to be security-positive, preventing CSRF attacks 
against soft and juicy targets such as router admin interfaces. DNS 
rebinding threats were of particular concern during the design of this 
feature: 
https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit#heading=h.189j5gnadts9




WebView application risks

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


None



Debuggability

Relevant information (client and resource IP address space) is already 
piped into the DevTools network panel. Deprecation warnings and errors 
will be surfaced in the DevTools issues panel explaining the problem 
when it arises.




Is this feature fully tested by web-platform-tests

?

Yes

https://wpt.fyi/results/fetch/private-network-access?q=fetch%2Fprivate-network-access_id=5090117631868928_id=6245938696814592_id=5769215446351872_id=5679819023974400 





Flag name on chrome://flags

None


Finch feature name

PrivateNetworkAccessForNavigations, 
PrivateNetworkAccessForNavigationsWarningOnly



Requires code in //chrome?

False


Tracking bug

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


Estimated milestones

Shipping on desktop 124

Shipping on Android 124



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4869685172764672

This intent message was generated by Chrome Platform Status 
.

--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 

Re: [blink-dev] Intent to Ship: 'pagereveal' event

[Chris Harrelson]

LGTM3

On Fri, Feb 2, 2024 at 2:03 PM Mike Taylor  wrote:

> LGMT2 - no concerns about lack of a response from TAG.
> On 2/2/24 1:18 AM, Domenic Denicola wrote:
>
> LGTM1
>
> On Fri, Feb 2, 2024 at 6:53 AM David Bokan  wrote:
>
>> Contact emails bo...@chromium.org, khushalsa...@chromium.org,
>> nrosent...@chromium.org, vmp...@chromium.org
>>
>> Explainer
>> https://github.com/WICG/view-transitions/blob/main/cross-doc-explainer.md
>>
>> Specification https://html.spec.whatwg.org/#reveal
>>
>> Design docs
>> https://github.com/WICG/view-transitions/blob/main/cross-doc-explainer.md
>>
>> Summary
>>
>> The `pagereveal` event is fired on a Document's window object at the
>> first render opportunity after a Document is: initially loaded, restored
>> from the back-forward cache, or activated from a prerender. It can be used
>> by a page author to set up a page entry UX - such as a ViewTransition from
>> a previous state. This feature is split out from the larger Cross Document
>> View Transition project.
>>
>>
>> Blink component Blink>ViewTransitions
>> 
>>
>> Search tags transition
>> , firstrender
>> , reveal
>> , event
>> , viewtransition
>> 
>>
>> TAG review https://github.com/w3ctag/design-reviews/issues/851
>>
>> Note: TAG review was for Cross-Document View Transitions which included
>> this event as a piece. I asked TAG whether they'd like to do a separate
>> review but didn't receive a response.
>>
>
> I'll note that the ask was in 2023-09-28, with two other pings since then,
> so I think this is very fair. (And I also agree that this was covered by
> the original review request.)
>
>>
>> TAG review status Issues addressed
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> This is a new event so shouldn't have any compatibility risks. Usual
>> interop risk of other engines not adopting it exists but this should be low
>> since it's had input and discussion[1] from engineers of both WebKit and
>> Mozilla and is a dependency of cross-document view transitions which has
>> received a positive signal from at least Mozilla[2] (waiting to hear from
>> Apple[3]). [1] https://github.com/whatwg/html/issues/9315 [2]
>> https://github.com/mozilla/standards-positions/issues/677
>>
>> [3] https://github.com/WebKit/standards-positions/issues/302
>>
>>
>> *Gecko*: Positive (
>> https://github.com/mozilla/standards-positions/issues/677) See:
>> https://github.com/mozilla/standards-positions/issues/677#issuecomment-1904541389
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/303) Awaiting
>> response.
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> No
>>
>>
>> Debuggability
>>
>> None
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, ChromeOS, Android, and Android WebView)? Yes
>>
>> This is a standard HTML event applicable to all platforms
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ? Yes
>>
>>
>> https://wpt.fyi/results/html/browsers/browsing-the-web/history-traversal/pagereveal?label=experimental=master
>>
>
> Can you un-tentative these tests?
>
>
>>
>>
>> Flag name on chrome://flags
>> chrome://flags/#enable-experimental-web-platform-features
>>
>> Finch feature name PageRevealEvent
>>
>> Requires code in //chrome? False
>>
>> Tracking bug https://crbug.com/1466250
>>
>> Estimated milestones
>> Shipping on desktop 123
>> DevTrial on desktop 120
>> Shipping on Android 123
>> DevTrial on Android 120
>> Shipping on WebView 123
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or
>> interop issues. Please list open issues (e.g. links to known github issues
>> in the project for the feature specification) whose resolution may
>> introduce web compat/interop risk (e.g., changing to naming or structure of
>> the API in a non-backward-compatible way).
>> None
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5205586941837312
>>
>> Links to previous Intent discussions Intent to prototype:
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f0f76584-ea3f-43ab-946c-b920fc064344n%40chromium.org
>>
>> 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 

Re: [blink-dev] Intent to Ship: 'pagereveal' event

[Mike Taylor]

LGMT2 - no concerns about lack of a response from TAG.

On 2/2/24 1:18 AM, Domenic Denicola wrote:

LGTM1

On Fri, Feb 2, 2024 at 6:53 AM David Bokan  wrote:


Contact emails

bo...@chromium.org, khushalsa...@chromium.org,
nrosent...@chromium.org, vmp...@chromium.org


Explainer

https://github.com/WICG/view-transitions/blob/main/cross-doc-explainer.md


Specification

https://html.spec.whatwg.org/#reveal


Design docs


https://github.com/WICG/view-transitions/blob/main/cross-doc-explainer.md


Summary

The `pagereveal` event is fired on a Document's window object at
the first render opportunity after a Document is: initially
loaded, restored from the back-forward cache, or activated from a
prerender. It can be used by a page author to set up a page entry
UX - such as a ViewTransition from a previous state. This feature
is split out from the larger Cross Document View Transition project.



Blink component

Blink>ViewTransitions




Search tags

transition ,
firstrender ,
reveal , event
, viewtransition



TAG review

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

Note: TAG review was for Cross-Document View Transitions which
included this event as a piece. I asked TAG whether they'd like to
do a separate review but didn't receive a response.


I'll note that the ask was in 2023-09-28, with two other pings since 
then, so I think this is very fair. (And I also agree that this was 
covered by the original review request.)



TAG review status

Issues addressed


Risks



Interoperability and Compatibility

This is a new event so shouldn't have any compatibility risks.
Usual interop risk of other engines not adopting it exists but
this should be low since it's had input and discussion[1] from
engineers of both WebKit and Mozilla and is a dependency of
cross-document view transitions which has received a positive
signal from at least Mozilla[2] (waiting to hear from Apple[3]).
[1] https://github.com/whatwg/html/issues/9315 [2]
https://github.com/mozilla/standards-positions/issues/677

[3] https://github.com/WebKit/standards-positions/issues/302



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

https://github.com/mozilla/standards-positions/issues/677#issuecomment-1904541389

/WebKit/: No signal
(https://github.com/WebKit/standards-positions/issues/303)
Awaiting response.

/Web developers/: No signals

/Other signals/:


WebView application risks

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

No



Debuggability

None



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

Yes

This is a standard HTML event applicable to all platforms



Is this feature fully tested by web-platform-tests

?

Yes


https://wpt.fyi/results/html/browsers/browsing-the-web/history-traversal/pagereveal?label=experimental=master




Can you un-tentative these tests?



Flag name on chrome://flags

chrome://flags/#enable-experimental-web-platform-features


Finch feature name

PageRevealEvent


Requires code in //chrome?

False


Tracking bug

https://crbug.com/1466250


Estimated milestones

Shipping on desktop 123
DevTrial on desktop 120

Shipping on Android 123
DevTrial on Android 120

Shipping on WebView 123



Anticipated spec changes

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

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5205586941837312


Links to previous Intent 

Re: [blink-dev] Re: Intent to experiment - WebAssembly JavaScript Promise Integration (update)

['Panos Astithas' via blink-dev]

Hey Rick,

This intent was updated to last between M123-M132 after posting, but before
approval. Since it's not clear whether you looked at Chromestatus or the
email thread, can you confirm that your approval is indeed for these
milestones?

Thanks,
Panos

On Thu, Jan 25, 2024 at 10:29 AM Mike Taylor  wrote:

> Yep - that is an official positive signal, thanks!
> On 1/24/24 7:40 PM, Francis McCabe wrote:
>
> Does this:
> https://mozilla.github.io/standards-positions/#wasm-js-promise-integration
> count as an official positive signal?
>
> Francis
>
> On Wed, Jan 24, 2024 at 3:09 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>>
>>
>> On Friday, January 5, 2024 at 7:25:28 PM UTC+1 Francis McCabe wrote:
>>
>> This is an update to the previous intent-to-experiment (filled out a few
>> more fields)
>>
>> Contact emails...@chromium.org
>>
>> Explainerhttps://github.com/WebAssembly/js-promise-integration/blob/main/
>> proposals/js-promise-integration/Overview.md
>>
>> Specificationhttps://github.com/WebAssembly/js-promise-
>> integration/blob/main/proposals/js-promise-integration/Overview.md
>>
>> Summary
>>
>> Stack Switching denotes a technology that allows programs to suspend and
>> resume computation. This is an active area that is part of the WebAssembly
>> standards track. See https://github.com/WebAssembly/stack-switching and
>> https://github.com/WebAssembly/meetings/tree/main/stack. This particular
>> feature refers to the integration between JavaScript Promises and stack
>> switching. This is described in more detail in https://docs.google.com/
>> document/d/16Us-pyte2-9DECJDfGm5tnUpfngJJOc8jbj54HMqE9Y/edit#
>>
>>
>> Blink componentBlink>JavaScript>WebAssembly
>> 
>>
>> Search tagsstack switching
>> , Promise
>> , JSPI
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/809
>>
>> TAG review statusPending
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> This spec is backed by a standardization effort. We do not plan to ship
>> the JSPI until it has been standardized by the W3C Wasm WG. However, post
>> standardization, we will depend on all browsers implementing the standard.
>>
>>
>> *Gecko*: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1850627)
>> Mozilla have started their own imlementation
>>
>>
>> That doesn't count as a positive signal. Please file for official signals
>>  (but that is not blocking for this OT).
>>
>>
>>
>> *WebKit*: No signal
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>>
>> Goals for experimentationThis specification is getting close to
>> finalization. We would like feedback from a wider audience as to the
>> utility and convenience of using the API.
>>
>> In addition, we are interested in performance benchmarking in production
>> applications.
>>
>> Ongoing technical constraints
>>
>> None.
>>
>>
>> Debuggability
>>
>> Developers can piggyback on existing DevTools support for Promises to
>> help with debugging JSPI applications. In particular the existing
>> mechanisms for constructing extended stack traces from so-called Promise
>> chains will also include stack traces from JSPI applications.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, ChromeOS, Android, and Android WebView)?Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?No
>>
>>
>> I'm guessing it will be covered by tests, at least eventually?
>>
>>
>>
>>
>> Flag name on chrome://flagsenable-experimental-
>> webassembly-stack-switching
>>
>> Finch feature nameNone
>>
>> Non-finch justificationNone
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/v8/issues/detail?id=12191=
>> owner%3Ame=2
>>
>> Estimated milestonesOriginTrial desktop last130OriginTrial desktop first
>> 122OriginTrial Android last130OriginTrial Android first122OriginTrial
>> webView last130OriginTrial webView first122
>>
>> Link to entry on the Chrome Platform Statushttps://chromestatus.com/
>> feature/5674874568704000
>>
>> Links to previous Intent discussionsIntent to prototype: https://groups.
>> google.com/a/chromium.org/d/msgid/blink-dev/
>> CAAdKk6BGFseZ6pBO2qEW_xeovVw1_guVq26rcNM1nWY442Y5Ng%40mail.gmail.com Intent
>> to Experiment: https://groups.google.com/a/chromium.org/d/
>> msgid/blink-dev/CAE65UWD8e57Bd5x3nr63M3QcdPo6TKom%2BVZT%3DvO2Uo4x6th_kA%
>> 40mail.gmail.com
>>
>>
>> This intent message was generated by Chrome Platform Status
>> 

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

[Victor Tan]

the code point PR is merged. Feel free to take a look again. Thanks. 

On Wednesday, January 24, 2024 at 3:34:44 PM UTC-5 Victor Tan wrote:

> create a PR for the code point change on the RFC draft, will work on 
> there: https://github.com/vasilvv/tls-alps/pull/15, thanks. 
>
> On Wednesday, January 24, 2024 at 1:55:56 PM UTC-5 Erik Anderson wrote:
>
>> Thanks, it will be helpful to make sure this is documented outside of 
>> Chromium. I will also chat with some folks on Microsoft’s end that both own 
>> server implementations and have more IETF experience to explore how we can 
>> help with moving things forward.
>>
>>  
>>
>> *From:* Victor Tan  
>> *Sent:* Wednesday, January 24, 2024 9:00 AM
>> *To:* blink-dev 
>> *Cc:* Yoav Weiss ; blink-dev <
>> blink-dev@chromium.org>; Erik Anderson ; 
>> Chris Harrelson ; David Benjamin <
>> david...@chromium.org>; Mike Taylor ; Victor Tan 
>> ; Rick Byers 
>> *Subject:* Re: [blink-dev] Re: Intent to Ship: New ALPS code point
>>
>>  
>>
>> You don't often get email from victor...@chromium.org. Learn why this is 
>> important 
>>
>> Rick, thanks for question, I will create a PR on the ALPS RFC draft to 
>> document the new code point regarding the early experiment. 
>>
>> On Wednesday, January 24, 2024 at 11:15:39 AM UTC-5 Yoav Weiss wrote:
>>
>> On Wed, Jan 24, 2024 at 4:48 PM Rick Byers  wrote:
>>
>> Oof, I agree it's not good that the only documentation for the actual 
>> code point value is in Chromium code - that's the sort of thing our blink 
>> I2S process is supposed to prevent. In addition to confusion, there's also 
>> potential IP-risk downsides to this. Our blink process is generally to 
>> block shipping on the existence of some specification for everything 
>> necessary for a compatible implementation in a forum that ensures IP 
>> protection. While this isn't typically an adoption barrier for many 
>> companies, I know it has been in the past for some (including Microsoft). 
>> This doesn't mean we have to block on getting consensus in the "right" 
>> standards venue, we can just do a monkey-patch spec in a venue like the 
>> WICG, or an unlanded PR in a formal WG where the PR counts as an IP 
>> contribution. Then we can ship it as an "incubation" while doing the 
>> standards maturation work in parallel. Erik, can you comment on the extent 
>> to which such incubation spec work would help with Microsoft adoption?
>>
>>  
>>
>> Victor, is there any chance you can throw something together quickly 
>> (spec PR or monkey-patch) that would cover the gaps in what's necessary for 
>> compatible implementations? This particular delta seems very tiny and 
>> straightforward to me, so I was originally thinking I'd just approve it. 
>> But in principle I don't think we should be continuing to approve changes 
>> to APIs which we realize are struggling with adoption due to the standards 
>> work not quite being up to our I2S bar.
>>
>>  
>>
>> +1 to defining these codepoints somewhere. Where are such codepoints 
>> typically defined? I'd have assumed they'd go into one of the relevant 
>> I-Ds..
>>
>>   
>>
>>  
>>
>> Erik, thank you for your offer of help on the standardization front! It 
>> definitely sounds to me like we should be pushing on the full standards 
>> effort in parallel to this specific intent. Having Microsoft and Google 
>> work together on that would hopefully be able to accelerate it.
>>
>>  
>>
>> Rick
>>
>>  
>>
>>  
>>
>> On Tue, Jan 23, 2024 at 11:40 AM 'Victor Tan' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>> To be clarify,  currently David is not working on the standardizing ALPS 
>> feature.   
>>
>>  
>>
>> On Tuesday, January 23, 2024 at 11:27:41 AM UTC-5 Victor Tan wrote:
>>
>> Hi Erik, 
>>
>> We are actively working on it, but we need to put more efforts to 
>> standardization. 
>>
>> In the last serval IETF, David is the only person is talking about the 
>> ALPS feature.  We'd glad to combine more efforts to move it forward to 
>> standardization.
>>
>>  
>>
>> Bests,
>>
>> Victor 
>>
>> On Monday, January 22, 2024 at 5:24:25 PM UTC-5 Erik Anderson wrote:
>>
>> Is the ALPS draft being actively worked on?
>>
>>  
>>
>> Various teams at Microsoft that own web sites leveraging client hints 
>> have expressed interest in using it, but the lack of a finalized standard 
>> has significantly slowed conversations with the teams that own the server 
>> code that would need to add support first.
>>
>>  
>>
>> Are you looking for help in moving standardization forward?
>>
>>  
>>
>> *From:* Yoav Weiss (@Shopify)  
>> *Sent:* Monday, January 22, 2024 7:39 AM
>> *To:* Victor Tan 
>> *Cc:* blink-dev ; Chris Harrelson <
>> chri...@chromium.org>; David Benjamin ; Mike 
>> Taylor 
>> *Subject:* Re: [blink-dev] Re: Intent to Ship: New ALPS code point
>>
>>  
>>
>> Is the old code point defined somewhere? Would it be possible to add such 
>> a definition to one of the I-Ds? Or is this 

Re: [blink-dev] Request for Deprecation Trial : HTMLVideoElement-specific Prefixed Fullscreen API

[Mike Taylor]

LGTM3

On 2/2/24 1:03 AM, Domenic Denicola wrote:
LGTM2. Please be sure to update Chrome Status with the deprecation 
trial timelines and removal milestones so that data gets fed into the 
feature dashboard, beta blog posts, etc.


On Fri, Feb 2, 2024 at 7:35 AM Thomas Guilbert 
 wrote:


Thank you!

I will be adding an enterprise policy to re-enable the APIs if
necessary, as part of the enterprise review. Deprecating the
enterprise policy will become the new objective after the proper
amount of time has elapsed, before the code can be deleted for good.

I will keep updating this thread as I make it further in the
launch process.

On Thu, Feb 1, 2024 at 2:24 PM Philip Jägenstedt
 wrote:

Thank you Thomas!

As far as I'm aware that's all of the paperwork completed, so
LGTM1 to disable the APIs by default and at the same time
start a reverse origin trial to re-enable them for 6 months.
If you hear feedback requesting an extension towards the end
of those 6 months, please request an extension for another 6
months.

On Thu, Feb 1, 2024 at 12:43 AM Thomas Guilbert
 wrote:

Thanks for marking it for review!

I submitted a request to review this change to the
chromium enterprise mailing list.

Thanks,
Thomas

On Wed, Jan 31, 2024 at 1:08 PM Mike Taylor
 wrote:

Yep - seems that's the cause of confusion. In your
first email,
https://chromestatus.com/feature/5259513871466496 is
linked from the bottom, so our review tooling is
presenting that to us. But I've just flagged the new
one so it will show up as well.

thanks!

On 1/31/24 2:41 PM, Thomas Guilbert wrote:

I requested privacy/security/debuggability on the
video element fullscreen API deprecation feature

 last
week. Privacy and debuggability are approved, just
waiting on security.

Mike, are you talking about requesting those gates on
the original Prefixed Fullscreen API feature
?
I don't have edit rights on that Chrome status entry,
and upon closer look, it relates to
`webkitRequestFullscreen`, which is not covered by
this deprecation intent.

> [...] requesting enterprise signoff [...]
Is this a field on the chrome status entry? It
doesn't show up for me. Or is this about emailing the
list mentioned here

?

Thanks,
Thomas



On Wed, Jan 31, 2024 at 8:54 AM Philip Jägenstedt
 wrote:

Apologies in advance for excessive paperwork, but
can you also put
https://chromestatus.com/feature/5111638103687168
through the process, requesting enterprise
signoff in particular? Enterprise folks could
depend on this and might need to take some extra
action, and a "Feature deprecation" entry is the
only way we can flag that.

On Wed, Jan 31, 2024 at 5:44 PM Mike Taylor
 wrote:

Gentle reminder to follow up on requesting
privacy/security/debuggability approvals in
chromestatus (which is currently blocking LGTMs).

On Wednesday, January 24, 2024 at 7:23:28 AM
UTC-5 Mike Taylor wrote:

Would you mind requesting reviews for the
various gates (privacy, security,
debuggability) for an OT/DT in your
chromestatus entry?

On 1/19/24 10:43 PM, Thomas Guilbert wrote:



Contact emails

tguilb...@chromium.org


Explainer

None


Specification


https://fullscreen.spec.whatwg.org/#dom-document-fullscreenenabled


Summary

There was an attempt in 2014


to deprecate and remove the
 

Re: [blink-dev] Intent to Ship: 'pagereveal' event

[David Bokan]

On Friday, February 2, 2024 at 9:35:13 AM UTC-5 David Bokan wrote:

On Friday, February 2, 2024 at 1:18:42 AM UTC-5 Domenic Denicola wrote:

Can you un-tentative these tests?


Sure, will do this today! 


 Done.

-- 
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/3b2df66a-aadf-4c45-aa28-48c7344db9a0n%40chromium.org.

[blink-dev] Intent to Prototype and Ship: Standardized CSS zoom

['Yotam Hacohen' via blink-dev]

Contact emailsyo...@google.com

ExplainerNone

Specificationhttps://github.com/w3c/csswg-drafts/pull/9699

Design docs
https://docs.google.com/document/d/1AcnDShjT-kEuRaMchZPm5uaIgNZ4OiYtM4JI9qiV8Po/edit

Summary

Aligns the existing implementation of the previously non-standard CSS zoom
property to align with the new standard. This changes various JS APIs to
align with the spec (see design doc), change zoom to apply to iframes, and
change it to apply to all inherit all length properties (currently it only
changes inherited font-size)

Blink componentBlink>Paint


TAG reviewNone

TAG review statusPending

Risks

Interoperability and Compatibility

There is web compatibility risk for these changes. However, previous
research indicates broken content due to unexpected changes of the JS APIs
is very unlikely, since: * The changes to the JS API simply change the
coordinate space of the responses, not the syntax or what APIs are
available. * Most pages found during the research didn't appear to use CSS
zoom at all and the ones that did only relied on the visual effect, not JS
APIs. It's possible some pages will be broken by the changes to inherited
properties other than font-size, or applying zoom to sub-frames, but based
on previous research, those are very likely to be minor visual changes that
don't break fundamental user interaction with the site. None of the sites
reviewed contained iframes underneath a zoomed ancestor. We will use direct
outreach to avoid any broken features in Office 365 or the Gmail native
mobile app


*Gecko*: No signal Filed a standard position request:
https://github.com/mozilla/standards-positions/issues/977

*WebKit*: No signal Filed a standard position request:
https://github.com/WebKit/standards-positions/issues/311

*Web developers*: Positive (
https://docs.google.com/document/d/1cmbXpjAcXAht2ufi7bNKy-rbVNveqaf0UzeYg_DIMNA/edit#heading=h.6sz4u73bikbd)
Research collected as part of the previous attempt to remove CSS zoom
demonstrated several use cases.

*Other signals*:

WebView application risks

See Interoperability and Compatibility above


Debuggability

None

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

Is this feature fully tested by web-platform-tests

?Yes

All JS APIs affected by zoom are tested with the following wpt tests:
https://wpt.fyi/results/css/cssom-view/offsetTop-offsetLeft-with-zoom.html?label=master=experimental=cssom-view%2FoffsetTop-offsetLeft-with-zoom.html
https://wpt.fyi/results/css/cssom-view/client-props-zoom.html?label=master=experimental
https://wpt.fyi/results/css/cssom-view/getBoundingClientRect-zoom.html?label=master=experimental
https://wpt.fyi/results/css/cssom-view/getClientRects-zoom.html?label=master=experimental
https://wpt.fyi/results/css/cssom-view/scroll-zoom.html?label=master=experimental
https://wpt.fyi/results/intersection-observer/zoom-scaled-target.html?label=experimental=master

Flag name on chrome://flagsStandardizedBrowserZoom

Finch feature nameStandardizedBrowserZoom

Requires code in //chrome?False

Sample linkshttps://jsbin.com/wasafateko/edit?html,css,js,output

Estimated milestones

No milestones specified

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

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/CAAOtuiYKjC9Gt%2BgXwWNT_hJneBMa053RizCX5Xj5p_07CVLXkA%40mail.gmail.com.

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

[Mason Freed]

On Fri, Feb 2, 2024 at 9:37 AM Vladimir Levin  wrote:

> It's good to know that QuillJS seems to be addressing their issue in 2.0,
> although the currently published stable version is still 1.x. I just wanted
> to verify the timeline for disabling these features. The trial is for
> 124-134 and the feature will be turned off by default in 127. Sounds
> reasonable to me, but I'd encourage checking whether QuillJS ships to 2.0
> in the 127 timeframe :)
>

I 100% agree. I have been trying to follow up
 with
that team to see what the timeline looks like. But more importantly, I did
my own testing and I can't see any negative effects on QuillJS pre-2.0 with
Mutation Events disabled. So my hope is that even if the timeline doesn't
line up, things might be "ok".

That's another important thing: I've been running locally with Mutation
Events disabled completely for about 4 months now, and I have yet to notice
anything broken. That's anecdotal, but makes me feel a bit better that
perhaps even if there is usage on a site, it might not be critical or
noticable.

Thanks,
Mason



>
>>
>>>  The npm package you listed, for example, would use the actual events if
>>> available, so sites using that polyfill would also count towards the event
>>> usage if the browser supports those even though that's "safe", right?
>>>
>>
>> This is an excellent point that I hadn't thought of. I'm going to modify
>> the polyfill right now to *always* run. That way polyfilled usage will no
>> longer be counted. I'm used to writing polyfills for features that are
>> getting *added*, where you want to avoid using the polyfill when the
>> feature is supported. This is the opposite.
>>
>> Thanks,
>> Mason
>>
>>
>>

 *Gecko*: Positive (
 https://github.com/mozilla/standards-positions/issues/807) "very
 strong positive position"

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

 *Web developers*: No signals

 *Other signals*:

 WebView application risks

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

 None


 Goals for experimentation



 Ongoing technical constraints



 Debuggability



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

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

 Flag name on chrome://flags

 Finch feature nameNone

 Non-finch justificationNone

 Requires code in //chrome?False

 Tracking bughttps://crbug.com/1446498

 Estimated milestones
 Shipping on desktop 115
 OriginTrial desktop last 134
 OriginTrial desktop first 124
 Shipping on Android 115
 OriginTrial Android last 134
 OriginTrial Android first 124
 Shipping on WebView 115
 OriginTrial webView last 134
 OriginTrial webView first 124

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

 Links to previous Intent discussionsIntent to Experiment:
 https://groups.google.com/a/chromium.org/g/blink-dev/c/qDsKRU-cQ_4/m/isA1mZ_aAAAJ


 This intent message was generated by Chrome Platform Status
 .

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

>>>

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

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

['Vladimir Levin' via blink-dev]

On Thu, Feb 1, 2024 at 6:30 PM Mason Freed  wrote:

>
> On Thu, Feb 1, 2024 at 7:12 AM Vladimir Levin  wrote:
>
>> This is very exciting! Thank you for working on this.
>>
>
> Thanks!
>
>
>> Do you know whether the existing usage is feature checked? 1.58% seems
>> very high, but if it's feature checked and fallback is something like
>> mutation observer, then it would be a lot more safe imho. Also, do you have
>> a sense of where the usage is coming from (a few large frameworks vs a ton
>> of smaller sites)?
>>
>
> Unfortunately, I haven't seen a lot of feature checking around mutation
> events directly. I have definitely seen feature checks on MutationObserver
> that then avoids trying to use mutation events. But obviously those aren't
> part of the use counter data, since they don't attach mutation
> event listeners.
>
> I've been looking into UKM data to see if I can suss out any large usage
> patterns. I've found a few, e.g. QuillJS
> , which contribute a
> significant chunk of usage to many sites. Thankfully in the cases I've
> seen, the (large) deprecation warnings I've added to Chrome seem to be doing
> their thing
> .
> My hope is that direct outreach (which I've done in a few cases), heavy
> warnings, and eventually the start of the removal effort (plus this OT to
> give sites an extension) will nudge the remaining users to migrate.
>

It's good to know that QuillJS seems to be addressing their issue in 2.0,
although the currently published stable version is still 1.x. I just wanted
to verify the timeline for disabling these features. The trial is for
124-134 and the feature will be turned off by default in 127. Sounds
reasonable to me, but I'd encourage checking whether QuillJS ships to 2.0
in the 127 timeframe :)


>
>>  The npm package you listed, for example, would use the actual events if
>> available, so sites using that polyfill would also count towards the event
>> usage if the browser supports those even though that's "safe", right?
>>
>
> This is an excellent point that I hadn't thought of. I'm going to modify
> the polyfill right now to *always* run. That way polyfilled usage will no
> longer be counted. I'm used to writing polyfills for features that are
> getting *added*, where you want to avoid using the polyfill when the
> feature is supported. This is the opposite.
>
> Thanks,
> Mason
>
>
>
>>>
>>> *Gecko*: Positive (
>>> https://github.com/mozilla/standards-positions/issues/807) "very strong
>>> positive position"
>>>
>>> *WebKit*: No signal (
>>> https://github.com/WebKit/standards-positions/issues/192)
>>>
>>> *Web developers*: No signals
>>>
>>> *Other signals*:
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> None
>>>
>>>
>>> Goals for experimentation
>>>
>>>
>>>
>>> Ongoing technical constraints
>>>
>>>
>>>
>>> Debuggability
>>>
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, ChromeOS, Android, and Android WebView)?Yes
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?No
>>>
>>> Flag name on chrome://flags
>>>
>>> Finch feature nameNone
>>>
>>> Non-finch justificationNone
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://crbug.com/1446498
>>>
>>> Estimated milestones
>>> Shipping on desktop 115
>>> OriginTrial desktop last 134
>>> OriginTrial desktop first 124
>>> Shipping on Android 115
>>> OriginTrial Android last 134
>>> OriginTrial Android first 124
>>> Shipping on WebView 115
>>> OriginTrial webView last 134
>>> OriginTrial webView first 124
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5083947249172480
>>>
>>> Links to previous Intent discussionsIntent to Experiment:
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/qDsKRU-cQ_4/m/isA1mZ_aAAAJ
>>>
>>>
>>> This intent message was generated by Chrome Platform Status
>>> .
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDjevtANjMn1NUK83UGyJyv4HrLCFkjs9fhL6UVov_uAkA%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 

Re: [blink-dev] Intent to Ship: 'pagereveal' event

[Christian Biesinger]

On Thu, Feb 1, 2024 at 4:53 PM David Bokan  wrote:

> Contact emailsbo...@chromium.org, khushalsa...@chromium.org,
> nrosent...@chromium.org, vmp...@chromium.org
>
> Explainer
> https://github.com/WICG/view-transitions/blob/main/cross-doc-explainer.md
>
> Specificationhttps://html.spec.whatwg.org/#reveal
>
> Design docs
> https://github.com/WICG/view-transitions/blob/main/cross-doc-explainer.md
>
> Summary
>
> The `pagereveal` event is fired on a Document's window object at the first
> render opportunity after a Document is: initially loaded, restored from the
> back-forward cache, or activated from a prerender. It can be used by a page
> author to set up a page entry UX - such as a ViewTransition from a previous
> state. This feature is split out from the larger Cross Document View
> Transition project.
>

If someone else was wondering, the explainer does say:
"Note that this event is different from pageshow
 as a newly
initialized document fires pageshow is only once the document is fully
loaded."

-- 
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/CAPTJ0XFV-3CPS9jEdoYF3GGXU3rwZdhefr%2Bs%3DdiScFpaZ_wqTQ%40mail.gmail.com.

Re: [blink-dev] PSA: Browser text zoom on Android will now work like it does on desktop

['Mark Schillaci' via blink-dev]

Just to loop back on this - Page Zoom does not affect WebView. The custom
text zoom of WebView was not changed.

Sorry for the delay :p.

On Wed, Aug 2, 2023 at 11:14 AM Torne (Richard Coles) 
wrote:

> This mentions it's supported in Android WebView, but WebView has always
> used the font size specified in the OS to scale text specifically (*not* to
> scale CSS pixels):
> https://source.chromium.org/chromium/chromium/src/+/main:android_webview/java/src/org/chromium/android_webview/AwSettings.java;l=296;drc=334d01268df246e959b238956ab956413562edfb
>
> Does this change actually affect WebView? If so, how? If it ends up
> stacking with the text zoom we are already doing then the results may not
> be desirable.
>
> On Wed, 2 Aug 2023 at 13:27, 'Jonathan Bernal' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails
>>
>> mschill...@google.com, rayjonath...@google.com, p...@google.com,
>> ikilpatr...@google.com, aldi...@google.com, chris...@google.com
>>
>>
>> Explainer
>>
>>
>> https://docs.google.com/document/d/1vRVRJFaY3TWRFkrKvLhhiBemTfFxUzI_co4YZq_kB0E/edit
>>
>>
>> Summary
>>
>> Browser text zoom on Android will now work like it does on desktop. See
>> https://blog.google/products/android/new-android-features-february-2023/
>> for a blog post about it. The default rendered zoom value of a given page
>> will transparently account for a user’s OS-level font size setting. This
>> means that any user on Android who has a non-default OS-level font size
>> setting (~40% of users), will use a non-100% zoom on Android Chrome by
>> default. This feature is currently released to 10% of stable users.
>>
>>
>> How to opt into the feature:
>>
>>1.
>>
>>Go to chrome://flags
>>2.
>>
>>Search for "Accessibility Page Zoom”
>>3.
>>
>>Use the dropdown box to switch the feature from “Default” to “Enabled”
>>4.
>>
>>Restart Chrome (force quit)
>>
>>
>> How to use the feature:
>> https://support.google.com/chrome/answer/96810?co=GENIE.Platform%3DAndroid=1
>> Blink component
>>
>> Compositor
>>
>>
>> Risks
>>
>>-
>>
>>This will change the overall distribution of window.innerWidth values
>>a website sees, which may be unexpected.
>>-
>>
>>Don't currently have any provision for opting out specific origins
>>(eg. overriding the default zoom level back to 100%) if breakage is
>>discovered.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> Android and Android WebView
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> No
>>
>>
>> Flag name
>>
>> Accessibility Page Zoom
>> Requires code in //chrome?
>>
>> Yes
>>
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=645717
>>
>>
>> Launch bug
>>
>> https://launch.corp.google.com/launch/4206588 (sorry, Googlers only)
>>
>>
>> Estimated milestones
>>
>> M113
>> Link to entry on the Chrome Platform Status
>>
>> N/A
>>
>>
>> Links to previous Intent discussions
>>
>> N/A
>>
>> --
>> 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/CA%2B8nQZ6JJHyUXC5fofsnSW2gAi64Xqe7WHus94FqQs%3DFMS1qOA%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/CAK9iZJj_-VGd_nyLFc2becK9UjbqR5pAn%3D6hvNNHOYHXfZofQQ%40mail.gmail.com.

[blink-dev] Intent to Prototype: Web Monetization

[Alexander Surkov]

   Contact emails

asur...@igalia.com


   Explainer

https://webmonetization.org/docs 


   High Level Overview

High Level Web Monetization Overview 




   Specification

https://webmonetization.org/specification/ 




   Summary

Implement the Web Monetization spec. Web Monetization is a web 
technology that enables website owners to receive micro payments from 
users as they interact with their content. It provides a way for content 
creators and website owners to be compensated for their work without 
relying solely on ads or subscriptions. Notably, Web Monetization offers 
two unique features—small payments and no user interaction—users are 
paying/tipping for the content while they consume it. It extends the 
HTML  element by introducing rel="monetization". When this element 
is incorporated into a web page, it signifies the website's support for 
web monetization. If a user has their wallet set up for a particular 
website, their browser will automatically start a web monetization 
session, enabling direct payments from the user to the website.




   Blink component

Blink>Payments 




   Motivation

Web monetization offers a new revenue model for content creators and 
website owners, allowing them to earn from their work while users 
consume their content. It also facilitates voluntary user contributions, 
such as tips, directly rewarding the creators for the value their 
content provides.



   Initial public proposal

None


   TAG review

None


   TAG review status

Pending


   Risks



   Interoperability and Compatibility

None



Gecko: No signal


WebKit: No signal


Web developers: a fraction of a percent of all web pages have already 
been configured to use the feature in anticipation of web/browser 
support, according to metrics 
. 
There used to be a different way to set up web monetization on a web 
site by using HTML:meta tag, which achieved 0.03% adoption 
on 
the web.



Other signals:


   WebView application risks

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


None



   Debuggability

None



   Is this feature fully tested byweb-platform-tests
   
?

No


   Flag name on chrome://flags

WebMonetization in runtime_enabled_features.json5.


   Finch feature name

None


   Non-finch justification

None


   Requires code in //chrome?

False


   Estimated milestones

M127 



   Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4917148755689472 




This intent message was generated byChrome 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/d91487a5-108c-46e7-accd-d44b734a0b34%40igalia.com.

[blink-dev] Intent to Prototype and Ship: Private network access checks for navigation requests: warning-only mode

[Jonathan Hao]

Contact emailsp...@chromium.org

Explainer
https://github.com/WICG/private-network-access/blob/main/explainer.md

Specificationhttps://wicg.github.io/private-network-access

Design docs
https://docs.google.com/document/d/1UqkJsc2VZ4bXmZkVxh-EPyBFEtdxX9p2zX4sxzAj754/edit?usp=sharing=0-7cfhrTo57AElxA6M9EVScg

Summary

Before a website A navigates to another site B in the user's private
network, this feature does the following:
1. Checks whether the request has been initiated from a secure context
2. Sends a preflight request, and checks whether B responds with a header
that allows private network access.

The above checks are made to protect the user's private network.  There are
already features for subresources and workers, but this one is for
navigation requests specifically.


Since this feature is the "warning-only" mode, we do not fail the requests
if any of the checks fails.  Instead, a warning will be shown in the
DevTools, to help developers prepare for the coming enforcement.


Blink componentBlink>SecurityFeature>CORS>PrivateNetworkAccess


Motivation

To prevent malicious websites from pivoting through the user agent's
network position to attack devices and services which reasonably assumed
they were unreachable from the Internet at large, by virtue of residing on
the user’s local intranet or the user's machine.


Initial public proposal
https://discourse.wicg.io/t/transfer-cors-rfc1918-and-hsts-priming-to-wicg/1726

TAG reviewhttps://github.com/w3ctag/design-reviews/issues/572

TAG review statusIssues addressed

Risks


Interoperability and Compatibility

Since we don't enforce the checks and only show warnings, there isn't any
compatibility risks on the client side. On the server side, it shouldn't
pose any risk either as the server can ignore the preflight requests.


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

*WebKit*: Positive (https://github.com/WebKit/standards-positions/issues/163)
Safari disagrees with the spec name and header names, but still overall
positive.

*Web developers*: Mixed signals Anecdotal evidence so far suggests that
most web developers are OK with this new requirement, though some do not
control the target endpoints and would be negatively impacted.

*Other signals*:

Security

This change aims to be security-positive, preventing CSRF attacks against
soft and juicy targets such as router admin interfaces. DNS rebinding
threats were of particular concern during the design of this feature:
https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit#heading=h.189j5gnadts9


WebView application risks

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

None


Debuggability

Relevant information (client and resource IP address space) is already
piped into the DevTools network panel. Deprecation warnings and errors will
be surfaced in the DevTools issues panel explaining the problem when it
arises.


Is this feature fully tested by web-platform-tests

?Yes

https://wpt.fyi/results/fetch/private-network-access?q=fetch%2Fprivate-network-access_id=5090117631868928_id=6245938696814592_id=5769215446351872_id=5679819023974400


Flag name on chrome://flagsNone

Finch feature namePrivateNetworkAccessForNavigations,
PrivateNetworkAccessForNavigationsWarningOnly

Requires code in //chrome?False

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

Estimated milestones
Shipping on desktop 124
Shipping on Android 124

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

This intent message was generated by Chrome Platform Status
.

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

Re: [blink-dev] Intent to Ship: 'pagereveal' event

[David Bokan]

On Friday, February 2, 2024 at 1:18:42 AM UTC-5 Domenic Denicola wrote:

Can you un-tentative these tests?


Sure, will do this today! 

-- 
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/6b4280fe-cd1b-46a4-9de0-bd211e137992n%40chromium.org.

[blink-dev] Intent to Ship: Cross App and Web Attribution Measurement

[Nan Lin]

Contact emails

lin...@chromium.org, johni...@chromium.org

Explainer

Cross App and Web Attribution Measurement


Specification

https://wicg.github.io/attribution-reporting-api/#cross-app-and-web

Summary

This is an extension to the Attribution Reporting API
 that has already
shipped.

Currently, the Attribution Reporting API
 supports attributing
events within a single browser instance. This proposal expands the scope of
attribution to allow attributing conversions that happen on the web to
events that happen off the browser on the same device, within other
applications such as mobile applications, or vice-versa.

The proposal here leverages OS-level support for attribution. In
particular, it gives the developer an option to allow events on the mobile
web to be delegated to Android’s Privacy Sandbox
,
although support for other platforms could also be implemented in the
future.

Note that with this proposal new features shipped by the OS may be
implicitly supported without web API changes. For example, Android may ship
support for new registration fields not supported in the existing
Attribution Reporting API. Once a developer elects to delegate events to
the OS, there is no way web-visible to introspect this.


Blink component

Internals > AttributionReporting



TAG review

https://github.com/w3ctag/design-reviews/issues/724#issuecomment-1908353938

TAG review status

Pending

Risks

 Interoperability and Compatibility

See the Attribution Reporting API I2S
 for
information on the other general measurement proposals in this space.

Private Click Measurement in Safari supports app to web measurement (
https://webkit.org/blog/11529/introducing-private-click-measurement-pcm/#:~:text=App%2Dto%2DWeb%20Click%20Measurement).
On iOS, some web to app measurement is supported via SKAdNetwork (
https://developer.apple.com/documentation/skadnetworkforwebads). There is
currently no interop between these proposals and the cross app web API for
Attribution Reporting.

Gecko: No official position (
https://github.com/mozilla/standards-positions/issues/791#issuecomment-1908359889
)

WebKit: No official position (
https://github.com/WebKit/standards-positions/issues/307)

Web developers: Positive. Some testers are currently implementing and
providing feedback and more usage expected in 2024. Developers have
requested expansion of coverage of this feature (example:
https://github.com/WICG/attribution-reporting-api/issues/1125).

Debuggability

The Attribution Reporting API utilizes DevTools and an internal page
(chrome://attribution-internals) to facilitate testing and integration. The
debugging information for OS registrations from Chrome will be displayed in
DevTools and the internal page as well.


Additionally, debug reports

are supported for OS registrations. The Attribution Reporting API for
Android also implements a similar debugging reports framework

to facilitate cross app and web testing.


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

The Attribution-Reporting-Support header is supported on all platforms.
Today, only Android offers a native Attribution Reporting API, so the
ability to register with the OS is only supported on those platforms
(Android and Android WebView).

Is this feature fully tested by web-platform-tests

?

The Attribution-Reporting-Support header is tested by web platform tests,
but the integration with OS is not as web platform tests are not supported
for Android.

Requires code in //chrome?

False

Estimated milestones

Chrome 123

Launch bug

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

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4994430156668928

Links to previous Intent discussions

Cross App and Web Attribution Measurement Intent to Experiment


Cross App and Web Attribution Measurement Intent to Extend Experiment


Attribution Reporting API Intent to Ship

Re: [blink-dev] Intent to Ship: Clipboard API: Svg

['Thomas Steiner' via blink-dev]

Regarding developer interest, there's definitely some false positives in
there, but a quick GitHub search

demonstrates
that quite a few developers attempt to write `image/svg+xml` onto the
clipboard. (Including my own app, SVGcode

).

On Thu, Feb 1, 2024 at 11:45 PM Chris Harrelson 
wrote:

>
>
> On Thu, Feb 1, 2024 at 2:43 PM Evan Stade  wrote:
>
>> My understanding is that SVG support got lost in a personnel shuffle and
>> that we would like to ship it in theory. This comment
>>  has
>> some more context, the takeaways being that:
>>
>>- we need to be more sure of the implementation
>>- we need partner confirmation, i.e. addressing "LGTM3 with the
>>caveat that we should only flip this flag to ship if big customers like
>>Sean's team are able to use this successfully to minimally cover their
>>needs."
>>
>> From my perspective the LGTMs are no longer caveated. I think there is
> enough evidence of demand to just do it.
>
>
>> No one has done that outreach as of yet.
>>
>> -- Evan Stade
>>
>>
>> On Thu, Feb 1, 2024 at 2:35 PM Chris Harrelson 
>> wrote:
>>
>>> Hi,
>>>
>>> From my perspective, you still have 3 LGTMs to ship from the API owners.
>>> However, please fill out the cross-functional reviews for privacy,
>>> security, etc that have been added to the process since this intent was
>>> created. If that doesn't seem possible with your existing chromestatus
>>> entry, let me know or just create a new one and I'll LGTM it after those
>>> reviews have started.
>>>
>>> On Thu, Feb 1, 2024 at 1:38 PM Anupam Snigdha <
>>> snianu.micros...@gmail.com> wrote:
>>>
 Thanks Chris!
 cc'ing estade@.
 I think Darwin and Victor are not working on clipboard anymore so this
 feature was stalled.

 Recently another bug was opened (
 https://bugs.chromium.org/p/chromium/issues/detail?id=1410321) where
 support for copying/pasting svg images is needed. More discussions:
 https://boxy-svg.com/ideas/268/paste-images-from-the-system-clipboard#comment-2313
 Since this I2S was LGTM'd with the caveat that Adobe is able to use
 this format, and I'm not sure if there is any update on that, is it
 possible to reconsider this I2S if there are other customers like Keynote
 and Cleanshot X interested in this feature?
 cc'ing Josh as well to see if there were any internal discussions with
 Adobe for SVG image support. Thanks!

 -Anupam

 On Mon, Nov 13, 2023 at 4:50 PM Chris Harrelson 
 wrote:

> Thanks for the interest! I agree it would be good to ship this if
> possible.
>
> On Tue, Oct 31, 2023 at 1:22 AM 一丝  wrote:
>
>> Unfortunately, three LGTMs obtained here did not ship. Can anyone
>> re-continue this process?
>>
>> With Keynote 13.1 supporting the SVG format, this API seems to be the
>> only way to copy and paste SVGs into Keynote in a browser.
>
>
> Could you test with the experimental-web-platform-features chrome flag
> turned on, and see if it works as intended for copy and paste from 
> Keynote?
>
>
>>
>> 在2021年8月20日星期五 UTC+8 03:15:56 写道：
>>
>>> LGTM3 with the caveat that we should only flip this flag to ship if
>>> big customers like Sean's team are able to use this successfully to
>>> minimally cover their needs.
>>>
>>> On Thursday, August 19, 2021 at 11:57:00 AM UTC-7 Chris Harrelson
>>> wrote:
>>>
 LGTM2

 On Thu, Aug 19, 2021 at 11:46 AM Mike West 
 wrote:

>>> LGTM1.
>
> I think it's important that we address the TAG's concerns about
> gesture requirements and other mechanisms which might reduce the 
> surprise
> associated with some uses of the clipboard API, but I agree with 
> Darwin
> that shipping SVG support doesn't need to block on that conversation. 
> That
> said, I'd encourage y'all to engage more closely with those questions.
> Marijn, you and +Victor Costan are on an internal thread on that
> topic that we should follow up on.
>
> Regarding style, this intent is the most conservative approach to
> sanitization, which has been approved by the security team. Ideally, 
> we
> could find a way to allow style safely via the sanitization API work 
> that's
> underway separately, as Anne suggested on Mozilla's standards
> position thread
> .
> I also note that Apple's response on
>