Re: [blink-dev] Intent to Experiment: Unrestricted access to performance.measureUserAgentSpecificMemory()

[Yoav Weiss]

Great! My LGTM stands, but please wait for the relevant reviews to complete
before starting the experiment.

On Tue, Oct 17, 2023 at 6:43 PM Lutz Vahl  wrote:

> Clarified with Jason offline. Thanks again!
> Reviews are triggered now. PTAL.
>
> On Tue, Oct 17, 2023 at 8:44 AM Yoav Weiss  wrote:
>
>>
>>
>> On Tue, Oct 17, 2023 at 4:45 PM Lutz Vahl  wrote:
>>
>>> I've adjusted the stage to 'Origin Trial' and added the OT milestones.
>>> Does this trigger the relevant reviews?
>>>
>>
>> It does not.. +Jason Robbins  - can you assist?
>>
>>
>>>
>>> On Tue, Oct 17, 2023 at 4:35 AM Yoav Weiss 
>>> wrote:
>>>
 Oops! Can you start the reviews for privacy, security and debuggability
 in the new status entry?

 On Tuesday, October 17, 2023 at 1:34:44 PM UTC+2 Yoav Weiss wrote:

> LGTM to experiment M120 to M121
>
> On Monday, October 16, 2023 at 2:25:00 PM UTC+2 Michael Lippautz wrote:
>
>> On Fri, Oct 13, 2023 at 3:58 PM Michael Lippautz <
>> mlippa...@chromium.org> wrote:
>>
>>> Thanks!
>>>
>>> On Fri, Oct 13, 2023 at 10:52 AM Yoav Weiss 
>>> wrote:
>>>
 This is exciting! Thanks for working on this!!

 On Fri, Oct 13, 2023 at 10:42 AM Michael Lippautz <
 mlippa...@chromium.org> wrote:

> Contact emails
>
> v...@chromium.org, mlippa...@chromium.org
>
> Explainer
>
> https://github.com/WICG/performance-measure-memory
>
> Specification
>
> https://github.com/WICG/performance-measure-memory
>
> Design docs
>
> Original docs:
>
> https://web.dev/monitor-total-page-memory-usage
>
>
> https://github.com/WICG/performance-measure-memory/blob/master/ORIGIN_TRIAL.md
>
> Summary
>
> performance.measureUserAgentSpecificMemory() is specified to only
> be available in cross-origin isolated environments (behind COOP/COEP).
>
> This is a request for removing the COOP/COEP restriction for a
> limited amount of time from M120 to M121. This is to allow partners 
> that
> adopted WasmGC on WebWorkers to perform regression tests in the wild 
> as
> well as measure their impact. These partners are not fully ready to 
> deploy
> COOP/COEP.
>

 Do you want to experiment with removing the API's restrictions
 generally or to sites that opt-in to this? (Through an OT flag, I'm
 assuming)

>>>
>>> We don't want this generally but through an OT for a limited time.
>>>
>>>

> Note that performance.memory (legacy API) cannot be used for this
> purpose as it was never enabled on workers.
>
> The timeline has been adjusted to match the OT for
> SharedArrayBuffer on non-isolated pages.
>

 IIUC the restrictions on measureUASpecificMemory and
 SharedArrayBuffer are similar but for different reasons. Would we have 
 a
 separate OT token for this?

>>>
>>> We would want a separate OT token.  We already reached out to a few
>>> security folks which would want us to align the times and make it as 
>>> short
>>> as possible (for good reasons). The unrestricted SAB OT also has issues
>>> with privacy which is why we should align the OT times.
>>>
>>>


>
> Blink component
>
> Blink>PerformanceAPIs
> 
>
> Search tags
>
> JavaScript memory
> ,
> crossOriginIsolated
> ,
> performance.measureMemory()
> 
>
> TAG review
>
> -
>
> TAG review status
>
> -
>
> Chromium Trial Name
>
> MeasureMemory
>
> Link to origin trial feedback summary
>
> -
>
> Origin Trial documentation link
>
> -
>
> Risks
>
> This area is unchanged from the original launch.
>
> Interoperability and Compatibility
>
> The actual memory usage of a web page is not comparable across
> browsers. The granularity of memory usage breakdown will differ across
> browsers.
>
>
> Gecko: Under consideration (
> https://github.com/mozilla/standards-positions/issues/281)
>
> WebKit: No signal (
> https://lists.webkit.org/pipermail/webkit-dev/2020-April/

Re: [blink-dev] Intent to Re-implement and Ship: CSS Font Loading API - FontFaceSet: check() method

[Yoav Weiss]

LGTM3

Thanks for clarifying. Please file implementation bugs for these failures,
if ones don't already exist.

On Tue, Oct 17, 2023 at 11:16 PM ChangSeok Oh  wrote:

> Hi Yoav,
>
> Yes, Safari and Firefox support the check method [1], and I confirmed it.
> The test failures are due to other factors (e.g., pixel mismatches), not
> FontFaceSet::check(). Sub-tests on the check() method have passed.
>
> [1] https://caniuse.com/mdn-api_fontfaceset_check
>
> --
> ChangSeok
>
> > On Oct 17, 2023, at 4:29 AM, Yoav Weiss  wrote:
> >
> >
> >
> > On Mon, Oct 16, 2023 at 8:15 PM Mike Taylor 
> wrote:
> > LGTM2
> > On 10/16/23 1:35 PM, Alex Russell wrote:
> >> LGTM1
> >>
> >> On Sun, Oct 15, 2023 at 1:01 PM ChangSeok Oh 
> wrote:
> >> Contact emails
> >> changseok...@bytedance.com, shivami...@gmail.com
> >>
> >> Specification
> >> https://drafts.csswg.org/css-font-loading/#font-face-set-check
> >>
> >> Summary
> >> The FontFaceSet's check() function verifies whether it's possible to
> display text using the specified fonts without attempting to utilize fonts
> in the FontFaceSet that have not completed loading. This allows users to
> safely employ the font without later triggering a font replacement (i.e.,
> font swap).
> >>
> >> Motivation
> >> While having a review [1] to fix issue 1416842 [2], I heard that an
> "Intent to ship" email is required since the fix changes Blink's behavior.
> The font loading API was updated, so we need to update our implementation
> in conformance with the spec.
> >>
> >> [1] https://chromium-review.googlesource.com/c/chromium/src/+/4913179
> >> [2] https://crbug.com/1416842
> >>
> >> Blink component
> >> Blink>Fonts
> >>
> >> Search tags
> >> CSS, Font, Loading, FontFaceSet, check
> >>
> >> TAG review
> >> None
> >>
> >> TAG review status
> >> Not applicable
> >>
> >> Risks
> >>
> >> Interoperability and Compatibility
> >> The current behavior of Blink does neither follow the updated spec nor
> match other engines' behavior. This proposal aims at fixing it.
> https://github.com/w3c/csswg-drafts/issues/5744
> >>
> >> Gecko: Shipped/Shipping (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1252821)
> >>
> >> WebKit: Shipped/Shipping (
> https://bugs.webkit.org/show_bug.cgi?id=156035
> >
> > I see Safari failing both WPTs you state below and Firefox fails one of
> them. Are you sure they are shipping it?
> >>
> >>
> >>
> >> Web developers: No signals
> >>
> >> Other signals:
> >>
> >> WebView application risks
> >> Does this intent deprecate or change behavior of existing APIs, such
> that it has potentially high risk for Android WebView-based applications?
> >> None
> >>
> >> Debuggability
> >> None
> >>
> >> Will this feature be supported on all six Blink platforms (Windows,
> Mac, Linux, Chrome OS, Android, and Android WebView)?
> >> Yes
> >>
> >> Is this feature fully tested by web-platform-tests?Yes
> >> The following WPT tests cover this feature. *
> css/css-fonts/fallback-remote-to-data-url.html *
> css/css-fonts/fallback-url-to-local.html
> >>
> >> 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=1416842
> >>
> >> Estimated milestones
> >> Shipping on desktop
> >> 120
> >> Shipping on Android
> >> 120
> >> Shipping on WebView
> >> 120
> >> Shipping on WebView
> >> 120
> >>
> >> Anticipated spec changes
> >> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project for the feature specification) whose resolution may
> introduce web compat/interop risk (e.g., changing to naming or structure of
> the API in a non-backward-compatible way).
> >> None
> >>
> >> Link to entry on the Chrome Platform Status
> >> https://chromestatus.com/feature/5174086494060544
> >>
> >> 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/f1705c1e-cf65-4c2e-bfe2-3ee3b4fb12d1n%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/CAA44PQj9Q67soyyTMG_eP_2PUPyRNEHh63HXbcbA5TT0mGEe3g%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 receivin

[blink-dev] Android shared workers

[Rik Cabanier]

One of our users reported that sharedworkers weren't working in the browser.
After investigating it looks like they were never supported on Android but 
it seems that they are supported everywhere else, including mobile Safari.
Reading https://monorail-prod.appspot.com/p/chromium/issues/detail?id=154571, 
it seems there was a concern that too many sharedworkers would exhaust 
system resources. Is that still a concern 10 years later?

-- 
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/34528104-dca4-4a21-b376-013bd393dfc1n%40chromium.org.

Re: [blink-dev] Android shared workers

[Ben Kelly]

FWIW, chrome on android is the last holdout on shared workers.  Safari on
ios supports it.  It would be nice if this could be prioritized.

On Wed, Oct 18, 2023 at 9:44 AM Rik Cabanier  wrote:

> One of our users reported that sharedworkers weren't working in the
> browser.
> After investigating it looks like they were never supported on Android but
> it seems that they are supported everywhere else, including mobile Safari.
> Reading
> https://monorail-prod.appspot.com/p/chromium/issues/detail?id=154571, it
> seems there was a concern that too many sharedworkers would exhaust system
> resources. Is that still a concern 10 years later?
>
> --
> 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/34528104-dca4-4a21-b376-013bd393dfc1n%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/CAK7rkMjH%2BV42hygYZTH6f9CBj4nfkk4W4rQuaXY84d-r%2BX%3DOmg%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: Async Clipboard API: Read unsanitized HTML and write well-formed HTML format.

[Evan Stade]

Hi Anupam,

I think this feature is now scoped just to the read side of the equation,
is that correct? Could you update the Chrome status entry
 text
to remove references to writing to avoid confusion?

-- Evan Stade


On Fri, Oct 6, 2023 at 10:31 AM Anupam Snigdha  wrote:

> The I2S thread was incorrectly merged into another I2S that I sent for a
> completely different feature. I'm creating a new thread and merging
> replies. Sorry for the inconvenience.
>
> As the author of the web custom formats article
> ,
> just for me to better understand: the problem is that the clipboard gets
> populated with `text/html` by random (web or native) apps. If the clipboard
> were populated from the start with `web text/html`, the contents could be
> read unsanitized, even without this new parameter. So this new parameter is
> the escape hatch that developers can use via
> `navigator.clipboard.read({unsanitized: ["text/html"]})`.
>
> So, the problem is that, for sites like Excel Online, they aren't sure
> where the user is going to paste, so they always have to produce both 'web
> text/html' and 'text/html'. That way if an app doesn't have support for web
> custom format, then they can use the native HTML format. Same thing for
> native apps that produce a web custom format.
> There are also legacy native apps (old Office versions that are used by
> Enterprises) that don't have support for the new web custom format, so the
> site has to produce the standard HTML format for those apps as well.
> But you are right that if both source and target apps support web custom
> format, then it can be used to access unsanitized HTML content.
>
> An immediate question that I ask myself is whether this mechanism could be
> expanded to other values than just `"text/html"`.
>
> Currently we are focusing on the standard HTML format to better align with
> the DataTransfer APIs. In theory you could add support for other built-in
> formats as well, but the main intent here is to produce similar fidelity of
> HTML format so sites that use DataTransfer APIs to read HTML do not
> experience any regression when they move over to async clipboard API for
> copy-paste operations.
>
> Here is a document where I described the regressions and impact on the
> apps when sanitization is performed:
> https://docs.google.com/document/d/1nLny6t3w0u9yxEzusgFJSj-D6DZmDIAzkr1DdgWcZXA/edit?usp=sharing
>
> Some native apps that I surveyed for impact of this new proposal:
> https://docs.google.com/document/d/1O2vtCS23nB_6aJy7_xcdaWKw7TtqYm0fERzEjtLyv5M/edit?usp=sharing
>
> FWIW, this demo was initially a bit misleading, since I expected "some
> text" to be on the clipboard, or whatever I put into the `contenteditable`
> box, but it's hardcoded. Maybe remove the box.
>
> Oops, sorry about that. Copy-paste error 🙂 I fixed it now.
>
> Please let me know if you have any questions!
>
> Thanks,
> Anupam
> --
> *From:* Thomas Steiner 
> *Sent:* Friday, October 6, 2023 2:54 AM
> *To:* Anupam Snigdha 
> *Cc:* blink-dev@chromium.org ; Sanket Joshi
> (EDGE) ; Evan Stade ;
> jsb...@google.com ; Ana Sollano Kim <
> ana.soll...@microsoft.com>
> *Subject:* [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: Async Clipboard
> API: Read unsanitized HTML and write well-formed HTML format.
>
>
> Adoption expectation
> Excel online is ready to use this API. They are trying to move away from
> DataTransfer APIs and use Async clipboard APIs where web custom format is
> supported along with other benefits from async usage.
>
> Adoption plan
> Support for async clipboard API and web custom format is already in inner
> rings, so once this gets added to the clipboard API, Excel would be ready
> to use it right away.
>
>
> As the author of the web custom formats article
> ,
> just for me to better understand: the problem is that the clipboard gets
> populated with `text/html` by random (web or native) apps. If the clipboard
> were populated from the start with `web text/html`, the contents could be
> read unsanitized, even without this new parameter. So this new parameter is
> the escape hatch that developers can use via
> `navigator.clipboard.read({unsanitized: ["text/html"]})`.
>
> An immediate question that I ask myself is whether this mechanism could be
> expanded to other values than just `"text/html"`. For example, could one do
> `navigator.clipboard.read({unsanitized: ["image/avif"]})` and expect it to
> work (when an AVIF image is on the clipboard)? Reading the relevant
> section in the explainer
> ,
> it seems hardcoded to ignore any other value than `"text/html"`, so
> something like `navigator.clipboard.read({unsanitized: ["hahaha/l

Re: [blink-dev] Re: Intent to Ship: Close requests for CloseWatcher, , and popover=""

[Philip Jägenstedt]

The spec change has now landed, LGTM2.

More introspection could possibly be useful
, but
without a concrete use case, example code, or developer feedback, I think
it's hard to do a good job. Having reviewed the spec change, I'm confident
that exposing more information is technically straightforward if the need
arises.

On Thu, Oct 12, 2023 at 1:59 AM Domenic Denicola 
wrote:

>
>
> On Thu, Oct 12, 2023 at 12:51 AM Yoav Weiss 
> wrote:
>
>>
>>
>> On Friday, October 6, 2023 at 12:34:21 AM UTC+2 Chris Harrelson wrote:
>>
>> Hi,
>>
>> While Alex's concerns are totally valid to consider from a feature design
>> perspective, I think they are better to be discussed on the WHATWG issues
>> for this feature. I chatted offline with Alex and he agreed about that
>> point, and agreed to post comments and questions there.
>>
>> So from an API owners perspective LGTM1 modulo considering and taking
>> into account all comments and feedback from Alex on the spec (as we should
>> for all such feedback from anyone, of course!).
>>
>>
>> On Wed, Oct 4, 2023 at 8:28 AM Domenic Denicola 
>> wrote:
>>
>>
>>
>> 2023年10月4日(水) 8:16 Alex Russell :
>>
>>
>>
>> On Monday, October 2, 2023 at 10:16:53 AM UTC-7 Domenic Denicola wrote:
>>
>>
>>
>> 2023年10月2日(月) 10:11 Alex Russell :
>>
>>
>>
>> On Sunday, October 1, 2023 at 9:08:57 PM UTC-7 Domenic Denicola wrote:
>>
>> On Sat, Sep 30, 2023 at 5:01 AM Alex Russell 
>> wrote:
>>
>> The implicit behaviours based on construction order in this API are very
>> strange and seem like footguns.
>>
>>
>> I don't understand why you find this strange, or a footgun. It's intended
>> to be the opposite: it guides developers toward creating the experience the
>> user expects, where when the user requests to close something, the last
>> thing that was opened, is what closes.
>>
>>
>> Chris Palmer covered this pretty well recently, so I'll defer to his more
>> eloquent writeup:
>>
>> https://noncombatant.org/2023/05/29/complexities-of-allocation/
>>
>> Basically, this is spooky action at a distance and without _at least_
>> some reflection and manipulation surface (via DOM, probably), it's hard to
>> understand how this won't turn into a footgun.
>>
>> As a separate note, I'm disappointed in the proliferation of APIs that
>> affect DOM but have no API and reflection. Import Maps spring to mind, but
>> there are other recent examples too. If manual disposal is going to be
>> required for this, we should at least make it possible to introspect
>> outside the scope in which an object that defines this behaviour is
>> allocated.
>>
>>
>> In what way does this API affect the DOM? No parts of the DOM tree are
>> modified by CloseWatcher. The same is true for import maps...
>>
>>
>> This is view state, which is frequently reflected via DOM. The primary
>> concern here is that there's no way to inspect and/or modify the stack
>> (attached to Node instances or not) independently of closure-scoped object
>> lifetimes.
>>
>>
>> It's not clear to me what definition of "view state" you are using, such
>> that it encompasses things like the module specifier resolution algorithm
>> or the routing of Android back gestures.
>>
>> Maybe, if this is a principle you believe in, you could file it as a
>> suggestion on the w3ctag/design-principles repository, ideally with a clear
>> explanation of what the boundaries of this "view state" concept are.
>> (Including what, in your view, would *not* quality as view state.)
>>
>>
>>
>> The TAG feedback didn't touch on this very much, AFAICT, but it's
>> somewhat surprising that the stack of close actions isn't inspectable.
>>
>>
>> I can't speak for the TAG, but here are the reasons why the stack of
>> close watchers isn't inspectable:
>>
>>- We received no developer or partner feedback requesting this
>>capability
>>- This could cause potential forward-compat problems without careful
>>design. E.g., it could make it possible for developers to write code that
>>assumes that only CloseWatchers, dialogs, and popover="" elements are 
>> close
>>watchers, and thus make it hard for the web platform to introduce a fourth
>>close watcher (e.g., ) in the future.
>>- This would be somewhat of an encapsulation leak between different
>>parts of the application, making it harder to write resilient components.
>>(This is not a strong argument, but rather a bias toward waiting for a use
>>case instead of just exposing the information automatically.)
>>
>> Thanks, I appreciate the context, and I am impressed by the thoroughness
>> of the design artifacts.
>>
>>
>> What's the behaviour of non-`destroy()`'d watchers; e.g. if a developer
>> forgets to dispose of one correctly? Can users get stuck?
>>
>>
>> Non-destroy()ed is the default state of a CloseWatcher, so such
>> CloseWatchers will respond to the next close request if they are on the top
>> of the stack. The user cannot really get 

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

[Mike Taylor]

Apologies, I missed that there wasn't yet a spec. I'll retract my LGTM 
until then.


On 10/17/23 4:16 AM, 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 behavior of
existing APIs, such that it has potentially high risk
for Android WebView-based applications?/

None



Debuggability


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

Is this feature fully tested by web-platform-tests

?

No. However, there are web tests in Chromium that test
PointerEventInit with this feature.

Flag name on chrome://flags
PointerEventDeviceId

Finch feature name


Non-finch justification
Edge origin trials successfully underway.

Any Origin Trial feedback you can share?


Absolutely, the feature has been working well. Our partners
(Microsoft Whiteboard) have enabled the feature that is
dependent on this API for their general audience! We did not
receive any constructive feedback. This API is being used by
them on Microsoft Surface Hub devices, which support
multi-pen inking.



Requires code in //chrome?
False

Measurement
PointerEventDeviceId use counter implemented.

Availability expectation
Initially available on Chromiu

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

[Alex Russell]

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 behavior of existing APIs, such 
>>> that it has potentially high risk for Android WebView-based applications?*
>>>
>>> None
>>>
>>>
>>> Debuggability 
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>>> Linux, Chrome OS, Android, and Android WebView)? 
>>> No
>>>
>>> Is this feature fully tested by web-platform-tests 
>>> 
>>> ? 
>>> No. However, there are web tests in Chromium that test PointerEventInit 
>>> with this feature.
>>>
>>> Flag name on chrome://flags 
>>> PointerEventDeviceId
>>>
>>> Finch feature name 
>>>
>>>
>>> Non-finch justification 
>>> Edge origin trials successfully underway.
>>>
>>> Any Origin Trial feedback you can share?
>>>
>>>
>>> Absolutely, the feature has been working well. Our partners (Microsoft 
>>> Whiteboard) have enabled the feature that is dependent on this API for 
>>> their general audience! We did not receive any constructive feedback. This 
>>> API is being used by them on Microsoft Surface Hub devices, which support 
>>> multi-pen inking.
>>>
>>>
>>> Requires code in //chrome? 
>>> False
>>>
>>> Measurement 
>>> PointerEventDeviceId use counter implemented.
>>>
>>> Availability expectation 
>>> Initially available on Chromium browsers on Windows.
>>>
>>> Out of curiosity, are there limitations on other platforms that prevent 
>>> supporting this feature?
>>>
>>>
>>> We haven't been able to get our hands on hardware that supports other 
>>> platforms in addition to multi pen inking in order to implement and 
>>> appropr

Re: [blink-dev] Re: Intent to Ship: Close requests for CloseWatcher, , and popover=""

[Yoav Weiss]

LGTM3

I agree that introspection can be additive on top of what we want to ship
here.

On Wed, Oct 18, 2023 at 5:48 PM Philip Jägenstedt 
wrote:

> The spec change has now landed, LGTM2.
>
> More introspection could possibly be useful
> , but
> without a concrete use case, example code, or developer feedback, I think
> it's hard to do a good job. Having reviewed the spec change, I'm confident
> that exposing more information is technically straightforward if the need
> arises.
>
> On Thu, Oct 12, 2023 at 1:59 AM Domenic Denicola 
> wrote:
>
>>
>>
>> On Thu, Oct 12, 2023 at 12:51 AM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Friday, October 6, 2023 at 12:34:21 AM UTC+2 Chris Harrelson wrote:
>>>
>>> Hi,
>>>
>>> While Alex's concerns are totally valid to consider from a feature
>>> design perspective, I think they are better to be discussed on the WHATWG
>>> issues for this feature. I chatted offline with Alex and he agreed about
>>> that point, and agreed to post comments and questions there.
>>>
>>> So from an API owners perspective LGTM1 modulo considering and taking
>>> into account all comments and feedback from Alex on the spec (as we should
>>> for all such feedback from anyone, of course!).
>>>
>>>
>>> On Wed, Oct 4, 2023 at 8:28 AM Domenic Denicola 
>>> wrote:
>>>
>>>
>>>
>>> 2023年10月4日(水) 8:16 Alex Russell :
>>>
>>>
>>>
>>> On Monday, October 2, 2023 at 10:16:53 AM UTC-7 Domenic Denicola wrote:
>>>
>>>
>>>
>>> 2023年10月2日(月) 10:11 Alex Russell :
>>>
>>>
>>>
>>> On Sunday, October 1, 2023 at 9:08:57 PM UTC-7 Domenic Denicola wrote:
>>>
>>> On Sat, Sep 30, 2023 at 5:01 AM Alex Russell 
>>> wrote:
>>>
>>> The implicit behaviours based on construction order in this API are very
>>> strange and seem like footguns.
>>>
>>>
>>> I don't understand why you find this strange, or a footgun. It's
>>> intended to be the opposite: it guides developers toward creating the
>>> experience the user expects, where when the user requests to close
>>> something, the last thing that was opened, is what closes.
>>>
>>>
>>> Chris Palmer covered this pretty well recently, so I'll defer to his
>>> more eloquent writeup:
>>>
>>> https://noncombatant.org/2023/05/29/complexities-of-allocation/
>>>
>>> Basically, this is spooky action at a distance and without _at least_
>>> some reflection and manipulation surface (via DOM, probably), it's hard to
>>> understand how this won't turn into a footgun.
>>>
>>> As a separate note, I'm disappointed in the proliferation of APIs that
>>> affect DOM but have no API and reflection. Import Maps spring to mind, but
>>> there are other recent examples too. If manual disposal is going to be
>>> required for this, we should at least make it possible to introspect
>>> outside the scope in which an object that defines this behaviour is
>>> allocated.
>>>
>>>
>>> In what way does this API affect the DOM? No parts of the DOM tree are
>>> modified by CloseWatcher. The same is true for import maps...
>>>
>>>
>>> This is view state, which is frequently reflected via DOM. The primary
>>> concern here is that there's no way to inspect and/or modify the stack
>>> (attached to Node instances or not) independently of closure-scoped object
>>> lifetimes.
>>>
>>>
>>> It's not clear to me what definition of "view state" you are using, such
>>> that it encompasses things like the module specifier resolution algorithm
>>> or the routing of Android back gestures.
>>>
>>> Maybe, if this is a principle you believe in, you could file it as a
>>> suggestion on the w3ctag/design-principles repository, ideally with a clear
>>> explanation of what the boundaries of this "view state" concept are.
>>> (Including what, in your view, would *not* quality as view state.)
>>>
>>>
>>>
>>> The TAG feedback didn't touch on this very much, AFAICT, but it's
>>> somewhat surprising that the stack of close actions isn't inspectable.
>>>
>>>
>>> I can't speak for the TAG, but here are the reasons why the stack of
>>> close watchers isn't inspectable:
>>>
>>>- We received no developer or partner feedback requesting this
>>>capability
>>>- This could cause potential forward-compat problems without careful
>>>design. E.g., it could make it possible for developers to write code that
>>>assumes that only CloseWatchers, dialogs, and popover="" elements are 
>>> close
>>>watchers, and thus make it hard for the web platform to introduce a 
>>> fourth
>>>close watcher (e.g., ) in the future.
>>>- This would be somewhat of an encapsulation leak between different
>>>parts of the application, making it harder to write resilient components.
>>>(This is not a strong argument, but rather a bias toward waiting for a 
>>> use
>>>case instead of just exposing the information automatically.)
>>>
>>> Thanks, I appreciate the context, and I am impressed by the thoroughness
>>> of the design artifacts.
>>>
>>>
>>> What's the behaviour of non-`destro

Re: [blink-dev] Intent to Ship: Fire toggle events using microtasks

[Philip Jägenstedt]

Hi again Joey,

Can you bump this thread when you'd like to ship it?

Best regards,
Philip

On Fri, Oct 6, 2023 at 7:38 PM Joey Arhar  wrote:

> > On the level of interest, there was no reaction on
> https://github.com/whatwg/html/issues/9046 after you asked. Is there
> other communication that makes you relatively sure the interest is there?
>
> I should have filed standards positions first. I have done so now:
> - https://github.com/WebKit/standards-positions/issues/263
> - https://github.com/mozilla/standards-positions/issues/901
>
> > It sounds like the idea is to prove this web compatible by shipping it,
> before updating the spec
>
> I intend to get positive signals from Gecko and WebKit first before
> actually shipping this.
> I already have an HTML spec PR open, so the spec could be updated at any
> time.
>
> There is a risk for web compatibility, although I was convinced that this
> should just improve the consistency of the event timing.
> If there is significant breakage, I will disable this change via finch and
> revert the spec changes.
>
> On Fri, Oct 6, 2023 at 4:12 AM Philip Jägenstedt 
> wrote:
>
>> It sounds like the idea is to prove this web compatible by shipping it,
>> before updating the spec. On the level of interest, there was no reaction
>> on https://github.com/whatwg/html/issues/9046 after you asked. Is there
>> other communication that makes you relatively sure the interest is there?
>>
>> On Fri, Oct 6, 2023 at 3:34 AM Joey Arhar  wrote:
>>
>>> Contact emailsjar...@chromium.org
>>>
>>> Explainerhttps://github.com/whatwg/html/issues/9046
>>>
>>> Specificationhttps://github.com/whatwg/html/pull/9775
>>>
>>> Summary
>>>
>>> The toggle events for the popover attribute and the details element, as
>>> well as the close event for dialog elements, currently post a task to the
>>> DOM manipulation task source to fire these events asynchronously. This
>>> means that the event could fire before or after the next render, which
>>> could lead to flaky rendering for one frame. By using microtasks instead,
>>> the event will always fire before the next render. This was suggested in
>>> this HTML spec issue: https://github.com/whatwg/html/issues/9046
>>>
>>>
>>> Blink componentBlink>DOM
>>> 
>>>
>>> TAG reviewThis is a very small change so I'm not making a TAG review.
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> If websites are relying on the slower event timing somehow, then we
>>> could run into problems.
>>>
>>>
>>> *Gecko*: Positive?
>>> https://github.com/whatwg/html/issues/9046#issuecomment-1724509340
>>>
>>> *WebKit*: No signal
>>>
>>> *Web developers*: No signals
>>>
>>> *Other signals*:
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> None
>>>
>>>
>>> Debuggability
>>>
>>> None
>>>
>>>
>>> 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
>>> 
>>> ?Yes
>>>
>>> Flag name on chrome://flagsNone
>>>
>>> Finch feature nameNone
>>>
>>> Non-finch justification
>>>
>>> I am not interested in any metrics changes for this feature, it should
>>> just make the behavior more consistent for web developers. Should it prove
>>> to have issues, I can disable it with a finch killswitch.
>>>
>>>
>>> Requires code in //chrome?False
>>>
>>> Adoption expectationIf we ship this without breaking websites, then I
>>> think the other browsers will feel interested in implementing this as well.
>>>
>>> Adoption planThis change modifies several WPTs which the other browsers
>>> are likely watching, which will help encourage them to implement this as
>>> well.
>>>
>>> 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/5123249231101952
>>>
>>> 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://gr

Re: [blink-dev] Intent to Experiment: Protected Audience Bidding & Auction Services

[Mike Taylor]

Hi Paul,

Can you clarify what the proposed end milestone will be?

thanks,
Mike

On 10/13/23 10:46 AM, Chris Harrelson wrote:
Please fill out and start the reviews for Privacy, Security and 
Debuggability in your chromestatus entry, thanks.


On Thu, Oct 12, 2023 at 3:40 PM Paul Jensen  
wrote:



Contact emails

pauljen...@chromium.org, behamil...@google.com


Explainer

Chrome:

https://github.com/WICG/turtledove/blob/main/FLEDGE_browser_bidding_and_auction_API.md



Services:

https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md



Note that this explainer has a helpful onboarding section

for
setting up the services.


Specification

May be influenced by Origin Trial feedback, so not yet started. 
Protected Audience auctions running on Bidding & Auction Services
provide functionality very similar to existing on-device auctions
so much of the existing spec
applies.


Summary

The Protected Audience API (formerly known as FLEDGE) is a Privacy
Sandbox proposal to serve remarketing and custom audience use
cases, designed so third parties cannot track user browsing
behavior across sites. This proposal, the Protected Audience
Bidding & Auction Services proposal, outlines a way to allow
Protected Audience computation to take place on cloud servers in a
Trusted Execution Environment (TEE), rather than running locally
on a user's device. Moving computation to cloud servers can help
optimize the Protected Audience auction, and free up computational
cycles and network bandwidth for a device.


Blink component

Blink>InterestGroups




TAG review

The parent proposal, Protected Audience, is still pending:
https://github.com/w3ctag/design-reviews/issues/723



TAG review status

Pending


Risks


Interoperability and Compatibility

None. This is an optional new feature of the Protected Audience
API. Ad techs can use this new feature by calling
navigator.getInterestGroupAdAuctionData() and specifying values
for new fields in the auction config. Without invoking the new
function or explicit values for those new fields, there's no
functional behavioral change as a result of this feature.


Gecko & WebKit: No signal on parent proposal, Protected Audience.
Asked in the Mozilla forumhere
, and
in the Webkit forum here
.


Web developers: Extensive interest in this feature from adtechs,
evidenced by the myriad of discussions on Protected Audience’s
issue tracker and
weekly WICG calls .


Goals for experimentation

Operating Bidding and Auction services in TEEs represents a major
shift from running Protected Audience auctions inside the
browser.  During this Origin Trial we’d like to gain confidence
that this is possible to do at scale and in a performant manner. 
We want feedback on new API surfaces and how these servers are
operated.


Debuggability

On-device API surfaces should be debuggable in Chrome DevTools,
and we’ve added extensive mechanisms for debugging Bidding and
Auction services

.


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

It will be supported on all platforms that support Protected
Audience, so all but WebView.


Is this feature fully tested by web-platform-tests

?

No. Moreweb-platform-test

coverage
is expected when the specification is closer to completion.


Flag name on chrome://flags

Overall control is not possible via chrome://flags, though the
consented debugging support

Re: [blink-dev] Intent to ship: The Login Status API and its use in FedCM

[Daniel Bratell]

Hi, I just have a couple of questions without having read through the 
intent in detail.


You say "Our goal is to open this up to other websites in the future.", 
but what does that mean? Is there some kind of web site restriction today?


Not creating a https://github.com/mozilla/standards-positions/issues 
entry seems a bit wrong even if someone at Mozilla has said it is not 
needed. They have in the past specifically wanted us to explicitly use 
the standards-positions repo rather than relying on negative or positive 
statements elsewhere. Would it be best to post one just in case?


/Daniel

On 2023-10-12 21:04, Christian Biesinger wrote:



Contact emails

cbiesin...@chromium.org


Explainer

https://github.com/fedidcg/FedCM/blob/main/proposals/idp-sign-in-status-api.md 




Specification

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




Summary

The Login Status API 
(formerly IdP Sign-in Status 
API) allows identity providers to signal to the browser when their 
users are logging-in/out. Our goal is to open this up to other 
websites in the future.


This signal, in this intent, is used by FedCM to address a silent 
timing attack, and in doing so, allows FedCM to operate without third 
party cookies altogether. This update would address the last remaining 
backwards incompatible changes we had previously identified in the 
original I2S of FedCM 
as 
part of our scope of work.


In the future, we expect that the Login Status API may also be used 
outside of FedCM (e.g. the Storage Access API 
) and may 
be useful for websites that are not identity providers (e.g. extending 
browser storage 
).



Blink component

Blink>Identity>FedCM 




Search tags

fedcm , login 




TAG review

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




TAG review status

Pending


Chromium Trial Name

FedCmIdpSigninStatus


Link to origin trial feedback summary

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


Origin Trial documentation link

https://github.com/fedidcg/FedCM/blob/main/proposals/idp-sign-in-status-api.md
https://developer.chrome.com/blog/fedcm-chrome-116-updates/#idp-signin-status 




Risks


Interoperability and Compatibility

For interop:

This I2S is composed of two different (but interdependent) APIs: The 
Login Status API and FedCM.


With regards to the Login Status API 
, both Firefox and Safari are 
on board with the general API (breakout notes 
, follow up 
notes 
) 
. There is an overall agreement on starting from a self-declared 
status and also some general agreement on where the Login Status API 
may lead in the future, including having higher assurance levels and 
applications outside of FedCM.


With regards to its use in FedCM, Firefox is generally in agreement 
with the shape of the solution. Firefox is working on the 
implementation behind a flag. Safari isn’t shipping FedCM yet.


For compat:

While this is a backwards incompatible change for FedCM, we are in 
active conversations with all IdPs that are currently using FedCM (as 
shown by our UKM metrics) and they are onboard with this change.


Gecko: Under consideration (https://github.com/fedidcg/FedCM/pull/436 
) We have been working with 
the Firefox team for the last year or so on this API (e.g. TPAC 2022 
). 
We generally agree on the shape of the solution and we are working 
with them to write the spec in a way that allows Chrome and Firefox to 
implement FedCM in an interoperable way. (Firefox has asked us 
(https://github.com/fedidcg/FedCM/issues/431#issuecomment-1425025469 
) 
to rely on PR comments instead of filing standards positions for these 
FedCM extensions)


WebKit: Under consideration 
(https://github.com/WebKit/standards-positions/i

Re: [blink-dev] Intent to ship: The Login Status API and its use in FedCM

[Christian Biesinger]

+Ben and Martin from Mozilla -- could you weigh in on whether we should
create a Mozilla standards position request for this?

Daniel: there is no technical limitation that prevents a non-IDP from
calling this API, apologies for the unclear phrasing. However, a non-IDP
(or indeed an IDP that does not use FedCM) will get no benefit from calling
this API.

Christian

On Wed, Oct 18, 2023 at 12:11 PM Daniel Bratell  wrote:

> Hi, I just have a couple of questions without having read through the
> intent in detail.
>
> You say "Our goal is to open this up to other websites in the future.",
> but what does that mean? Is there some kind of web site restriction today?
>
> Not creating a https://github.com/mozilla/standards-positions/issues
> entry seems a bit wrong even if someone at Mozilla has said it is not
> needed. They have in the past specifically wanted us to explicitly use the
> standards-positions repo rather than relying on negative or positive
> statements elsewhere. Would it be best to post one just in case?
>
> /Daniel
> On 2023-10-12 21:04, Christian Biesinger wrote:
>
> Contact emails
>
> cbiesin...@chromium.org
>
>
> Explainer
>
>
> https://github.com/fedidcg/FedCM/blob/main/proposals/idp-sign-in-status-api.md
>
>
> Specification
>
> https://github.com/fedidcg/FedCM/pull/436
>
>
> Summary
>
> The Login Status API  (formerly
> IdP Sign-in Status API) allows identity providers to signal to the browser
> when their users are logging-in/out. Our goal is to open this up to other
> websites in the future.
>
> This signal, in this intent, is used by FedCM to address a silent timing
> attack, and in doing so, allows FedCM to operate without third party
> cookies altogether. This update would address the last remaining backwards
> incompatible changes we had previously identified in the original I2S of
> FedCM
> 
> as part of our scope of work.
>
> In the future, we expect that the Login Status API may also be used
> outside of FedCM (e.g. the Storage Access API
> ) and may be
> useful for websites that are not identity providers (e.g. extending
> browser storage
> ).
>
>
> Blink component
>
> Blink>Identity>FedCM
> 
>
>
> Search tags
>
> fedcm , login
> 
>
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/884
>
>
> TAG review status
>
> Pending
>
>
> Chromium Trial Name
>
> FedCmIdpSigninStatus
>
>
> Link to origin trial feedback summary
>
> https://github.com/fedidcg/FedCM/issues/
>
>
> Origin Trial documentation link
>
>
> https://github.com/fedidcg/FedCM/blob/main/proposals/idp-sign-in-status-api.md
>
> https://developer.chrome.com/blog/fedcm-chrome-116-updates/#idp-signin-status
>
>
> Risks Interoperability and Compatibility
>
> For interop:
>
> This I2S is composed of two different (but interdependent) APIs: The Login
> Status API and FedCM.
>
> With regards to the Login Status API
> , both Firefox and Safari are on
> board with the general API (breakout notes
> , follow up notes
> )
> . There is an overall agreement on starting from a self-declared status and
> also some general agreement on where the Login Status API may lead in the
> future, including having higher assurance levels and applications outside
> of FedCM.
>
> With regards to its use in FedCM, Firefox is generally in agreement with
> the shape of the solution. Firefox is working on the implementation behind
> a flag. Safari isn’t shipping FedCM yet.
>
> For compat:
>
> While this is a backwards incompatible change for FedCM, we are in active
> conversations with all IdPs that are currently using FedCM (as shown by our
> UKM metrics) and they are onboard with this change.
>
> Gecko: Under consideration (https://github.com/fedidcg/FedCM/pull/436) We
> have been working with the Firefox team for the last year or so on this API
> (e.g. TPAC 2022
> ).
> We generally agree on the shape of the solution and we are working with
> them to write the spec in a way that allows Chrome and Firefox to implement
> FedCM in an interoperable way. (Firefox has asked us (
> https://github.com/fedidcg/FedCM/issues/431#issuecomment-1425025469) to
> rely on PR comments instead of filing standards positions for these FedCM
> extensions)
>
> WebKit:  Under consideration (
> https://github.com/WebKit/s

[blink-dev] Re: Intent to Ship: Async Clipboard API: Read unsanitized HTML and write well-formed HTML format.

['Sumeet Sharma' via blink-dev]

I think there is also a copy-side change in that writing to the clipboard 
should never sanitize text/html going forward.
On Wednesday, October 18, 2023 at 10:52:14 AM UTC-4 Evan Stade wrote:

> Hi Anupam,
>
> I think this feature is now scoped just to the read side of the equation, 
> is that correct? Could you update the Chrome status entry 
>  text 
> to remove references to writing to avoid confusion?
>
> -- Evan Stade
>
>
> On Fri, Oct 6, 2023 at 10:31 AM Anupam Snigdha  
> wrote:
>
>> The I2S thread was incorrectly merged into another I2S that I sent for a 
>> completely different feature. I'm creating a new thread and merging 
>> replies. Sorry for the inconvenience.
>>
>> As the author of the web custom formats article 
>> ,
>>  
>> just for me to better understand: the problem is that the clipboard gets 
>> populated with `text/html` by random (web or native) apps. If the clipboard 
>> were populated from the start with `web text/html`, the contents could be 
>> read unsanitized, even without this new parameter. So this new parameter is 
>> the escape hatch that developers can use via 
>> `navigator.clipboard.read({unsanitized: ["text/html"]})`.
>>
>> So, the problem is that, for sites like Excel Online, they aren't sure 
>> where the user is going to paste, so they always have to produce both 'web 
>> text/html' and 'text/html'. That way if an app doesn't have support for web 
>> custom format, then they can use the native HTML format. Same thing for 
>> native apps that produce a web custom format.
>> There are also legacy native apps (old Office versions that are used by 
>> Enterprises) that don't have support for the new web custom format, so the 
>> site has to produce the standard HTML format for those apps as well.
>> But you are right that if both source and target apps support web custom 
>> format, then it can be used to access unsanitized HTML content.
>>
>> An immediate question that I ask myself is whether this mechanism could 
>> be expanded to other values than just `"text/html"`.
>>
>> Currently we are focusing on the standard HTML format to better align 
>> with the DataTransfer APIs. In theory you could add support for other 
>> built-in formats as well, but the main intent here is to produce similar 
>> fidelity of HTML format so sites that use DataTransfer APIs to read HTML do 
>> not experience any regression when they move over to async clipboard API 
>> for copy-paste operations.
>>
>> Here is a document where I described the regressions and impact on the 
>> apps when sanitization is performed: 
>> https://docs.google.com/document/d/1nLny6t3w0u9yxEzusgFJSj-D6DZmDIAzkr1DdgWcZXA/edit?usp=sharing
>>
>> Some native apps that I surveyed for impact of this new proposal: 
>> https://docs.google.com/document/d/1O2vtCS23nB_6aJy7_xcdaWKw7TtqYm0fERzEjtLyv5M/edit?usp=sharing
>>
>> FWIW, this demo was initially a bit misleading, since I expected "some 
>> text" to be on the clipboard, or whatever I put into the `contenteditable` 
>> box, but it's hardcoded. Maybe remove the box.
>>
>> Oops, sorry about that. Copy-paste error 🙂 I fixed it now.
>>
>> Please let me know if you have any questions!
>>
>> Thanks,
>> Anupam
>> --
>> *From:* Thomas Steiner 
>> *Sent:* Friday, October 6, 2023 2:54 AM
>> *To:* Anupam Snigdha 
>> *Cc:* blin...@chromium.org ; Sanket Joshi (EDGE) <
>> sa...@microsoft.com>; Evan Stade ; jsb...@google.com 
>> ; Ana Sollano Kim 
>> *Subject:* [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: Async 
>> Clipboard API: Read unsanitized HTML and write well-formed HTML format.
>>  
>>
>> Adoption expectation
>> Excel online is ready to use this API. They are trying to move away from 
>> DataTransfer APIs and use Async clipboard APIs where web custom format is 
>> supported along with other benefits from async usage.
>>
>> Adoption plan 
>> Support for async clipboard API and web custom format is already in inner 
>> rings, so once this gets added to the clipboard API, Excel would be ready 
>> to use it right away.
>>
>>
>> As the author of the web custom formats article 
>> ,
>>  
>> just for me to better understand: the problem is that the clipboard gets 
>> populated with `text/html` by random (web or native) apps. If the clipboard 
>> were populated from the start with `web text/html`, the contents could be 
>> read unsanitized, even without this new parameter. So this new parameter is 
>> the escape hatch that developers can use via 
>> `navigator.clipboard.read({unsanitized: ["text/html"]})`.
>>
>> An immediate question that I ask myself is whether this mechanism could 
>> be expanded to other values than just `"text/html"`. For example, could one 
>> do `navigator.clipboard.read({unsanitized: ["image/avif"]})` 

Re: [blink-dev] Intent to Ship: Scroll To Text Fragment

[K. Moon]

Please stop posting this kind of feedback to this thread; you've been
informed multiple times by multiple individuals that this is not the right
forum for Chrome product feedback.

Continuing to persist in doing so may lead to intervention, like blocking
your ability to post entirely.

On Tue, Oct 17, 2023, 10:15 PM Adam Semenenko 
wrote:

> Here's another example of useless and distracting highlighting. What is it
> about the first two sentences that need highlighting? Is their position not
> significant enough?
>
> On Thu, 5 Oct 2023, 11:40 Adam Semenenko, 
> wrote:
>
>> Is it still not possible to disable this distraction yet? I found a
>> wonderfully ironic example today - see attached screenshot.
>>
>> There seem to be only two ways that this feature is used:
>>
>> 1. The first sentence of a page is highlighted, which is completely
>> redundant and patronising. Yes Chrome, thank you for highlighting the very
>> first sentence. However could I cope without you.
>>
>> 2. A random sentence halfway through the page is highlighted. This is
>> never what I want: I always want to read the page so that I can understand
>> the sentence in context.
>>
>>
>>
>> On Wed, 5 May 2021, 06:40 Adam Semenenko, 
>> wrote:
>>
>>> Hi all,
>>>
>>> Do you know if there's a consistent and easy way to disable this yet?
>>> It's really distracting for me. When I google something and click on a
>>> result, I like consistent behaviour and to see the whole page from the
>>> start. I feel disrupted when I'm randomly dropped into the middle of a page
>>> with a garish colour jumping out at me.
>>>
>>> Cheers,
>>> Adam
>>>
>>> On Mon, 26 Apr 2021 at 21:54, 'Grant Wang' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Hi all,

 It’s been roughly nine months since we first utilized Scroll To Text
 Fragment in featured snippets in Google Search. In that time, we’ve seen
 that Scroll To Text Fragment links help us towards our goal to get users
 the information they need.  In particular:

1. We find that Scroll To Text Fragment links increase engagement
-- users are less likely to visit a page and then quickly hit the back
button, because they can more readily understand how relevant the page 
 is
to their search after arriving at the page.

2. In user surveys, we find that users prefer being scrolled to the
relevant section of a page that’s in a featured snippet. Users who were
scrolled to the relevant section preferred the experience at a rate of 
 2:1;
even users who were not scrolled in the control group preferred the 
 option
of being scrolled to the relevant section at the same 2:1 rate.

 Besides their usage on Google Search, we’ve noticed scroll to text
 fragments links during our crawls of the web.  One of the best use cases
 has been wikipedia citations.  For instance, citation 9
 
 on this page: https://en.wikipedia.org/wiki/Melbourne_Cup_(greyhounds)
 provides the detailed attribution to the fastest-ever time at the Melbourne
 Cup.

 Cheers,
 Grant
 On Thursday, December 12, 2019 at 12:24:40 PM UTC-8
 sligh...@chromium.org wrote:

> LGTM4
>
>
> On Thursday, December 12, 2019 at 12:17:49 PM UTC-8, Daniel Bratell
> wrote:
>>
>> LGTM3
>>
>> /Daniel
>>
>>
>> On Thursday, 12 December 2019 19:45:38 UTC+1, Chris Harrelson wrote:
>>>
>>> LGTM2
>>>
>>> On Wed, Dec 11, 2019 at 10:27 PM Yoav Weiss  wrote:
>>>
 LGTM1


 On Wed, Dec 11, 2019, 22:03 Nick Burris 
 wrote:

> Hi all,
>
> We feel that we're now in good shape for shipping. We have
> addressed all of the shipping blockers that I listed in my previous 
> email,
> and the corresponding implementation changes have landed in Chrome. 
> We're
> still continuing to make improvements to the spec, functionality, and 
> web
> platform tests but we consider the outstanding issues to be minor and
> wouldn't have an effect on interop, so we don't believe they're
> ship-blocking.
>
> We have received positive signal on the feature from Safari, thank
> you Maciej for the reply on webkit-dev
> !
> Note that we actually do have feature detectability specified 
> implemented
> per my reply
> .
> My apologies this was not mentioned in the initial intent to ship 
> email, it
> developed a few emails down the line.
>
>>

Re: [blink-dev] Intent to Re-implement and Ship: CSS Font Loading API - FontFaceSet: check() method

[ChangSeok Oh]

Gecko got a ticket for that failure, WebKit passed the tests when I ran the 
tests with ToT.
Thanks for your LGTMs!

On Wednesday, October 18, 2023 at 12:21:01 AM UTC-7 yoav...@chromium.org 
wrote:

> LGTM3
>
> Thanks for clarifying. Please file implementation bugs for these failures, 
> if ones don't already exist.
>
> On Tue, Oct 17, 2023 at 11:16 PM ChangSeok Oh  wrote:
>
>> Hi Yoav,
>>
>> Yes, Safari and Firefox support the check method [1], and I confirmed it. 
>> The test failures are due to other factors (e.g., pixel mismatches), not 
>> FontFaceSet::check(). Sub-tests on the check() method have passed.
>>
>> [1] https://caniuse.com/mdn-api_fontfaceset_check
>>
>> --
>> ChangSeok
>>
>> > On Oct 17, 2023, at 4:29 AM, Yoav Weiss  wrote:
>> > 
>> > 
>> > 
>> > On Mon, Oct 16, 2023 at 8:15 PM Mike Taylor  
>> wrote:
>> > LGTM2
>> > On 10/16/23 1:35 PM, Alex Russell wrote:
>> >> LGTM1
>> >> 
>> >> On Sun, Oct 15, 2023 at 1:01 PM ChangSeok Oh  
>> wrote:
>> >> Contact emails
>> >> changs...@bytedance.com, shiva...@gmail.com
>> >> 
>> >> Specification
>> >> https://drafts.csswg.org/css-font-loading/#font-face-set-check
>> >> 
>> >> Summary
>> >> The FontFaceSet's check() function verifies whether it's possible to 
>> display text using the specified fonts without attempting to utilize fonts 
>> in the FontFaceSet that have not completed loading. This allows users to 
>> safely employ the font without later triggering a font replacement (i.e., 
>> font swap).
>> >> 
>> >> Motivation
>> >> While having a review [1] to fix issue 1416842 [2], I heard that an 
>> "Intent to ship" email is required since the fix changes Blink's behavior. 
>> The font loading API was updated, so we need to update our implementation 
>> in conformance with the spec.
>> >> 
>> >> [1] https://chromium-review.googlesource.com/c/chromium/src/+/4913179
>> >> [2] https://crbug.com/1416842
>> >> 
>> >> Blink component
>> >> Blink>Fonts
>> >> 
>> >> Search tags
>> >> CSS, Font, Loading, FontFaceSet, check
>> >> 
>> >> TAG review
>> >> None
>> >> 
>> >> TAG review status
>> >> Not applicable
>> >> 
>> >> Risks
>> >> 
>> >> Interoperability and Compatibility
>> >> The current behavior of Blink does neither follow the updated spec nor 
>> match other engines' behavior. This proposal aims at fixing it. 
>> https://github.com/w3c/csswg-drafts/issues/5744
>> >> 
>> >> Gecko: Shipped/Shipping (
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1252821)
>> >> 
>> >> WebKit: Shipped/Shipping (
>> https://bugs.webkit.org/show_bug.cgi?id=156035 
>> > 
>> > I see Safari failing both WPTs you state below and Firefox fails one of 
>> them. Are you sure they are shipping it?
>> >> 
>> >> 
>> >> 
>> >> Web developers: No signals
>> >> 
>> >> Other signals:
>> >> 
>> >> WebView application risks
>> >> Does this intent deprecate or change behavior of existing APIs, such 
>> that it has potentially high risk for Android WebView-based applications?
>> >> None
>> >> 
>> >> Debuggability
>> >> None
>> >> 
>> >> Will this feature be supported on all six Blink platforms (Windows, 
>> Mac, Linux, Chrome OS, Android, and Android WebView)?
>> >> Yes
>> >> 
>> >> Is this feature fully tested by web-platform-tests?Yes
>> >> The following WPT tests cover this feature. * 
>> css/css-fonts/fallback-remote-to-data-url.html * 
>> css/css-fonts/fallback-url-to-local.html
>> >> 
>> >> 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=1416842
>> >> 
>> >> Estimated milestones
>> >> Shipping on desktop
>> >> 120
>> >> Shipping on Android
>> >> 120
>> >> Shipping on WebView
>> >> 120
>> >> Shipping on WebView
>> >> 120
>> >> 
>> >> Anticipated spec changes
>> >> Open questions about a feature may be a source of future web compat or 
>> interop issues. Please list open issues (e.g. links to known github issues 
>> in the project for the feature specification) whose resolution may 
>> introduce web compat/interop risk (e.g., changing to naming or structure of 
>> the API in a non-backward-compatible way).
>> >> None
>> >> 
>> >> Link to entry on the Chrome Platform Status
>> >> https://chromestatus.com/feature/5174086494060544
>> >> 
>> >> This intent message was generated by Chrome Platform Status.
>> >> -- 
>> >> You received this message because you are subscribed to the Google 
>> Groups "blink-dev" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send 
>> an email to blink-dev+...@chromium.org.
>> >> To view this discussion on the web visit 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f1705c1e-cf65-4c2e-bfe2-3ee3b4fb12d1n%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 

Re: [blink-dev] Re: PSA: Web MIDI Permissions Prompt Change

[Hongchan Choi]

Hello Alex,

What's the rationale for this change?


There have been several reported problems around Web MIDI API's drive-by
access to client MIDI devices. (crbug , blog post
) To address this
problem, the Audio WG decided to place an explicit permission on the
general MIDI API access. (spec
) Originally, the
explicit permission was only required for the advanced MIDI usage (e.g.
system exclusive message) in Chrome, but the completion of this work will
expand the scope of the permission even to the regular MIDI API usage.


> Is it documented anywhere? I don't see an Explainer linked.


As Michael pointed out, we are not sure if this work requires an explainer
since a) FireFox already implemented with a wider permission per the spec
and b) this work does not involve API changes. We can expand the Chrome
Status entry to include more context and rationale if that's helpful.

Best,
Hongchan


On Tue, Oct 17, 2023 at 3:32 PM Michael Wilson 
wrote:

> In case you were asking about the permissions prompt change instead of the
> schedule change:
>
> This is not an API change and that's why we are sending out a PSA instead
> of an intent. The nature of the permission prompt change is described in
> the Chromestatus entry.
>
> Please let me know if you have more questions.
>
> Best,
> Michael
>
>
> On Tue, Oct 17, 2023 at 3:11 PM Michael Wilson 
> wrote:
>
>> Hi Alex,
>>
>> We've been having trouble finishing up the engineering work, hence the
>> delay.  I'm trying to make some workflow adjustments now.
>>
>> Best,
>> Michael
>>
>> On Tue, Oct 17, 2023 at 2:30 PM Alex Russell 
>> wrote:
>>
>>> What's the rationale for this change? Is it documented anywhere? I don't
>>> see an Explainer linked.
>>>
>>> On Tue, Oct 17, 2023, 2:11 PM 'Ajay Rahatekar' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 This feature is now planned to ship in M121.

 On Tuesday, July 18, 2023 at 12:59:23 PM UTC-7 Ajay Rahatekar wrote:

> This feature is planned to ship in M118.
>
> On Thursday, April 13, 2023 at 10:56:40 AM UTC-7 Ajay Rahatekar wrote:
>
>> A correction. The permission prompt will not be released on Webview
>> at this time. This is planned for to be revisited later.
>>
>> On Wednesday, April 5, 2023 at 4:54:20 PM UTC-7 Ajay Rahatekar wrote:
>>
>>> Contact emails
>>>
>>> mjwi...@chromium.org, sinaf...@chromium.org, hong...@chromium.org
>>>
>>> Specification
>>>
>>> https://www.w3.org/TR/webmidi/#requestmidiaccess
>>>
>>> Summary
>>>
>>> This change will require users to grant permission before they can
>>> use the Web MIDI API. Currently, users must explicitly grant permission 
>>> to
>>> use SysEx messages with the Web MIDI API. With this change, users will 
>>> need
>>> to grant a single permission to use the Web MIDI API and SysEx support.
>>> Both permissions will be requested in a bundled permission prompt.
>>>
>>> Blink component
>>>
>>> Blink>WebMIDI
>>> 
>>>
>>> Search tags
>>>
>>> MIDI , SysEx
>>>
>>> Risks
>>>
>>> Firefox already has a permissions prompt on Web MIDI API. We are
>>> working with known partners and plan on socializing this Chromium 
>>> change.
>>>
>>> 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
>>>
>>> Requires code in //chrome?
>>>
>>> False
>>>
>>> Tracking bug
>>>
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1420307
>>>
>>> Estimated milestones
>>>
>>> We hope to ship this in Q2 2023.
>>>
>>>
>>> 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/5087054662205440
>>>
>>> This intent message was generated by Chrome Platform Status
>>> .
>>>
>>>
>>> --
 You received this message because you are subscribed to the Google
 Groups "b

[blink-dev] Web-Facing Change PSA: View Transitions: making callback non-nullable

[Vladimir Levin]

Contact emailsvmp...@chromium.org

Specification
https://drafts.csswg.org/css-view-transitions-1/#additions-to-document-api

Summary

The `startViewTransition` call currently takes an optional nullable
callback type with a default value of null: `startViewTransition(optional
UpdateCallback? callback = null)` This feature changes this to be a
non-nullable type: `startViewTransition(optional UpdateCallback callback)`
More details: https://github.com/w3c/csswg-drafts/issues/9460


Blink componentBlink>ViewTransitions>SPA


TAG reviewNone

TAG review statusNot applicable - this is a minor, but visible, change to
the API contract

Risks


Interoperability and Compatibility

If there are cases of startViewTransition that explicitly pass `null` then
these will stop working. We don't believe there is any significant number
of these, based on the currently low usage of the view transition API, and
null being a small subset of those.


*Gecko*: No signal

*WebKit*: No signal

*Web developers*: No signals

*Other signals*:

WebView application risks

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

None


Debuggability

Same as ViewTransitiosn


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

?Yes

Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Estimated milestones
Shipping on desktop 120
Shipping on Android 120
Shipping on WebView 120

Anticipated spec changes

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

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

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

Re: [blink-dev] Re: PSA: Web MIDI Permissions Prompt Change

[Alex Russell]

Thanks for the explanation. I was also unsure if this needs an intent, and
my gut feeling is "no", except that it will be useful for this to get
captured in docs and updates for developers.

In that spirit, LGTM1, and thanks for filing.

On Wed, Oct 18, 2023, 10:45 AM Hongchan Choi  wrote:

> Hello Alex,
>
> What's the rationale for this change?
>
>
> There have been several reported problems around Web MIDI API's drive-by
> access to client MIDI devices. (crbug , blog
> post ) To
> address this problem, the Audio WG decided to place an explicit permission
> on the general MIDI API access. (spec
> ) Originally, the
> explicit permission was only required for the advanced MIDI usage (e.g.
> system exclusive message) in Chrome, but the completion of this work will
> expand the scope of the permission even to the regular MIDI API usage.
>
>
>> Is it documented anywhere? I don't see an Explainer linked.
>
>
> As Michael pointed out, we are not sure if this work requires an explainer
> since a) FireFox already implemented with a wider permission per the spec
> and b) this work does not involve API changes. We can expand the Chrome
> Status entry to include more context and rationale if that's helpful.
>
> Best,
> Hongchan
>
>
> On Tue, Oct 17, 2023 at 3:32 PM Michael Wilson 
> wrote:
>
>> In case you were asking about the permissions prompt change instead of
>> the schedule change:
>>
>> This is not an API change and that's why we are sending out a PSA instead
>> of an intent. The nature of the permission prompt change is described in
>> the Chromestatus entry.
>>
>> Please let me know if you have more questions.
>>
>> Best,
>> Michael
>>
>>
>> On Tue, Oct 17, 2023 at 3:11 PM Michael Wilson 
>> wrote:
>>
>>> Hi Alex,
>>>
>>> We've been having trouble finishing up the engineering work, hence the
>>> delay.  I'm trying to make some workflow adjustments now.
>>>
>>> Best,
>>> Michael
>>>
>>> On Tue, Oct 17, 2023 at 2:30 PM Alex Russell 
>>> wrote:
>>>
 What's the rationale for this change? Is it documented anywhere? I
 don't see an Explainer linked.

 On Tue, Oct 17, 2023, 2:11 PM 'Ajay Rahatekar' via blink-dev <
 blink-dev@chromium.org> wrote:

> This feature is now planned to ship in M121.
>
> On Tuesday, July 18, 2023 at 12:59:23 PM UTC-7 Ajay Rahatekar wrote:
>
>> This feature is planned to ship in M118.
>>
>> On Thursday, April 13, 2023 at 10:56:40 AM UTC-7 Ajay Rahatekar wrote:
>>
>>> A correction. The permission prompt will not be released on Webview
>>> at this time. This is planned for to be revisited later.
>>>
>>> On Wednesday, April 5, 2023 at 4:54:20 PM UTC-7 Ajay Rahatekar wrote:
>>>
 Contact emails

 mjwi...@chromium.org, sinaf...@chromium.org, hong...@chromium.org

 Specification

 https://www.w3.org/TR/webmidi/#requestmidiaccess

 Summary

 This change will require users to grant permission before they can
 use the Web MIDI API. Currently, users must explicitly grant 
 permission to
 use SysEx messages with the Web MIDI API. With this change, users will 
 need
 to grant a single permission to use the Web MIDI API and SysEx support.
 Both permissions will be requested in a bundled permission prompt.

 Blink component

 Blink>WebMIDI
 

 Search tags

 MIDI , SysEx

 Risks

 Firefox already has a permissions prompt on Web MIDI API. We are
 working with known partners and plan on socializing this Chromium 
 change.

 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

 Requires code in //chrome?

 False

 Tracking bug

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

 Estimated milestones

 We hope to ship this in Q2 2023.


 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 
>

Re: [blink-dev] Re: PSA: Web MIDI Permissions Prompt Change

[Hongchan Choi]

Yes - we are thinking about publishing a short developer-facing article
about Chrome's permission change when the implementation is ready.

Thanks Alex!


On Wed, Oct 18, 2023 at 1:14 PM Alex Russell 
wrote:

> Thanks for the explanation. I was also unsure if this needs an intent, and
> my gut feeling is "no", except that it will be useful for this to get
> captured in docs and updates for developers.
>
> In that spirit, LGTM1, and thanks for filing.
>
> On Wed, Oct 18, 2023, 10:45 AM Hongchan Choi 
> wrote:
>
>> Hello Alex,
>>
>> What's the rationale for this change?
>>
>>
>> There have been several reported problems around Web MIDI API's drive-by
>> access to client MIDI devices. (crbug , blog
>> post ) To
>> address this problem, the Audio WG decided to place an explicit permission
>> on the general MIDI API access. (spec
>> ) Originally, the
>> explicit permission was only required for the advanced MIDI usage (e.g.
>> system exclusive message) in Chrome, but the completion of this work will
>> expand the scope of the permission even to the regular MIDI API usage.
>>
>>
>>> Is it documented anywhere? I don't see an Explainer linked.
>>
>>
>> As Michael pointed out, we are not sure if this work requires an
>> explainer since a) FireFox already implemented with a wider permission per
>> the spec and b) this work does not involve API changes. We can expand the
>> Chrome Status entry to include more context and rationale if that's helpful.
>>
>> Best,
>> Hongchan
>>
>>
>> On Tue, Oct 17, 2023 at 3:32 PM Michael Wilson 
>> wrote:
>>
>>> In case you were asking about the permissions prompt change instead of
>>> the schedule change:
>>>
>>> This is not an API change and that's why we are sending out a PSA
>>> instead of an intent. The nature of the permission prompt change is
>>> described in the Chromestatus entry.
>>>
>>> Please let me know if you have more questions.
>>>
>>> Best,
>>> Michael
>>>
>>>
>>> On Tue, Oct 17, 2023 at 3:11 PM Michael Wilson 
>>> wrote:
>>>
 Hi Alex,

 We've been having trouble finishing up the engineering work, hence the
 delay.  I'm trying to make some workflow adjustments now.

 Best,
 Michael

 On Tue, Oct 17, 2023 at 2:30 PM Alex Russell 
 wrote:

> What's the rationale for this change? Is it documented anywhere? I
> don't see an Explainer linked.
>
> On Tue, Oct 17, 2023, 2:11 PM 'Ajay Rahatekar' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> This feature is now planned to ship in M121.
>>
>> On Tuesday, July 18, 2023 at 12:59:23 PM UTC-7 Ajay Rahatekar wrote:
>>
>>> This feature is planned to ship in M118.
>>>
>>> On Thursday, April 13, 2023 at 10:56:40 AM UTC-7 Ajay Rahatekar
>>> wrote:
>>>
 A correction. The permission prompt will not be released on Webview
 at this time. This is planned for to be revisited later.

 On Wednesday, April 5, 2023 at 4:54:20 PM UTC-7 Ajay Rahatekar
 wrote:

> Contact emails
>
> mjwi...@chromium.org, sinaf...@chromium.org, hong...@chromium.org
>
> Specification
>
> https://www.w3.org/TR/webmidi/#requestmidiaccess
>
> Summary
>
> This change will require users to grant permission before they can
> use the Web MIDI API. Currently, users must explicitly grant 
> permission to
> use SysEx messages with the Web MIDI API. With this change, users 
> will need
> to grant a single permission to use the Web MIDI API and SysEx 
> support.
> Both permissions will be requested in a bundled permission prompt.
>
> Blink component
>
> Blink>WebMIDI
> 
>
> Search tags
>
> MIDI , SysEx
>
> Risks
>
> Firefox already has a permissions prompt on Web MIDI API. We are
> working with known partners and plan on socializing this Chromium 
> change.
>
> 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
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1420307
>
> Estimated milestones
>
> We hope to ship this in Q2 2023.
>

Re: [blink-dev] Re: PSA: Web MIDI Permissions Prompt Change

[Chris Harrelson]

LGTM2

On Wed, Oct 18, 2023 at 1:31 PM Hongchan Choi  wrote:

> Yes - we are thinking about publishing a short developer-facing article
> about Chrome's permission change when the implementation is ready.
>
> Thanks Alex!
>
>
> On Wed, Oct 18, 2023 at 1:14 PM Alex Russell 
> wrote:
>
>> Thanks for the explanation. I was also unsure if this needs an intent,
>> and my gut feeling is "no", except that it will be useful for this to get
>> captured in docs and updates for developers.
>>
>> In that spirit, LGTM1, and thanks for filing.
>>
>> On Wed, Oct 18, 2023, 10:45 AM Hongchan Choi 
>> wrote:
>>
>>> Hello Alex,
>>>
>>> What's the rationale for this change?
>>>
>>>
>>> There have been several reported problems around Web MIDI API's drive-by
>>> access to client MIDI devices. (crbug , blog
>>> post ) To
>>> address this problem, the Audio WG decided to place an explicit permission
>>> on the general MIDI API access. (spec
>>> ) Originally, the
>>> explicit permission was only required for the advanced MIDI usage (e.g.
>>> system exclusive message) in Chrome, but the completion of this work will
>>> expand the scope of the permission even to the regular MIDI API usage.
>>>
>>>
 Is it documented anywhere? I don't see an Explainer linked.
>>>
>>>
>>> As Michael pointed out, we are not sure if this work requires an
>>> explainer since a) FireFox already implemented with a wider permission per
>>> the spec and b) this work does not involve API changes. We can expand the
>>> Chrome Status entry to include more context and rationale if that's helpful.
>>>
>>> Best,
>>> Hongchan
>>>
>>>
>>> On Tue, Oct 17, 2023 at 3:32 PM Michael Wilson 
>>> wrote:
>>>
 In case you were asking about the permissions prompt change instead of
 the schedule change:

 This is not an API change and that's why we are sending out a PSA
 instead of an intent. The nature of the permission prompt change is
 described in the Chromestatus entry.

 Please let me know if you have more questions.

 Best,
 Michael


 On Tue, Oct 17, 2023 at 3:11 PM Michael Wilson 
 wrote:

> Hi Alex,
>
> We've been having trouble finishing up the engineering work, hence the
> delay.  I'm trying to make some workflow adjustments now.
>
> Best,
> Michael
>
> On Tue, Oct 17, 2023 at 2:30 PM Alex Russell 
> wrote:
>
>> What's the rationale for this change? Is it documented anywhere? I
>> don't see an Explainer linked.
>>
>> On Tue, Oct 17, 2023, 2:11 PM 'Ajay Rahatekar' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> This feature is now planned to ship in M121.
>>>
>>> On Tuesday, July 18, 2023 at 12:59:23 PM UTC-7 Ajay Rahatekar wrote:
>>>
 This feature is planned to ship in M118.

 On Thursday, April 13, 2023 at 10:56:40 AM UTC-7 Ajay Rahatekar
 wrote:

> A correction. The permission prompt will not be released on
> Webview at this time. This is planned for to be revisited later.
>
> On Wednesday, April 5, 2023 at 4:54:20 PM UTC-7 Ajay Rahatekar
> wrote:
>
>> Contact emails
>>
>> mjwi...@chromium.org, sinaf...@chromium.org, hong...@chromium.org
>>
>> Specification
>>
>> https://www.w3.org/TR/webmidi/#requestmidiaccess
>>
>> Summary
>>
>> This change will require users to grant permission before they
>> can use the Web MIDI API. Currently, users must explicitly grant 
>> permission
>> to use SysEx messages with the Web MIDI API. With this change, users 
>> will
>> need to grant a single permission to use the Web MIDI API and SysEx
>> support. Both permissions will be requested in a bundled permission 
>> prompt.
>>
>> Blink component
>>
>> Blink>WebMIDI
>> 
>>
>> Search tags
>>
>> MIDI , SysEx
>>
>> Risks
>>
>> Firefox already has a permissions prompt on Web MIDI API. We are
>> working with known partners and plan on socializing this Chromium 
>> change.
>>
>> 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
>>
>> Requires code in //chrome?
>>
>> Fals

Re: [blink-dev] Re: PSA: Web MIDI Permissions Prompt Change

[Mike Taylor]

LGTM3 (if you need it...)

On 10/18/23 2:32 PM, Chris Harrelson wrote:

LGTM2

On Wed, Oct 18, 2023 at 1:31 PM Hongchan Choi  
wrote:


Yes - we are thinking about publishing a short developer-facing
article about Chrome's permission change when the implementation
is ready.

Thanks Alex!


On Wed, Oct 18, 2023 at 1:14 PM Alex Russell
 wrote:

Thanks for the explanation. I was also unsure if this needs an
intent, and my gut feeling is "no", except that it will be
useful for this to get captured in docs and updates for
developers.

In that spirit, LGTM1, and thanks for filing.

On Wed, Oct 18, 2023, 10:45 AM Hongchan Choi
 wrote:

Hello Alex,

What's the rationale for this change?


There have been several reported problems around Web MIDI
API's drive-by access to client MIDI devices. (crbug
, blog post
)
To address this problem, the Audio WG decided to place an
explicit permission on the general MIDI API access. (spec
)
Originally, the explicit permission was only required for
the advanced MIDI usage (e.g. system exclusive message) in
Chrome, but the completion of this work will expand the
scope of the permission even to the regular MIDI API usage.

Is it documented anywhere? I don't see an Explainer
linked.


As Michael pointed out, we are not sure if this work
requires an explainer since a) FireFox already implemented
with a wider permission per the spec and b) this work does
not involve API changes. We can expand the Chrome Status
entry to include more context and rationale if that's helpful.

Best,
Hongchan


On Tue, Oct 17, 2023 at 3:32 PM Michael Wilson
 wrote:

In case you were asking about the permissions prompt
change instead of the schedule change:

This is not an API change and that's why we are
sending out a PSA instead of an intent. The nature of
the permission prompt change is described in the
Chromestatus entry.

Please let me know if you have more questions.

Best,
Michael


On Tue, Oct 17, 2023 at 3:11 PM Michael Wilson
 wrote:

Hi Alex,

We've been having trouble finishing up the
engineering work, hence the delay.  I'm trying to
make some workflow adjustments now.

Best,
Michael

On Tue, Oct 17, 2023 at 2:30 PM Alex Russell
 wrote:

What's the rationale for this change? Is it
documented anywhere? I don't see an Explainer
linked.

On Tue, Oct 17, 2023, 2:11 PM 'Ajay Rahatekar'
via blink-dev  wrote:

This feature is now planned to ship in M121.

On Tuesday, July 18, 2023 at 12:59:23 PM
UTC-7 Ajay Rahatekar wrote:

This feature is planned to ship in M118.

On Thursday, April 13, 2023 at
10:56:40 AM UTC-7 Ajay Rahatekar wrote:

A correction. The permission
prompt will not be released on
Webview at this time. This is
planned for to be revisited later.

On Wednesday, April 5, 2023 at
4:54:20 PM UTC-7 Ajay Rahatekar wrote:


Contact emails

mjwi...@chromium.org,
sinaf...@chromium.org,
hong...@chromium.org


Specification


https://www.w3.org/TR/webmidi/#requestmidiaccess


Summary

This change will require users
to grant permission before
they can use the Web MIDI API.
Currently, users must
explicitly grant permission to

[blink-dev] Intent to Ship: MediaCapabilities: Query HDR support with decodingInfo()

[Dale Curtis]

Contact emailsv...@microsoft.com, gw...@microsoft.com, gur...@microsoft.com
, dalecur...@chromium.org

Explainer
https://github.com/w3c/media-capabilities/blob/main/explainer.md#decode-capabilities

Specificationhttps://www.w3.org/TR/media-capabilities/#hdrmetadatatype

Summary

Extends the Media Capabilities API to allow detection of HDR rendering
support via three new VideoConfiguration dictionary fields:
hdrMetadataType, colorGamut, transferFunction. Chromium implements its own
tone-mapping algorithms so will always return true for HDR10 (smpteSt2086)
static metadata. HDR10+ (smpteSt2094-10) and Dolby Vision (smpteSt2094-40)
dynamic metadata are not currently supported, so will return false. We
anticipate adding support for dynamic metadata in the future, so this API
will allow developers to select the appropriate content for users with
support.


Blink componentBlink>Media>Capabilities


TAG reviewAlready shipping by another UA. The now-closed Media Capabilities
TAG review covered similar discussions:
https://github.com/w3ctag/design-reviews/issues/218

TAG review statusNot applicable

Risks


Interoperability and Compatibility

Low interop risk: Already shipping in Safari.


*Gecko*: Neutral (https://github.com/mozilla/standards-positions/issues/910)

*WebKit*: Shipped/Shipping (
https://www.w3.org/2019/11/19-mediawg-minutes.html)

*Web developers*: Positive (
https://github.com/w3c/media-capabilities/issues/118#issuecomment-511461132)

*Other signals*:

Activation

Will start returning false for some DolbyVision and HDR10+ metadata types
on the web -- playback would have been broken already for these.


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 risks unique to WebView.


Debuggability

Debuggable through media dev tools and chrome://gpu information.


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

?Yes

https://wpt.fyi/results/media-capabilities/decodingInfo.any.html?label=experimental&label=master&aligned


Flag name on chrome://flags

Finch feature nameMediaCapabilitiesDynamicRange

Requires code in //chrome?False

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

Estimated milestones
Shipping on desktop 120
Shipping on Android 120
Shipping on WebView 120

Anticipated spec changes

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

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/jBzVLBz-Yk4/m/ORuQg2zAEwAJ

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/CAPUDrwforrrpNE5RLc_OVa9uwa-63UX03VgijptNU5E8sVcD7g%40mail.gmail.com.