Re: [blink-dev] New API owner: Vladimir Levin!

[Yoav Weiss (@Shopify)]

Congrats!! :)

On Wed, May 15, 2024 at 9:46 PM Ken Russell  wrote:

> Congratulations Vlad!
>
>
> On Wed, May 15, 2024 at 10:43 AM Mike Taylor 
> wrote:
>
>> Congrats Vlad!
>> On 5/15/24 12:22 PM, danakj wrote:
>>
>> Congrats, Vlad :)
>>
>> On Wed, May 15, 2024 at 12:19 PM Chris Harrelson 
>> wrote:
>>
>>> Hi all,
>>>
>>> I'd like to welcome Vlad as our newest API owner. He is a long-time
>>> member of the Blink community that many of you know well, and has quite a
>>> bit of experience in graphics, Blink rendering and standards.
>>>
>>> Welcome Vlad, and congratulations!
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9BACT3QX34KLKXKkA02WccSJmACtJa1nK8eVm0PNe55Q%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/CAHtyhaTEFMFARkpKtj_4JbcHREMNQAPRxEqPDFhVO-HextRDNQ%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/419eb2b4-6eb6-499e-9321-d4caa9c4a6fb%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/CAMYvS2cUsGy0tt%3DgOezbObdnPJpnwtcz0Xp5g8KE2Wr6cb9czA%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/CAOmohSK7p%3Dc-R4dY8Cvy75_SOs7oGZ1qSHyhVqfyLkBefTqeBQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Tabbed web apps

[Brett Wilson]

To follow up, there's a nice shout out at Google I/O about this feature and
also mentions that Figma is trying it:

https://youtu.be/KFeuEMAaKfM?si=pr71c4hfxhI5RbT0=1039

On Sun, May 12, 2024 at 6:08 PM Matt Giuca  wrote:

> Thanks everyone. This is now enabled on ToT in 126.
>
> On Fri, 10 May 2024 at 17:59, TAMURA, Kent  wrote:
>
>> LGTM3.
>>
>>
>> On Fri, May 10, 2024 at 2:41 AM Mike Taylor 
>> wrote:
>>
>>> LGTM2
>>> On 5/9/24 10:48 AM, Chris Harrelson wrote:
>>>
>>> Thanks for these clarifications.
>>>
>>> LGTM1
>>>
>>> On Wed, May 8, 2024 at 6:05 PM Daniel Murphy 
>>> wrote:
>>>
 We don't have an objection to this feature existing - it's actually
 currently in our backlog. But it is very low in our priority list. While we
 can review patches, we will not be able to dedicate resources for
 consultation or maintenance.

 On Wed, May 8, 2024 at 9:19 AM Brett Wilson 
 wrote:

> On Wed, May 8, 2024 at 8:39 AM Alex Russell 
> wrote:
>
>> I'm happy for this to be CrOS first, but would like to unpack Brett's
>> statement above a bit. If we (MSFT) were to polish this up for Windows,
>> would patches for that be accepted?
>>
>
> I can't speak for the browser team. But my current understanding is
> that the browser team likes this in principle but doesn't prioritize it
> high enough to work on it right now (this is a correction from my previous
> assertion). So I'm pretty sure patches enabling this for other platforms
> would be accepted.
>
> Brett
> --
> 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/CABiGVV-Zeyv3Rez%2BPQ%2B%2BfW4ihpRCwnnGN2HNxOyXTA7_uWehzw%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/CA%2B4qT32O-zoM4tarHQvoHkmYt%2B%3Dc5iOiPdkueMk%2BhUe7mkYU%2BA%40mail.gmail.com
 
 .

>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_QmtkQeDUW%2BEbWtQC4ghvpHFk-Uf65YqYjPMjEQEwwCg%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/201d6c2d-be84-4d6b-9c4b-b1c9f89b0bf8%40chromium.org
>>> 
>>> .
>>>
>>
>>
>> --
>> TAMURA Kent
>> Software Engineer, Google
>>
>>
>>

-- 
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/CABiGVV90nyjCkO8zvKA3g7VjCBfbBfqxP_yj9jjeE-0eN-pQYA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Deprecate Mutation Events

[Vladimir Levin]

I recall that some of this usage was feature detected: if mutation events
are supported, use them; otherwise, use something else. Unfortunately, that
makes it difficult to estimate the expected number of breakages. I agree
though that it would be nice to understand the type of usage that still
exists and the likelihood of real breakage


On Wed, May 15, 2024 at 9:27 PM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

>
>
> On Wed, May 15, 2024 at 9:03 PM Mason Freed  wrote:
>
>> Contact emailsmas...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://w3c.github.io/uievents/#legacy-event-types
>>
>> Summary
>>
>> Mutation Events, including `DOMSubtreeModified`, `DOMNodeInserted`,
>> `DOMNodeRemoved`, `DOMNodeRemovedFromDocument`,
>> `DOMNodeInsertedIntoDocument`, and `DOMCharacterDataModified`, are quite
>> bad for page performance, and also significantly increase the complexity of
>> adding new features to the Web. These APIs were deprecated from the spec (
>> https://w3c.github.io/uievents/#legacy-event-types) in 2011, and were
>> replaced (in 2012) by the much better-behaved Mutation Observer API. Usage
>> of the obsolete Mutation Events must now be migrated to Mutation Observer.
>> Mutation event support will be disabled by default starting in Chrome 127,
>> around July 30, 2024. Code should be migrated before that date to avoid
>> site breakage. If more time is needed, there are a few options: - The
>> Mutation Events Deprecation Trial (
>> https://developer.chrome.com/origintrials/#/view_trial/919297273937002497)
>> can be used to re-enable the feature for a limited time on a given site.
>> This can be used through Chrome 134, ending March 25, 2025. - A
>> MutationEventsEnabled enterprise policy (
>> https://chromeenterprise.google/policies/#MutationEventsEnabled) can
>> also be used for the same purpose, also through Chrome 134. Please see this
>> blog post for more detail:
>> https://developer.chrome.com/blog/mutation-events-deprecation Report
>> bugs here:
>> https://issues.chromium.org/new?component=1456718=1948649
>>
>>
>> Blink componentBlink>DOM
>> 
>>
>> Search tagsMutationEvent
>> ,
>> DOMSubtreeModified
>> ,
>> DOMNodeInserted 
>> , DOMNodeRemoved 
>> , DOMNodeRemovedFromDocument
>> ,
>> DOMNodeInsertedIntoDocument
>> ,
>> DOMCharacterDataModified
>> 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Chromium Trial NameMutationEvents
>>
>> Origin Trial documentation link
>> https://developer.chrome.com/blog/mutation-events-deprecation
>>
>> WebFeature UseCounter namekDOMNodeRemovedEvent
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> There are technically 9 Mutation Events, but Chromium only implements 6
>> of them. Their use counters vary significantly: -
>> DOMNodeInsertedIntoDocument: 0.008% - DOMNodeRemovedFromDocument: 0.009% -
>> DOMCharacterDataModified: 0.011% - DOMNodeRemoved: 0.73% -
>> DOMSubtreeModified: 0.68% - DOMNodeInserted: 1.086%
>>
>
> 1% is a *lot*. Did UKM reveal anything interesting about this usage? Do we
> know if all of it is driven by site content, vs e.g. extensions?
>
>
>> Chrome has shipped an experiment since M124 that disables all Mutation
>> Events for 99% of users of Canary, Dev, and Beta versions of Chrome. Very
>> few bugs have been filed in the intervening months, and all that were filed
>> have been resolved quickly via the site owner making changes to not rely on
>> the deprecated events.
>>
> This gives me significant confidence that removing the events will not be
>> as big of a deal as the use counters would suggest. Still, due to the
>> still-high numbers, extreme care will be taken in the removal process. I
>> plan to disable the events via Finch only, so that if issues are
>> encountered, Finch will be a safe way to re-enable the events.
>> Additionally, there are the deprecation trial and enterprise policies to
>> offer an easy relief valve for affected sites.
>>
>>
>> *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*:
>>
>> Activation
>>
>> This npm package attempts to polyfill Mutation Events using Mutation
>> Observer: https://www.npmjs.com/package/mutation-events.
>>
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially 

Re: [blink-dev] Intent to Prototype: Web Translation API

[Domenic Denicola]

On Thu, May 16, 2024 at 1:14 AM Alex Russell 
wrote:

> Ah, thanks. I'd missed that.
>
> I don't see any considered alternatives in that doc.
>

They're in the section titled "Alternatives considered and under
consideration"



> The streaming return value seems like it should, at a minimum, cause us to
> want to update the setHTML and innerHTML/innerText systems to handle stream
> assignments.
>

If you check out previous conversations
 on the subject, this is fairly
complicated. Thankfully, it can be pursued orthogonally. Indeed, every time
we add a streaming API to the platform, fulfilling this feature request
would add even more convenience; but there's no blocking relationship
between these two workstreams. (And since it's just convenience, I haven't
yet seen a browser vendor prioritize the streaming-into-an-element
workstream very highly.)


> Also, do streamed translations ever backtrack? E.g., do systems ever
> produce partial translations that they then change?
>

Given our setting, with a single (non-streaming) input, this does not occur
with the models we're aware of. Although there's plausibly some in which
this can be the case.

Of course, if the input is allowed to be streaming, then indeed this can
occur. Which is why we don't support streaming input

for
now.


>
> Best,
>
> Alex
>
> On Mon, May 6, 2024 at 8:54 PM Domenic Denicola 
> wrote:
>
>>
>>
>> On Wed, May 1, 2024 at 6:43 AM Alex Russell 
>> wrote:
>>
>>> This effort seems worthwhile, and would like to see an explainer that
>>> discisses the various API options; that might provide some context for the
>>> security conversation.
>>>
>>
>> Did you see the explainer linked in the original post? I'll post it here
>> again: https://github.com/WICG/translation-api/blob/main/README.md
>>
>>
>>>
>>> Best,
>>>
>>> Alex
>>>
>>> On Tue, Apr 30, 2024, 2:30 AM 'Fergal Daly' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>


 On Tue, 30 Apr 2024 at 18:08, Daniel Vogelheim 
 wrote:

> Hi Domenic, et al.,
>
> This intent came up in the OWP sec review today. We wonder whether
> there's XSS potential, and how input with plain text interspersed with 
> tags
> is meant to be handled:
>
> Several of the use cases seem to hint at the input being HTML strings
> (e.g. "pages with complicated DOM"). If the intended input would indeed be
> HTML strings, and the output is intended to be parsed & inserted into the
> DOM, then this basically implements a new XSS factory. In addition to the
> existing re-parsing risks, it would add new ones based on translation 
> (e.g.
> "" turning into 

Re: [blink-dev] Intent to Ship: Deprecate Mutation Events

[Yoav Weiss (@Shopify)]

On Wed, May 15, 2024 at 9:03 PM Mason Freed  wrote:

> Contact emailsmas...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://w3c.github.io/uievents/#legacy-event-types
>
> Summary
>
> Mutation Events, including `DOMSubtreeModified`, `DOMNodeInserted`,
> `DOMNodeRemoved`, `DOMNodeRemovedFromDocument`,
> `DOMNodeInsertedIntoDocument`, and `DOMCharacterDataModified`, are quite
> bad for page performance, and also significantly increase the complexity of
> adding new features to the Web. These APIs were deprecated from the spec (
> https://w3c.github.io/uievents/#legacy-event-types) in 2011, and were
> replaced (in 2012) by the much better-behaved Mutation Observer API. Usage
> of the obsolete Mutation Events must now be migrated to Mutation Observer.
> Mutation event support will be disabled by default starting in Chrome 127,
> around July 30, 2024. Code should be migrated before that date to avoid
> site breakage. If more time is needed, there are a few options: - The
> Mutation Events Deprecation Trial (
> https://developer.chrome.com/origintrials/#/view_trial/919297273937002497)
> can be used to re-enable the feature for a limited time on a given site.
> This can be used through Chrome 134, ending March 25, 2025. - A
> MutationEventsEnabled enterprise policy (
> https://chromeenterprise.google/policies/#MutationEventsEnabled) can also
> be used for the same purpose, also through Chrome 134. Please see this blog
> post for more detail:
> https://developer.chrome.com/blog/mutation-events-deprecation Report bugs
> here: https://issues.chromium.org/new?component=1456718=1948649
>
>
> Blink componentBlink>DOM
> 
>
> Search tagsMutationEvent
> , DOMSubtreeModified
> ,
> DOMNodeInserted ,
> DOMNodeRemoved ,
> DOMNodeRemovedFromDocument
> ,
> DOMNodeInsertedIntoDocument
> ,
> DOMCharacterDataModified
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Chromium Trial NameMutationEvents
>
> Origin Trial documentation link
> https://developer.chrome.com/blog/mutation-events-deprecation
>
> WebFeature UseCounter namekDOMNodeRemovedEvent
>
> Risks
>
>
> Interoperability and Compatibility
>
> There are technically 9 Mutation Events, but Chromium only implements 6 of
> them. Their use counters vary significantly: - DOMNodeInsertedIntoDocument:
> 0.008% - DOMNodeRemovedFromDocument: 0.009% - DOMCharacterDataModified:
> 0.011% - DOMNodeRemoved: 0.73% - DOMSubtreeModified: 0.68% -
> DOMNodeInserted: 1.086%
>

1% is a *lot*. Did UKM reveal anything interesting about this usage? Do we
know if all of it is driven by site content, vs e.g. extensions?


> Chrome has shipped an experiment since M124 that disables all Mutation
> Events for 99% of users of Canary, Dev, and Beta versions of Chrome. Very
> few bugs have been filed in the intervening months, and all that were filed
> have been resolved quickly via the site owner making changes to not rely on
> the deprecated events.
>
This gives me significant confidence that removing the events will not be
> as big of a deal as the use counters would suggest. Still, due to the
> still-high numbers, extreme care will be taken in the removal process. I
> plan to disable the events via Finch only, so that if issues are
> encountered, Finch will be a safe way to re-enable the events.
> Additionally, there are the deprecation trial and enterprise policies to
> offer an easy relief valve for affected sites.
>
>
> *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*:
>
> Activation
>
> This npm package attempts to polyfill Mutation Events using Mutation
> Observer: https://www.npmjs.com/package/mutation-events.
>
>
> 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, ChromeOS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> Flag name on chrome://flagsmutation-events
>
> Finch feature nameMutationEvents
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1446498
>
> Estimated milestones
> 

Re: [blink-dev] Intent to Ship: Automatic Fullscreen Content Setting

[Reilly Grant]

LGTM as an IWA OWNER (3x LGTM from Blink API OWNERS are still required
according to the IWA-specific API launch process
).

Thank you for working with the IWA and Security reviewers to figure out the
right restrictions to prevent this from exacerbating fullscreen-based
phishing attacks. We have the option to loosen these restrictions if a
better UX solution to the notice and consent is developed.
Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome



On Wed, May 15, 2024 at 3:00 PM Mike Wasserman  wrote:

> Our team can commit to adding Permissions API query integration, with the
> requisite approvals.
> That would provide feature detection, and also clarify requestFullscreen
> method steps in the spec.
>
> I'm requesting approval to ship the feature in its current state, given
> our commitment to follow up.
>
> Thanks,
> Mike
>
>
> On Wed, May 15, 2024 at 10:01 AM Mike Wasserman  wrote:
>
>> No, this content setting does not have Permissions API integration at
>> this time.
>> That seems like a great future improvement, especially if user control of
>> the setting is extended to more contexts.
>>
>> On Wed, May 15, 2024 at 9:37 AM Alex Russell 
>> wrote:
>>
>>> Will the status of the permission be reflected in the Permissions API? I
>>> see Permissions Policy integration, but not the Permissions API reflection
>>> that I'd expect.
>>>
>>> Best,
>>>
>>> Alex
>>>
>>> On Tuesday, May 14, 2024 at 3:54:24 PM UTC-7 Mike Wasserman wrote:
>>>
 Thanks! I pinged the PR, and hope for some feedback there soon.

 Feature detection via Permissions API querying seems like a great
 follow up here, ideally alongside broadened feature availability (i.e.
 extending user control beyond Isolated Web Apps).


 On Tue, May 14, 2024 at 1:43 PM Mike Taylor 
 wrote:

> It would be nice for the PR to be reviewed and approved, even without
> other stakeholder support.
>
> Additionally - the explainer mentions a few options for feature
> detection. Any progress on that front? Or is it just hypothetical?
> On 5/9/24 3:04 PM, Mike Wasserman wrote:
>
> Sure. I'll note that whatwg/fullscreen's PR merging includes a
> question or criteria "At least two implementers are interested (and none
> opposed)".
> I have filed standards position requests with Mozilla and WebKit, and
> I will ping fullscreen spec maintainers for input.
>
> On Thu, May 9, 2024 at 11:39 AM Vladimir Levin 
> wrote:
>
>> Ah thanks, I missed it in the explainer. The spec changes make sense
>> to me. The changes don't look like they would be controversial, but it's
>> probably worthwhile to ensure that this PR is under review and/or landing
>> as a part of shipping this.
>>
>> Thanks!
>> Vlad
>>
>> On Thu, May 9, 2024 at 12:20 PM Mike Wasserman 
>> wrote:
>>
>>> Yes, there's a draft PR
>>>  with the
>>> Explainer's anticipated spec changes
>>> ,
>>> which are designed
>>> 
>>>  alike The rules for choosing a navigable
>>> 
>>> when a new top-level traversable
>>> 
>>> is being requested, as invoked by Window.open()
>>> :
>>>
>>>
>>>- If currentNavigable's active window
>>>
>>> 
>>>does not have transient activation
>>>
>>> 
>>>and the user agent has been configured to not show popups (i.e., the 
>>> user
>>>agent has a "popup blocker" enabled)
>>>   - The user agent may inform the user that a popup has been
>>>   blocked.
>>>
>>>
>>> On Thursday, May 9, 2024 at 7:30:09 AM UTC-7 Vladimir Levin wrote:
>>>
 On Wed, May 8, 2024 at 7:46 PM Mike Wasserman 
 wrote:

> Contact emails
>
> m...@chromium.org, fugu-...@chromium.org
>
> Explainer
>
>
> https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture
>
> Specification
>
> https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen
>
> Design docs
>
>
> 

Re: [blink-dev] Intent to Ship: Automatic Fullscreen Content Setting

[Mike Wasserman]

Our team can commit to adding Permissions API query integration, with the
requisite approvals.
That would provide feature detection, and also clarify requestFullscreen
method steps in the spec.

I'm requesting approval to ship the feature in its current state, given our
commitment to follow up.

Thanks,
Mike


On Wed, May 15, 2024 at 10:01 AM Mike Wasserman  wrote:

> No, this content setting does not have Permissions API integration at this
> time.
> That seems like a great future improvement, especially if user control of
> the setting is extended to more contexts.
>
> On Wed, May 15, 2024 at 9:37 AM Alex Russell 
> wrote:
>
>> Will the status of the permission be reflected in the Permissions API? I
>> see Permissions Policy integration, but not the Permissions API reflection
>> that I'd expect.
>>
>> Best,
>>
>> Alex
>>
>> On Tuesday, May 14, 2024 at 3:54:24 PM UTC-7 Mike Wasserman wrote:
>>
>>> Thanks! I pinged the PR, and hope for some feedback there soon.
>>>
>>> Feature detection via Permissions API querying seems like a great follow
>>> up here, ideally alongside broadened feature availability (i.e. extending
>>> user control beyond Isolated Web Apps).
>>>
>>>
>>> On Tue, May 14, 2024 at 1:43 PM Mike Taylor 
>>> wrote:
>>>
 It would be nice for the PR to be reviewed and approved, even without
 other stakeholder support.

 Additionally - the explainer mentions a few options for feature
 detection. Any progress on that front? Or is it just hypothetical?
 On 5/9/24 3:04 PM, Mike Wasserman wrote:

 Sure. I'll note that whatwg/fullscreen's PR merging includes a question
 or criteria "At least two implementers are interested (and none opposed)".
 I have filed standards position requests with Mozilla and WebKit, and I
 will ping fullscreen spec maintainers for input.

 On Thu, May 9, 2024 at 11:39 AM Vladimir Levin 
 wrote:

> Ah thanks, I missed it in the explainer. The spec changes make sense
> to me. The changes don't look like they would be controversial, but it's
> probably worthwhile to ensure that this PR is under review and/or landing
> as a part of shipping this.
>
> Thanks!
> Vlad
>
> On Thu, May 9, 2024 at 12:20 PM Mike Wasserman 
> wrote:
>
>> Yes, there's a draft PR
>>  with the Explainer's 
>> anticipated
>> spec changes
>> ,
>> which are designed
>> 
>>  alike The rules for choosing a navigable
>> 
>> when a new top-level traversable
>> 
>> is being requested, as invoked by Window.open()
>> :
>>
>>
>>- If currentNavigable's active window
>>
>> 
>>does not have transient activation
>>
>> 
>>and the user agent has been configured to not show popups (i.e., the 
>> user
>>agent has a "popup blocker" enabled)
>>   - The user agent may inform the user that a popup has been
>>   blocked.
>>
>>
>> On Thursday, May 9, 2024 at 7:30:09 AM UTC-7 Vladimir Levin wrote:
>>
>>> On Wed, May 8, 2024 at 7:46 PM Mike Wasserman 
>>> wrote:
>>>
 Contact emails

 m...@chromium.org, fugu-...@chromium.org

 Explainer


 https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture

 Specification

 https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen

 Design docs


 https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture

 Summary

 A new "Automatic Fullscreen" content setting permits
 Element.requestFullscreen() without a user gesture, and permits browser
 dialogs to appear without exiting fullscreen.

 The setting is blocked by default and sites cannot prompt for
 permission. New UI controls are limited to Chrome's settings pages [1] 
 and
 the site info bubble. Users can allow Isolated Web Apps [2], and 
 enterprise
 admins can allow additional origins with the
 AutomaticFullscreenAllowedForUrls policy.

 Combined with Window Management permission [3] and unblocked popups
 

Re: [blink-dev] New API owner: Vladimir Levin!

[Ken Russell]

Congratulations Vlad!


On Wed, May 15, 2024 at 10:43 AM Mike Taylor  wrote:

> Congrats Vlad!
> On 5/15/24 12:22 PM, danakj wrote:
>
> Congrats, Vlad :)
>
> On Wed, May 15, 2024 at 12:19 PM Chris Harrelson 
> wrote:
>
>> Hi all,
>>
>> I'd like to welcome Vlad as our newest API owner. He is a long-time
>> member of the Blink community that many of you know well, and has quite a
>> bit of experience in graphics, Blink rendering and standards.
>>
>> Welcome Vlad, and congratulations!
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9BACT3QX34KLKXKkA02WccSJmACtJa1nK8eVm0PNe55Q%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/CAHtyhaTEFMFARkpKtj_4JbcHREMNQAPRxEqPDFhVO-HextRDNQ%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/419eb2b4-6eb6-499e-9321-d4caa9c4a6fb%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/CAMYvS2cUsGy0tt%3DgOezbObdnPJpnwtcz0Xp5g8KE2Wr6cb9czA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Support Video Chapter in MediaMetadata

['Jiaming Cheng' via blink-dev]

Thanks Domenic and Mike for the reply!

I see. It looks like we have an LGTM on the Mozilla review
. Could we
please add some reviewers for the TAG review as well? If not, I'm happy to
ping this thread again in two weeks :]

Best,
Jiaming

On Tue, May 14, 2024 at 10:16 PM Domenic Denicola 
wrote:

> Hi Jiaming,
>
> Per our process
> ,
> we give the TAG and other vendors at least one month to comment on changes.
> (This is why it is recommended to start these reviewers earlier, before
> sending the Intent to Ship.) So it might be a bit more time before we can
> consider this feature for shipping. Of course, if you get responses and
> engagement before that point, we can proceed earlier.
>
> -Domenic
>
> On Tuesday, May 14, 2024 at 11:06:55 AM UTC+9 Jiaming Cheng wrote:
>
>> Hi team,
>>
>> Those reviews have been posted for 10 days, there's no opposing comments
>> on any of them so far. Could you please take another look at this intent?
>>
>> Let me know if you have any further questions or concerns.
>>
>> Thanks,
>> Jiaming
>>
>> On Fri, May 3, 2024 at 6:25 PM Jiaming Cheng  wrote:
>>
>>> Hi Alex, Chris and Daniel,
>>>
>>> Thank you for your valuable feedback!
>>>
>>> I've addressed your comments and taken the following updates:
>>>
>>> Hey Alex, the ChapterInformation *does* apply to audio as well as
>>> video, since MediaSession is for both audio and video. I've updated the
>>> Chrome status to reflect this.
>>>
>>> Additionally, I've taken the following actions:
>>>
>>>- Added WPT test:
>>>https://chromium-review.googlesource.com/c/chromium/src/+/5516503
>>>- Filed TAG review:
>>>https://github.com/w3ctag/design-reviews/issues/952
>>>- Filed WebKit review:
>>>https://github.com/WebKit/standards-positions/issues/344
>>>- Filed Gecko review:
>>>https://github.com/mozilla/standards-positions/issues/1019
>>>
>>>
>>> I will keep you updated on the progress of these reviews and notify you
>>> once they are approved. Let me know if you have any questions :]
>>>
>>> Best,
>>> Jiaming
>>>
>>> On Wed, May 1, 2024 at 8:57 AM Alex Russell 
>>> wrote:
>>>
 Hey folks,

 On reviewing this, I'm concerned that this isn't also addressing the
 same needs for Audio. This would have come up in a TAG review, and probably
 would have been fleshed out in an Explainer. Would like to see those before
 this progresses.

 Best,

 Alex

 On Tuesday, April 30, 2024 at 3:35:45 PM UTC-7 dan...@microsoft.com
 wrote:

> I was curious about WPT coverage for this and found
> https://wpt.fyi/results/mediasession/mediametadata.html
>
>
>
> Maybe that could be updated to check for the basics of the new
> attribute?
>
>
>
> -- Dan
>
>
>
> *From:* 'Jiaming Cheng' via blink-dev 
> *Sent:* Tuesday, April 30, 2024 1:50 PM
> *To:* blink-dev@chromium.org
> *Cc:* Alex Newcomer ; Megan Fu <
> megan...@google.com>; Tommy Steimel ; Andrew Xu <
> andre...@google.com>
> *Subject:* [blink-dev] Intent to Ship: Support Video Chapter in
> MediaMetadata
>
>
> Contact emails
>
> jiami...@google.com
>
>
> Explainer
>
> https://github.com/w3c/mediasession/pull/308
>
>
> Specification
>
> https://www.w3.org/TR/mediasession/#the-chapterinformation-interface
>
>
> Summary
>
> The corresponding implementation on the blink layer based on the w3c
> api change, which is to add the `ChapterInformation` attribute in the
> existing `MediaMetadata` See the propose:
> https://github.com/w3c/mediasession/issues/273
>
>
>
>
> Blink component
>
> Blink>Media>Session
> 
>
>
> TAG review
>
> None
>
>
> TAG review status
>
> Not applicable
>
>
> Risks
>
>
>
>
> Interoperability and Compatibility
>
> It’s low risk as it's a small addition to an existing API that both
> Gecko and WebKit approve of
>
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: No signals
>
> *Other signals*:
>
>
> WebView application risks
>
> *Does this intent deprecate or change behavior of existing APIs, such
> that it has potentially high risk for Android WebView-based applications?*
>
> None
>
>
>
>
> Debuggability
>
> None
>
>
>
>
> 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
> 

[blink-dev] Intent to Ship: Deprecate Mutation Events

[Mason Freed]

Contact emailsmas...@chromium.org

ExplainerNone

Specificationhttps://w3c.github.io/uievents/#legacy-event-types

Summary

Mutation Events, including `DOMSubtreeModified`, `DOMNodeInserted`,
`DOMNodeRemoved`, `DOMNodeRemovedFromDocument`,
`DOMNodeInsertedIntoDocument`, and `DOMCharacterDataModified`, are quite
bad for page performance, and also significantly increase the complexity of
adding new features to the Web. These APIs were deprecated from the spec (
https://w3c.github.io/uievents/#legacy-event-types) in 2011, and were
replaced (in 2012) by the much better-behaved Mutation Observer API. Usage
of the obsolete Mutation Events must now be migrated to Mutation Observer.
Mutation event support will be disabled by default starting in Chrome 127,
around July 30, 2024. Code should be migrated before that date to avoid
site breakage. If more time is needed, there are a few options: - The
Mutation Events Deprecation Trial (
https://developer.chrome.com/origintrials/#/view_trial/919297273937002497)
can be used to re-enable the feature for a limited time on a given site.
This can be used through Chrome 134, ending March 25, 2025. - A
MutationEventsEnabled enterprise policy (
https://chromeenterprise.google/policies/#MutationEventsEnabled) can also
be used for the same purpose, also through Chrome 134. Please see this blog
post for more detail:
https://developer.chrome.com/blog/mutation-events-deprecation Report bugs
here: https://issues.chromium.org/new?component=1456718=1948649


Blink componentBlink>DOM


Search tagsMutationEvent
, DOMSubtreeModified
, DOMNodeInserted
, DOMNodeRemoved
,
DOMNodeRemovedFromDocument
,
DOMNodeInsertedIntoDocument
,
DOMCharacterDataModified


TAG reviewNone

TAG review statusNot applicable

Chromium Trial NameMutationEvents

Origin Trial documentation link
https://developer.chrome.com/blog/mutation-events-deprecation

WebFeature UseCounter namekDOMNodeRemovedEvent

Risks


Interoperability and Compatibility

There are technically 9 Mutation Events, but Chromium only implements 6 of
them. Their use counters vary significantly: - DOMNodeInsertedIntoDocument:
0.008% - DOMNodeRemovedFromDocument: 0.009% - DOMCharacterDataModified:
0.011% - DOMNodeRemoved: 0.73% - DOMSubtreeModified: 0.68% -
DOMNodeInserted: 1.086% Chrome has shipped an experiment since M124 that
disables all Mutation Events for 99% of users of Canary, Dev, and Beta
versions of Chrome. Very few bugs have been filed in the intervening
months, and all that were filed have been resolved quickly via the site
owner making changes to not rely on the deprecated events. This gives me
significant confidence that removing the events will not be as big of a
deal as the use counters would suggest. Still, due to the still-high
numbers, extreme care will be taken in the removal process. I plan to
disable the events via Finch only, so that if issues are encountered, Finch
will be a safe way to re-enable the events. Additionally, there are the
deprecation trial and enterprise policies to offer an easy relief valve for
affected sites.


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

Activation

This npm package attempts to polyfill Mutation Events using Mutation
Observer: https://www.npmjs.com/package/mutation-events.


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, ChromeOS, Android, and Android WebView)?Yes

Is this feature fully tested by web-platform-tests

?No

Flag name on chrome://flagsmutation-events

Finch feature nameMutationEvents

Requires code in //chrome?False

Tracking bughttps://crbug.com/1446498

Estimated milestones
Shipping on desktop 127
Origin trial desktop first 124
Origin trial desktop last 134
Shipping on Android 127
OriginTrial Android last 134
OriginTrial Android first 124
Shipping on WebView 127
OriginTrial webView last 134
OriginTrial webView first 124

Anticipated spec changes

Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github 

Re: [blink-dev] New API owner: Vladimir Levin!

[Mike Taylor]

Congrats Vlad!

On 5/15/24 12:22 PM, danakj wrote:

Congrats, Vlad :)

On Wed, May 15, 2024 at 12:19 PM Chris Harrelson 
 wrote:


Hi all,

I'd like to welcome Vlad as our newest API owner. He is a
long-time member of the Blink community that many of you know
well, and has quite a bit of experience in graphics, Blink
rendering and standards.

Welcome Vlad, and congratulations!
-- 
You received this message because you are subscribed to the Google

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

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9BACT3QX34KLKXKkA02WccSJmACtJa1nK8eVm0PNe55Q%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/CAHtyhaTEFMFARkpKtj_4JbcHREMNQAPRxEqPDFhVO-HextRDNQ%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/419eb2b4-6eb6-499e-9321-d4caa9c4a6fb%40chromium.org.

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

[Yoav Weiss (@Shopify)]

LGTM3

On Wed, May 15, 2024 at 6:02 PM Daniel Bratell  wrote:

> LGTM2
>
> /Daniel
> On 2024-05-15 07:13, Domenic Denicola wrote:
>
> LGTM1.
>
> I have a small non-blocking request: update your Chrome Status entry to
> avoid using ClassName.staticMethod() syntax for what appears to be an
> instance method. (See e.g. this related discussion
>  and this bug I filed on
> Chrome Status a year ago
> .) This
> will avoid a confusing experience for web developers when this information
> makes its way into the beta blog post and other documentation.
>
> On Wednesday, May 15, 2024 at 5:49:30 AM UTC+9 Eugene Zemtsov wrote:
>
>> By reading an MDN article that I'll update after the launch.
>>
>> Even now allocationSize() is supposed to be called before copyTo()
>> anyway, to figure out the size of the buffer for the output. (see example
>> 1,
>> example2
>> 
>> )
>> That's why I don't think that it's an ergonomic burden for developers.
>>
>> On Tue, May 14, 2024 at 1:41 PM Mike Taylor 
>> wrote:
>>
>>> Ergonomics-wise, it does not seem intuitive to use a method called
>>> allocationSize() to feature detect copyTo support, even if the semantics
>>> are the same. Besides a very careful reading of the spec, how do we expect
>>> developers to know about it?
>>> On 5/14/24 4:32 PM, Eugene Zemtsov wrote:
>>>
>>> In that discussion Marcos Cáceres asked for a synchronous way to detect
>>> if format conversion is supported.
>>> We have a synchronous call allocationSize()
>>>  that
>>> throws an unsupported error in cases where format conversion is not
>>> supported.
>>> I added a WPT test around it in a recent CL
>>> .
>>>
>>> canCopyTo() might be needed if we have more settings in
>>> VideoFrameCopyToOptions
>>>  and
>>> might want to know which part exactly is causing an error.
>>>
>>> On Tue, May 14, 2024 at 12:25 PM Mike Taylor 
>>> wrote:
>>>
 I see that WebKit raised an API concern around detectability
 .
 In your reply, you said "we should consider...". Has that consideration
 happened, perhaps as follow-up work? :)
 On 5/8/24 4:05 PM, Eugene Zemtsov wrote:

 This feature has Privacy, Security, Enterprise, and Debuggability
 approvals. Webkit gave a positive signal.

 Any objections or questions from the API owners?



 On Wed, May 1, 2024 at 4:26 PM Eugene Zemtsov 
 wrote:

> I've filed issues for TAG review and firefox and webkit positions.
>
> >  Have you looked into other platform APIs that could benefit from
> being able to explicitly specify intermediate format hinting and/or
> transformation?
> I don't think this kind of review can be done for all web APIs by one
> person. It's up to spec editors in each area to identify these small
> changes that improve dev experience and performance.
>
> For media related things:
> -  VideoFrame is a versatile tool that can be created from
> HTMLOrSVGImageElement, HTMLVideoElement, HTMLCanvasElement,
> ImageBitmap,
>  OffscreenCanvas without a copy. In a way this change extends
> variety of export formats for all of them.
> So lots of things can be exported to RGB bitmaps without a canvas
> now.
> -  AudioData has a way to be exported into different sampling formats.
>
>
>
> On Wed, May 1, 2024 at 9:41 AM Mike Taylor 
> wrote:
>
>> +1. Would you mind also filing gecko and webkit positions? I expect
>> them to be positive, given the informal signals you have in the spec PRs
>> already - but this also lets them know we're moving ahead with shipping.
>> Thanks - Mike
>> On 5/1/24 11:51 AM, Alex Russell wrote:
>>
>> hey Eugene,
>>
>> This is an exciting an useful addition! Have you looked into other
>> platform APIs that could benefit from being able to explicitly specify
>> intermediate format hinting and/or transformation? It's a place where 
>> (had
>> the TAG been consulted) I would have expected to see a larger chain of
>> additions to make this work in other areas, or at least a discussion of 
>> why
>> they aren't (or are?) being pursued. Have you looked into that?
>>
>> Best,
>>
>> Alex
>>
>> On Tuesday, April 30, 2024 at 3:51:01 PM UTC-7 Eugene Zemtsov wrote:
>>
>>> > Can you please request reviews for privacy, security, enterprise,
>>> etc in the chromestatus entry?
>>>

Re: [blink-dev] Intent to Ship: Automatic Fullscreen Content Setting

[Mike Wasserman]

No, this content setting does not have Permissions API integration at this
time.
That seems like a great future improvement, especially if user control of
the setting is extended to more contexts.

On Wed, May 15, 2024 at 9:37 AM Alex Russell 
wrote:

> Will the status of the permission be reflected in the Permissions API? I
> see Permissions Policy integration, but not the Permissions API reflection
> that I'd expect.
>
> Best,
>
> Alex
>
> On Tuesday, May 14, 2024 at 3:54:24 PM UTC-7 Mike Wasserman wrote:
>
>> Thanks! I pinged the PR, and hope for some feedback there soon.
>>
>> Feature detection via Permissions API querying seems like a great follow
>> up here, ideally alongside broadened feature availability (i.e. extending
>> user control beyond Isolated Web Apps).
>>
>>
>> On Tue, May 14, 2024 at 1:43 PM Mike Taylor 
>> wrote:
>>
>>> It would be nice for the PR to be reviewed and approved, even without
>>> other stakeholder support.
>>>
>>> Additionally - the explainer mentions a few options for feature
>>> detection. Any progress on that front? Or is it just hypothetical?
>>> On 5/9/24 3:04 PM, Mike Wasserman wrote:
>>>
>>> Sure. I'll note that whatwg/fullscreen's PR merging includes a question
>>> or criteria "At least two implementers are interested (and none opposed)".
>>> I have filed standards position requests with Mozilla and WebKit, and I
>>> will ping fullscreen spec maintainers for input.
>>>
>>> On Thu, May 9, 2024 at 11:39 AM Vladimir Levin 
>>> wrote:
>>>
 Ah thanks, I missed it in the explainer. The spec changes make sense to
 me. The changes don't look like they would be controversial, but it's
 probably worthwhile to ensure that this PR is under review and/or landing
 as a part of shipping this.

 Thanks!
 Vlad

 On Thu, May 9, 2024 at 12:20 PM Mike Wasserman 
 wrote:

> Yes, there's a draft PR
>  with the Explainer's 
> anticipated
> spec changes
> ,
> which are designed
> 
>  alike The rules for choosing a navigable
> 
> when a new top-level traversable
> 
> is being requested, as invoked by Window.open()
> :
>
>
>- If currentNavigable's active window
>
> 
>does not have transient activation
>
> 
>and the user agent has been configured to not show popups (i.e., the 
> user
>agent has a "popup blocker" enabled)
>   - The user agent may inform the user that a popup has been
>   blocked.
>
>
> On Thursday, May 9, 2024 at 7:30:09 AM UTC-7 Vladimir Levin wrote:
>
>> On Wed, May 8, 2024 at 7:46 PM Mike Wasserman 
>> wrote:
>>
>>> Contact emails
>>>
>>> m...@chromium.org, fugu-...@chromium.org
>>>
>>> Explainer
>>>
>>>
>>> https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture
>>>
>>> Specification
>>>
>>> https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen
>>>
>>> Design docs
>>>
>>>
>>> https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture
>>>
>>> Summary
>>>
>>> A new "Automatic Fullscreen" content setting permits
>>> Element.requestFullscreen() without a user gesture, and permits browser
>>> dialogs to appear without exiting fullscreen.
>>>
>>> The setting is blocked by default and sites cannot prompt for
>>> permission. New UI controls are limited to Chrome's settings pages [1] 
>>> and
>>> the site info bubble. Users can allow Isolated Web Apps [2], and 
>>> enterprise
>>> admins can allow additional origins with the
>>> AutomaticFullscreenAllowedForUrls policy.
>>>
>>> Combined with Window Management permission [3] and unblocked popups
>>> [4], this unlocks valuable fullscreen capabilities:
>>>
>>> - Open a fullscreen popup on another display, from one gesture
>>>
>>> - Show fullscreen content on multiple displays from one gesture
>>>
>>> - Show fullscreen content on a new display, when it's connected
>>>
>>> - Swap fullscreen windows between displays with one gesture
>>>
>>> - Show fullscreen content after user gesture expiry or consumption
>>>
>>> [1] 

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

['Sahir Vellani' via blink-dev]

>From my understanding, we need to wait for the PointerEvents spec V3 to be 
published before the PR can be merged; this change is slated for the 4th 
iteration of the spec.

On Wednesday, May 15, 2024 at 9:02:52 AM UTC-7 Chris Harrelson wrote:

> Hi,
>
> I see the spec PR is still pending. Is there a reason it can't land before 
> shipping?
>
> On Thu, May 9, 2024 at 12:23 PM 'Sahir Vellani' via blink-dev <
> blin...@chromium.org> wrote:
>
>> Done! I've updated the explainer as well as the links in the TAG review.
>>
>> On Thursday, May 9, 2024 at 8:51:02 AM UTC-7 jyas...@chromium.org wrote:
>>
>>> Oops, Ben's not at Microsoft anymore, so you've done the best you can 
>>> with the Mozilla and WebKit position requests. Thanks.
>>>
>>> On Thu, May 9, 2024 at 8:48 AM Jeffrey Yasskin  
>>> wrote:
>>>
 If you've moved the explainer, could you replace the content of 
 https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md
  
 with a pointer to the new location? Then people who follow the old links 
 won't be confused. You can and should also update the links in 
 https://github.com/w3ctag/design-reviews/issues/880, and @Ben Mathwig 
 should 
 update the links in 
 https://github.com/mozilla/standards-positions/issues/715 and 
 https://github.com/WebKit/standards-positions/issues/102.

 Thanks,
 Jeffrey

 On Wed, May 8, 2024 at 7:14 PM 'Sahir Vellani' via blink-dev <
 blin...@chromium.org> wrote:

> I've published the spec PR. Since I can't update the links in the 
> original comment of this thread, I'd like to link the updated explainer 
> here for visibility.  
> pointer-event-extensions/pointer-event-device-id-explainer.md 
> at main · WICG/pointer-event-extensions (github.com) 
> 
> I have added comments to both request-for-positions informing of the 
> changes to the API. 
> Thanks for your comments Dan!
>
> On Wednesday, May 8, 2024 at 6:10:48 PM UTC-7 dan...@microsoft.com 
> wrote:
>
>> A non-blocking comment: now that the syntax has been changed I think 
>> it would be great if you could update the Explainer and the Mozilla and 
>> WebKit requests-for-position to reduce potential for confusion.
>>
>> Also, is there a reason the spec PR is still in Draft status? Could 
>> it be published so that there's no ambiguity for reviewers that this is 
>> (hopefully) moving forward imminently?
>>
>> -- Dan
>>
>> On Wednesday, May 8, 2024 at 2:00:38 PM UTC-7 sahir.vellani via 
>> Chromestatus wrote:
>>
>>> This is ready for another review :)
>>>
>> -- 
> 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/52090dcd-f068-456d-be41-bfadbb9055d1n%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+...@chromium.org.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6034517b-2f18-4f57-b36c-dc58cdce99afn%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/2d87b3da-9f3d-4c72-a45e-dff1e5cdcb81n%40chromium.org.

Re: [blink-dev] Intent to Ship: Automatic Fullscreen Content Setting

[Alex Russell]

Will the status of the permission be reflected in the Permissions API? I 
see Permissions Policy integration, but not the Permissions API reflection 
that I'd expect.

Best,

Alex

On Tuesday, May 14, 2024 at 3:54:24 PM UTC-7 Mike Wasserman wrote:

> Thanks! I pinged the PR, and hope for some feedback there soon.
>
> Feature detection via Permissions API querying seems like a great follow 
> up here, ideally alongside broadened feature availability (i.e. extending 
> user control beyond Isolated Web Apps).
>
>
> On Tue, May 14, 2024 at 1:43 PM Mike Taylor  
> wrote:
>
>> It would be nice for the PR to be reviewed and approved, even without 
>> other stakeholder support.
>>
>> Additionally - the explainer mentions a few options for feature 
>> detection. Any progress on that front? Or is it just hypothetical?
>> On 5/9/24 3:04 PM, Mike Wasserman wrote:
>>
>> Sure. I'll note that whatwg/fullscreen's PR merging includes a question 
>> or criteria "At least two implementers are interested (and none opposed)". 
>> I have filed standards position requests with Mozilla and WebKit, and I 
>> will ping fullscreen spec maintainers for input.
>>
>> On Thu, May 9, 2024 at 11:39 AM Vladimir Levin  
>> wrote:
>>
>>> Ah thanks, I missed it in the explainer. The spec changes make sense to 
>>> me. The changes don't look like they would be controversial, but it's 
>>> probably worthwhile to ensure that this PR is under review and/or landing 
>>> as a part of shipping this. 
>>>
>>> Thanks!
>>> Vlad
>>>
>>> On Thu, May 9, 2024 at 12:20 PM Mike Wasserman  wrote:
>>>
 Yes, there's a draft PR  
 with the Explainer's anticipated spec changes 
 ,
  
 which are designed 
 
  alike The rules for choosing a navigable 
 
  
 when a new top-level traversable 
 
  
 is being requested, as invoked by Window.open() 
 :
  


- If currentNavigable's active window 

 
  
does not have transient activation 

 
  
and the user agent has been configured to not show popups (i.e., the 
 user 
agent has a "popup blocker" enabled) 
   - The user agent may inform the user that a popup has been 
   blocked. 


 On Thursday, May 9, 2024 at 7:30:09 AM UTC-7 Vladimir Levin wrote:

> On Wed, May 8, 2024 at 7:46 PM Mike Wasserman  
> wrote:
>
>> Contact emails 
>>
>> m...@chromium.org, fugu-...@chromium.org
>>
>> Explainer 
>>
>>
>> https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture
>>
>> Specification 
>>
>> https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen
>>
>> Design docs 
>>
>>
>> https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture
>>
>> Summary 
>>
>> A new "Automatic Fullscreen" content setting permits 
>> Element.requestFullscreen() without a user gesture, and permits browser 
>> dialogs to appear without exiting fullscreen.
>>
>> The setting is blocked by default and sites cannot prompt for 
>> permission. New UI controls are limited to Chrome's settings pages [1] 
>> and 
>> the site info bubble. Users can allow Isolated Web Apps [2], and 
>> enterprise 
>> admins can allow additional origins with the 
>> AutomaticFullscreenAllowedForUrls policy.
>>
>> Combined with Window Management permission [3] and unblocked popups 
>> [4], this unlocks valuable fullscreen capabilities:
>>
>> - Open a fullscreen popup on another display, from one gesture
>>
>> - Show fullscreen content on multiple displays from one gesture
>>
>> - Show fullscreen content on a new display, when it's connected
>>
>> - Swap fullscreen windows between displays with one gesture
>>
>> - Show fullscreen content after user gesture expiry or consumption
>>
>> [1] chrome://settings/content/automaticFullScreen and site details 
>> pages
>>
>> [2] User control is initially scoped to security-sensitive apps; see 
>> https://chromestatus.com/feature/5146307550248960
>>
>> [3] For multi-screen window placement features; see 
>> 

Re: [blink-dev] New API owner: Vladimir Levin!

[danakj]

Congrats, Vlad :)

On Wed, May 15, 2024 at 12:19 PM Chris Harrelson 
wrote:

> Hi all,
>
> I'd like to welcome Vlad as our newest API owner. He is a long-time member
> of the Blink community that many of you know well, and has quite a bit of
> experience in graphics, Blink rendering and standards.
>
> Welcome Vlad, and congratulations!
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9BACT3QX34KLKXKkA02WccSJmACtJa1nK8eVm0PNe55Q%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/CAHtyhaTEFMFARkpKtj_4JbcHREMNQAPRxEqPDFhVO-HextRDNQ%40mail.gmail.com.

[blink-dev] New API owner: Vladimir Levin!

[Chris Harrelson]

Hi all,

I'd like to welcome Vlad as our newest API owner. He is a long-time member
of the Blink community that many of you know well, and has quite a bit of
experience in graphics, Blink rendering and standards.

Welcome Vlad, and congratulations!

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

Re: [blink-dev] Intent to Prototype: Web Translation API

[Alex Russell]

Ah, thanks. I'd missed that.

I don't see any considered alternatives in that doc. The streaming return
value seems like it should, at a minimum, cause us to want to update the
setHTML and innerHTML/innerText systems to handle stream assignments. Also,
do streamed translations ever backtrack? E.g., do systems ever produce
partial translations that they then change?

Best,

Alex

On Mon, May 6, 2024 at 8:54 PM Domenic Denicola 
wrote:

>
>
> On Wed, May 1, 2024 at 6:43 AM Alex Russell 
> wrote:
>
>> This effort seems worthwhile, and would like to see an explainer that
>> discisses the various API options; that might provide some context for the
>> security conversation.
>>
>
> Did you see the explainer linked in the original post? I'll post it here
> again: https://github.com/WICG/translation-api/blob/main/README.md
>
>
>>
>> Best,
>>
>> Alex
>>
>> On Tue, Apr 30, 2024, 2:30 AM 'Fergal Daly' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>>
>>>
>>> On Tue, 30 Apr 2024 at 18:08, Daniel Vogelheim 
>>> wrote:
>>>
 Hi Domenic, et al.,

 This intent came up in the OWP sec review today. We wonder whether
 there's XSS potential, and how input with plain text interspersed with tags
 is meant to be handled:

 Several of the use cases seem to hint at the input being HTML strings
 (e.g. "pages with complicated DOM"). If the intended input would indeed be
 HTML strings, and the output is intended to be parsed & inserted into the
 DOM, then this basically implements a new XSS factory. In addition to the
 existing re-parsing risks, it would add new ones based on translation (e.g.
 "" turning into 

Re: [blink-dev] Re: Intent to Ship: Stop modifying author-defined selection colors

[Chris Harrelson]

LGTM3

On Wed, May 15, 2024 at 9:08 AM Alex Russell 
wrote:

> LGTM2
>
> On Wednesday, May 15, 2024 at 8:55:34 AM UTC-7 Yoav Weiss wrote:
>
>> LGTM1
>>
>> On Thursday, May 9, 2024 at 1:41:40 AM UTC+2 Stephen Chenney wrote:
>>
>>> Contact emailsschen...@chromium.org
>>>
>>> ExplainerNone
>>>
>>> Specificationhttps://www.w3.org/TR/css-pseudo-4/#highlight-selectors
>>>
>>> SummaryChromium currently checks all selection highlight colors against
>>> the text color and inverts the highlight color if it matches the text.
>>> Hence, author-defined ::selection CSS properties may be modified by the
>>> browser despite explicit author intent. For example, a CSS rule
>>> "::selection { color: cyan; background: cyan; }" the background is inverted
>>> and red color is used. In
>>> https://github.com/w3c/csswg-drafts/issues/6150 the CSS Working Group
>>> resolved to disallow the chromium behavior. We propose to implement this
>>> spec change and bring chromium into compatibility with other browsers.
>>>
>>> Blink componentBlink>CSS
>>> 
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Low risk. Gecko and WebKit both respect author colors from
>>> ::selection already. The change makes chromium compatible. It is highly
>>> unlikely that authors are depending on chromium behavior given it is hard
>>> to predict and the number of people who have looked at the workarounds.
>>> Note the workarounds (adding some transparency) will not be broken by the
>>> change.
>>>
>>>
>>> *Gecko*: Shipped
>>>
>>> *WebKit*: Shipped
>>>
>>> *Web developers*:
>>> https://stackoverflow.com/questions/14970891/css-selection-color-behaving-strangely-on-chrome
>>>
>>> *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
>>>
>>> Improved because the rendered result now matches the colors specified by
>>> authors and reported in DevTools.
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, ChromeOS, Android, and Android WebView)?Yes
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?Yes
>>>
>>> Flag name on chrome://flagsNone
>>>
>>> Finch feature nameSelectionRespectsColors
>>>
>>> Non-finch justification
>>>
>>> The change has been behind Experimental Web Platform Features for 4
>>> months, with no issues reported.
>>>
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://issues.chromium.org/issues/40771258
>>>
>>> Estimated milestones
>>> Shipping on desktop 127
>>> Shipping on Android 127
>>>
>>> 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/5657973985640448?gate=6583848377253888
>>>
>> --
> 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/c7dccb61-b1f7-4a88-b512-389beff7fa58n%40chromium.org
> 
> .
>

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

[blink-dev] Re: Intent to Ship: Stop modifying author-defined selection colors

[Alex Russell]

LGTM2

On Wednesday, May 15, 2024 at 8:55:34 AM UTC-7 Yoav Weiss wrote:

> LGTM1
>
> On Thursday, May 9, 2024 at 1:41:40 AM UTC+2 Stephen Chenney wrote:
>
>> Contact emailsschen...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://www.w3.org/TR/css-pseudo-4/#highlight-selectors
>>
>> SummaryChromium currently checks all selection highlight colors against 
>> the text color and inverts the highlight color if it matches the text. 
>> Hence, author-defined ::selection CSS properties may be modified by the 
>> browser despite explicit author intent. For example, a CSS rule 
>> "::selection { color: cyan; background: cyan; }" the background is inverted 
>> and red color is used. In https://github.com/w3c/csswg-drafts/issues/6150 
>> the CSS Working Group resolved to disallow the chromium behavior. We 
>> propose to implement this spec change and bring chromium into compatibility 
>> with other browsers.
>>
>> Blink componentBlink>CSS 
>> 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Low risk. Gecko and WebKit both respect author colors from 
>> ::selection already. The change makes chromium compatible. It is highly 
>> unlikely that authors are depending on chromium behavior given it is hard 
>> to predict and the number of people who have looked at the workarounds. 
>> Note the workarounds (adding some transparency) will not be broken by the 
>> change.
>>
>>
>> *Gecko*: Shipped
>>
>> *WebKit*: Shipped
>>
>> *Web developers*: 
>> https://stackoverflow.com/questions/14970891/css-selection-color-behaving-strangely-on-chrome
>>
>> *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
>>
>> Improved because the rendered result now matches the colors specified by 
>> authors and reported in DevTools.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>> Linux, ChromeOS, Android, and Android WebView)?Yes
>>
>> Is this feature fully tested by web-platform-tests 
>> 
>> ?Yes
>>
>> Flag name on chrome://flagsNone
>>
>> Finch feature nameSelectionRespectsColors
>>
>> Non-finch justification
>>
>> The change has been behind Experimental Web Platform Features for 4 
>> months, with no issues reported.
>>
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://issues.chromium.org/issues/40771258
>>
>> Estimated milestones
>> Shipping on desktop 127
>> Shipping on Android 127
>>
>> 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/5657973985640448?gate=6583848377253888
>>
>

-- 
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/c7dccb61-b1f7-4a88-b512-389beff7fa58n%40chromium.org.

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

[Chris Harrelson]

Hi,

I see the spec PR is still pending. Is there a reason it can't land before
shipping?

On Thu, May 9, 2024 at 12:23 PM 'Sahir Vellani' via blink-dev <
blink-dev@chromium.org> wrote:

> Done! I've updated the explainer as well as the links in the TAG review.
>
> On Thursday, May 9, 2024 at 8:51:02 AM UTC-7 jyas...@chromium.org wrote:
>
>> Oops, Ben's not at Microsoft anymore, so you've done the best you can
>> with the Mozilla and WebKit position requests. Thanks.
>>
>> On Thu, May 9, 2024 at 8:48 AM Jeffrey Yasskin 
>> wrote:
>>
>>> If you've moved the explainer, could you replace the content of
>>> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md
>>> with a pointer to the new location? Then people who follow the old links
>>> won't be confused. You can and should also update the links in
>>> https://github.com/w3ctag/design-reviews/issues/880, and @Ben Mathwig should
>>> update the links in
>>> https://github.com/mozilla/standards-positions/issues/715 and
>>> https://github.com/WebKit/standards-positions/issues/102.
>>>
>>> Thanks,
>>> Jeffrey
>>>
>>> On Wed, May 8, 2024 at 7:14 PM 'Sahir Vellani' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
 I've published the spec PR. Since I can't update the links in the
 original comment of this thread, I'd like to link the updated explainer
 here for visibility.  
 pointer-event-extensions/pointer-event-device-id-explainer.md
 at main · WICG/pointer-event-extensions (github.com)
 
 I have added comments to both request-for-positions informing of the
 changes to the API.
 Thanks for your comments Dan!

 On Wednesday, May 8, 2024 at 6:10:48 PM UTC-7 dan...@microsoft.com
 wrote:

> A non-blocking comment: now that the syntax has been changed I think
> it would be great if you could update the Explainer and the Mozilla and
> WebKit requests-for-position to reduce potential for confusion.
>
> Also, is there a reason the spec PR is still in Draft status? Could it
> be published so that there's no ambiguity for reviewers that this is
> (hopefully) moving forward imminently?
>
> -- Dan
>
> On Wednesday, May 8, 2024 at 2:00:38 PM UTC-7 sahir.vellani via
> Chromestatus wrote:
>
>> This is ready for another review :)
>>
> --
 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/52090dcd-f068-456d-be41-bfadbb9055d1n%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/6034517b-2f18-4f57-b36c-dc58cdce99afn%40chromium.org
> 
> .
>

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

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

[Daniel Bratell]

LGTM2

/Daniel

On 2024-05-15 07:13, Domenic Denicola wrote:

LGTM1.

I have a small non-blocking request: update your Chrome Status entry 
to avoid using ClassName.staticMethod() syntax for what appears to be 
an instance method. (See e.g. this related discussion 
 and this bug I filed on 
Chrome Status a year ago 
.) 
This will avoid a confusing experience for web developers when this 
information makes its way into the beta blog post and other documentation.


On Wednesday, May 15, 2024 at 5:49:30 AM UTC+9 Eugene Zemtsov wrote:

By reading an MDN article that I'll update after the launch.

Even now allocationSize() is supposed to be called before copyTo()
anyway, to figure out the size of the buffer for the output. (see
example

1,
example2
)

That's why I don't think that it's an ergonomic burden for
developers.

On Tue, May 14, 2024 at 1:41 PM Mike Taylor
 wrote:

Ergonomics-wise, it does not seem intuitive to use a method
called allocationSize() to feature detect copyTo support, even
if the semantics are the same. Besides a very careful reading
of the spec, how do we expect developers to know about it?

On 5/14/24 4:32 PM, Eugene Zemtsov wrote:

In that discussion Marcos Cáceres asked for a synchronous way
to detect if format conversion is supported.
We have a synchronous call allocationSize()
 that
throws an unsupported error in cases where format conversion
is not supported.
I added a WPT test around it in a recent CL
.

canCopyTo() might be needed if we have more settings in
VideoFrameCopyToOptions
 and
might want to know which part exactly is causing an error.

On Tue, May 14, 2024 at 12:25 PM Mike Taylor
 wrote:

I see that WebKit raised an API concern around
detectability

.
In your reply, you said "we should consider...". Has that
consideration happened, perhaps as follow-up work? :)

On 5/8/24 4:05 PM, Eugene Zemtsov wrote:

This feature has Privacy, Security, Enterprise, and
Debuggability approvals. Webkit gave a positive signal.

Any objections or questions from the API owners?



On Wed, May 1, 2024 at 4:26 PM Eugene Zemtsov
 wrote:

I've filed issues for TAG review and firefox and
webkit positions.

>  Have you looked into other platform APIs that
could benefit from being able to explicitly specify
intermediate format hinting and/or transformation?
I don't think this kind of review can be done for
all web APIs by one person. It's up to spec
editors in each area to identify these small changes
that improve dev experience and performance.

For media related things:
- VideoFrame is a versatile tool that can be created
from HTMLOrSVGImageElement, HTMLVideoElement,
HTMLCanvasElement, ImageBitmap,
         OffscreenCanvaswithout a copy. In a way
this change extends variety of export formatsfor all
of them.
  So lots of things can be exported to RGB bitmaps
without a canvas now.
- AudioData has a way to be exported into different
sampling formats.



On Wed, May 1, 2024 at 9:41 AM Mike Taylor
 wrote:

+1. Would you mind also filing gecko and webkit
positions? I expect them to be positive, given
the informal signals you have in the spec PRs
already - but this also lets them know we're
moving ahead with shipping. Thanks - Mike

On 5/1/24 11:51 AM, Alex Russell wrote:

hey Eugene,

This is an exciting an useful addition! Have
you looked into other platform APIs that could
benefit from being able to explicitly specify
intermediate format hinting and/or
transformation? It's a place where (had the TAG
been consulted) I would have expected to see a
  

Re: [blink-dev] Request for Deprecation Trial: Media Previews opt-out

[Yoav Weiss (@Shopify)]

Can you expand on how (if) this is different from the past intent 

 
with a similar title?

On Monday, May 13, 2024 at 7:21:48 PM UTC+2 Mike Taylor wrote:

> FWIW, a deprecation trial can surpass 6 milestones - but they require 
> sufficient justification as well as 3 LGTMs. 
>
> That said, I'm not sure I understand the request here. I read the linked 
> "Chrome Camera and Mic Previews" document, but I think the Rollout plan 
> section is assuming more info than I have. Could you explain how this 
> feature and PEPC relate, and why having them work together is a bad thing? 
> Do you plan to deprecate one of the features once the Deprecation Trial is 
> finished? (Or are you just requesting an Origin Trial to temporarily 
> disable something, and expect it to be re-enabled in the future?)
>
> Something that approaches an Explainer would probably be helpful here - 
> thanks!
>
> On 5/10/24 5:05 PM, mark a. foltz wrote:
>
> I'm fine with shortening the trial, as long as extensions are possible in 
> case we need longer to ship a long-term solution.
>
> On Fri, May 10, 2024 at 12:39 PM Vladimir Levin  
> wrote:
>
>>
>>
>> On Fri, May 10, 2024 at 2:40 PM mark a. foltz  
>> wrote:
>>
>>> Contact emails mfo...@chromium.org, bryantchand...@chromium.org
>>>
>>> Explainer None
>>>
>>> Specification 
>>> https://docs.google.com/document/d/1ZnX2JROjr9l4y2_OPMpfVlLOo-A5cQzD4mWarj9kXQ0/edit
>>>
>>> Design docs 
>>>
>>> https://docs.google.com/document/d/1ZnX2JROjr9l4y2_OPMpfVlLOo-A5cQzD4mWarj9kXQ0/edit
>>>
>>> Summary 
>>>
>>> Allow coordination between sites using Page Embedded Permissions 
>>> Controls and concurrent experiments with the camera and microphone 
>>> permissions UI in Chrome.
>>>
>>>
>>> Blink component Blink>MediaStream 
>>> 
>>>
>>> TAG review None
>>>
>>> TAG review status Not applicable
>>>
>>> Chromium Trial Name MediaPreviewsOptOutPersistent
>>>
>>> Origin Trial documentation link 
>>> https://docs.google.com/document/d/1ZnX2JROjr9l4y2_OPMpfVlLOo-A5cQzD4mWarj9kXQ0/edit?usp=sharing
>>>
>>> WebFeature UseCounter name kOBSOLETE_PageDestruction
>>>
>>> Risks 
>>>
>>>
>>> Interoperability and Compatibility 
>>>
>>> None as this feature concerns the functionality of Chrome's permissions 
>>> UI, and does not change the behavior of the APIs that are gated by it: 
>>> navigator.mediaDevices.enumerateDevices and 
>>> navigator.mediaDevices.getUserMedia Other browsers implement their own 
>>> permissions UIs independently of Chrome. 
>>>
>>>
>>> *Gecko*: N/A
>>>
>>> *WebKit*: N/A
>>>
>>> *Web developers*: No signals
>>>
>>> *Other signals*:
>>>
>>> Ergonomics 
>>>
>>> N/A
>>>
>>>
>>> Activation 
>>>
>>> N/A
>>>
>>>
>>> Security 
>>>
>>> N/A
>>>
>>>
>>> WebView application risks 
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such 
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> None
>>>
>>>
>>> Goals for experimentation 
>>>
>>> Ongoing technical constraints 
>>>
>>> There are no plans to add media previews to Chrome on platforms other 
>>> than Windows/Mac/Linux.
>>>
>>>
>>> Debuggability 
>>>
>>> N/A
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>>> Linux, ChromeOS, Android, and Android WebView)? No 
>>>
>>> There are currently no plans to launch previews outside of 
>>> Windows/Mac/Linux.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests 
>>> 
>>> ? No 
>>>
>>> N/A
>>>
>>>
>>> DevTrial instructions https://tinyurl.com/yc6mvth8
>>>
>>> Flag name on chrome://flags --enable-features=camera-mic-preview
>>>
>>> Finch feature name CameraMicPreview
>>>
>>> Requires code in //chrome? False
>>>
>>> Tracking bug https://issues.chromium.org/330762482
>>>
>>> Launch bug https://launch.corp.google.com/launch/4304480
>>>
>>> Estimated milestones 
>>> Origin trial desktop first 126 
>>> Origin trial desktop last 137 
>>> DevTrial on desktop 122 
>>>
>>
>> According to 
>> https://www.chromium.org/blink/launching-features/#deprecation-trial, 
>> deprecation trials should only run for up to 6 milestones before an 
>> extension is required, so this may need to be adjusted
>>
>>
>>>
>>> Link to entry on the Chrome Platform Status 
>>> https://chromestatus.com/feature/5100528783851520?gate=5123374989967360
>>>
>>> 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 
>>> 

[blink-dev] Re: Intent to Ship: Stop modifying author-defined selection colors

[Yoav Weiss (@Shopify)]

LGTM1

On Thursday, May 9, 2024 at 1:41:40 AM UTC+2 Stephen Chenney wrote:

> Contact emailsschen...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://www.w3.org/TR/css-pseudo-4/#highlight-selectors
>
> SummaryChromium currently checks all selection highlight colors against 
> the text color and inverts the highlight color if it matches the text. 
> Hence, author-defined ::selection CSS properties may be modified by the 
> browser despite explicit author intent. For example, a CSS rule 
> "::selection { color: cyan; background: cyan; }" the background is inverted 
> and red color is used. In https://github.com/w3c/csswg-drafts/issues/6150 
> the CSS Working Group resolved to disallow the chromium behavior. We 
> propose to implement this spec change and bring chromium into compatibility 
> with other browsers.
>
> Blink componentBlink>CSS 
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> Low risk. Gecko and WebKit both respect author colors from 
> ::selection already. The change makes chromium compatible. It is highly 
> unlikely that authors are depending on chromium behavior given it is hard 
> to predict and the number of people who have looked at the workarounds. 
> Note the workarounds (adding some transparency) will not be broken by the 
> change.
>
>
> *Gecko*: Shipped
>
> *WebKit*: Shipped
>
> *Web developers*: 
> https://stackoverflow.com/questions/14970891/css-selection-color-behaving-strangely-on-chrome
>
> *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
>
> Improved because the rendered result now matches the colors specified by 
> authors and reported in DevTools.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, ChromeOS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests 
> 
> ?Yes
>
> Flag name on chrome://flagsNone
>
> Finch feature nameSelectionRespectsColors
>
> Non-finch justification
>
> The change has been behind Experimental Web Platform Features for 4 
> months, with no issues reported.
>
>
> Requires code in //chrome?False
>
> Tracking bughttps://issues.chromium.org/issues/40771258
>
> Estimated milestones
> Shipping on desktop 127
> Shipping on Android 127
>
> 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/5657973985640448?gate=6583848377253888
>

-- 
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/357a778c-cd0e-4468-9c90-2dc48e051a24n%40chromium.org.

Re: [blink-dev] Re: Intent to Experiment: Element Capture

[Yoav Weiss (@Shopify)]

LGTM3

On Tue, May 14, 2024 at 8:40 PM Chris Harrelson 
wrote:

> LGTM2
>
> On Tue, May 14, 2024 at 11:36 AM Mike Taylor 
> wrote:
>
>> OK - thanks for the clarification. I would ask that you get in touch with
>> every registered origin - expiring the experiment early may be surprising.
>>
>> LGTM1 to experiment from M127 to M132 inclusive.
>> On 5/14/24 12:08 PM, Elad Alon wrote:
>>
>> I'm asking for a break-off period starting July 1 and ending July 22
>> (inclusive). That means that the original trial will end on June 30, and be
>> restarted on July 23. This corresponds to breaking the original experiment
>> early during the cycle of what would have otherwise been its final
>> milestone (m126), the restarting the experiment over the m127-m132 range.
>> (CC Panos for feasibility.)
>>
>> On Friday, May 10, 2024 at 10:25:03 PM UTC+2 mike...@chromium.org wrote:
>>
>>> Note: Because you're asking for a renewal of 6 milestones, this will
>>> require 3 LGTMs.
>>>
>>> Can you clarify which milestones you're asking for? You've written
>>> "(2024-May-14 to 2024-Jun-04)" - that range maps to M125 and M126 stable
>>> releases.
>>> On 5/10/24 6:44 AM, 'Elad Alon' via blink-dev wrote:
>>>
>>> Hello Blink owners,
>>>
>>> We are asking for a breaking period of 3 weeks to this API, followed by
>>> a renewed experiment for the traditional 6 milestones (2024-May-14 to
>>> 2024-Jun-04). A request
>>> 
>>> that seems similar to me was granted in January 2022 for another API, and
>>> later shipped successfully with consensus with Mozilla and Apple.
>>>
>>> At the time of writing, we have public support
>>> 
>>> for this API from such companies as Zoom, Jitsi, Mux, DialPad, Whereby,
>>> Intel and Tella. Tango’s co-founder wrote
>>> 
>>> “I can't emphasize enough how instrumental this specification would be for
>>> our product and user experience.” However, none of them have signed up for
>>> the OT as of yet.
>>>
>>> From the OT perspective:
>>>
>>> This API allows Web developers to build novel new features; however, it
>>> requires a non-trivial investment. We are hoping that after giving more
>>> time, we will see more participation.
>>>
>>> From the standardization perspective:
>>>
>>> We need time to pick up discussions with Mozilla and Apple again. As
>>> Chrome’s Security and Privacy experts do not share the concerns Mozilla and
>>> Apple have previously voiced, it stands to reason that additional
>>> discussions will allow us to converge - and we will prioritize these
>>> discussions now.
>>>
>>> Additionally, some possibilities remain for API changes that could
>>> perhaps allow for a compromise, mostly around cross-origin isolation. (Full
>>> disclosure - this is not my ideal outcome, but it’s a fallback possibility
>>> worth mentioning.)
>>>
>>> Progress made:
>>>
>>>-
>>>
>>>Spec: The spec has evolved and is now more mature, dealing better
>>>with such edge cases as loss of “eligibility for restriction.”
>>>-
>>>
>>>TAG: Previously we held off on the request for a TAG review until we
>>>got some more developer feedback about the API shape. Having received 
>>> this
>>>initial feedback, the TAG request
>>> has now been
>>>submitted.
>>>-
>>>
>>>Signals: Signals have been requested. Mozilla responded. We intend
>>>to prioritize this discussion with them now.
>>>-
>>>
>>>Feedback: Outreach for feedback from the spec community - multiple
>>>issues
>>>
>>>were filed on the spec by Web developers.
>>>-
>>>
>>>WPT: Coverage has recently been extended
>>>
>>> 
>>>.
>>>
>>>
>>> Reasons to run a new trial:
>>>
>>> Gain additional feedback from new participants. Examples for remaining
>>> areas where new feedback could help include:
>>>
>>>-
>>>
>>>Uncover new edge cases which were not uncovered by the spec authors
>>>and reviewers, implementers and current OT participants. The current edge
>>>cases here
>>>
>>> 
>>>demonstrate how non-obvious these may be.
>>>-
>>>
>>>Validate (or refute) the assumptions we have made about the
>>>viability of an MVP that is missing some functionality. Examples:
>>>-
>>>
>>>   Events notifying apps when an element stops/starts being
>>>   “eligible for restriction”.
>>>   -
>>>
>>>   Mechanism to force elements into 

Re: [blink-dev] Intent to Prototype: Find-in-page highlight pseudos

[Daniel Bratell]

I appreciate that someone is working on this because Chromium has 
atrociously bad search hit highlights. That said, I wonder if it would 
be better fixing Chromium than the web. There are a lot of web pages out 
and this could at best help those with very active ongoing development.


/Daniel

On 2024-05-03 15:27, Delan Azabani wrote:



*Contact emails
*schen...@chromium.org, dazab...@igalia.com


*Explainer

*https://github.com/Igalia/explainers/blob/66623464ba1f2410a130d687116302b4a30b1148/css/find-in-page/README.md




*Specification
*None yet; to be specified in
https://drafts.csswg.org/css-pseudo/#highlight-pseudos



*Summary
*Exposes find-in-page search results to authors as a highlight
pseudo-element, like selections and spelling errors. This
allows authors to change the foreground and background colors
or add text decorations, which can be especially useful if the
UA defaults have insufficient contrast with the page colors or
are otherwise unsuitable.


*Blink component
*Blink>CSS




*Motivation
*Authors would like to customize the highlighted text from
find-in-page to have a style consistent with that of the rest
of the page. In particular, the existing find-in-page
highlights may offer poor contrast, harming accessibility. The
find-in-page highlights may also conflict with other
highlights on the page, such as syntax highlighting.


*Initial public proposal
*https://github.com/w3c/csswg-drafts/issues/3812



*Search tags
*search 


*TAG review
*None


*TAG review status
*Pending


*Risks*


*Interoperability and Compatibility
*None

/Gecko/: Not yet requested

/WebKit/: Not formally requested, but feedback on the CSS WG issue and 
in meetings. Unlikely to implement due to Safari’s unique UI behavior, 
but not opposed to the spec as long as UAs are allowed to parse but 
ignore the pseudo. CSS Working Group discussed and is OK with moving 
forward with prototyping under these conditions.


/Web developers/: Resolve problems with choosing code syntax 
highlighting colors 
https://github.com/w3c/csswg-drafts/issues/3812#issuecomment-1703272181 
; 
Explicit request for the feature How to style/detect highlighted boxes 
generated from browser native search in page - Stack Overflow 
; 
Another use case Confuse browsers in-built "find in page" feature - 
Stack Overflow 



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

*?
*Not yet; tests will be written during the spec and impl process


*Flag name on chrome://flags
*#enable-experimental-web-platform-features
SearchTextHighlightPseudo


*Finch feature name
*None


*Non-finch justification
*None


*Requires code in //chrome?
*False


*Estimated milestones
*No milestones specified


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


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/c447ed4dfd05b588e2afc650277371fd%40igalia.com 
.


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

Re: [blink-dev] Re: Intent to Ship: WebRTC encoded transform - Constructor with custom Metadata (originally Modify Metadata functions)

[Daniel Bratell]

LGTM3

/Daniel

On 2024-05-15 15:47, Guido Urdaneta wrote:

I just opened access to the doc.

On Wed, May 15, 2024 at 2:57 PM Daniel Bratell wrote:

The document seems to be an internal one. Is there anything you
can share publicly?

/Daniel

On 2024-05-15 07:34, Domenic Denicola wrote:

LGTM2

On Wednesday, May 15, 2024 at 4:47:32 AM UTC+9 Mike Taylor wrote:

Thanks for the doc. It sounds like the design evolved during
the OT based on fedback from the WG, and at least one partner
was satisfied with the shape and functionality.

LGTM1

On 5/14/24 8:05 AM, Guido Urdaneta wrote:

Here is a doc with feedback from the Origin Trial. There
were two registrants reported with a large usage scale. We
received feedback from one of them and will update the doc
if/when we get feedback from the other one.


https://docs.google.com/document/d/1QSYbrlgE_6ZZag_VRd8Mn863Slb5-GLlJ_-X4WOiym0/edit?usp=sharing


On Wed, May 8, 2024 at 5:45 PM Alex Russell
 wrote:

Hey Guido,

This is a cool feature! The Milestones section shows
that an OT was run; is there a summary someplace of what
we learned from the OT?

Best,

Alex

On Thursday, May 2, 2024 at 4:40:31 AM UTC-7 Guido
Urdaneta wrote:


Contact emails


h...@chromium.org, gui...@chromium.org,
agpa...@chromium.org


Explainer



https://github.com/guidou/webrtc-extensions/blob/main/constructor-explainer.md


Specification



https://w3c.github.io/webrtc-encoded-transform/#dom-rtcencodedvideoframe-constructor



https://w3c.github.io/webrtc-encoded-transform/#dom-rtcencodedaudioframe-constructor


Summary


Allow WebRTC Encoded Transform API to create
encoded audio and video frames specifying
custom metadata. This is achieved by
introducing constructors for encoded frames
that take the original frame and custom
metadata as input. This supports use cases
that involve manipulation of not only the
payload of encoded video / audio frames but
also its metadata. Some examples: * Changing
the mime type of the frame if the transform
changes the type of the payload * Forwarding
of media to a new peer connection set up to
use different metadata values * Altering the
timestamp of a frame to introduce a delay
Use cases:

https://w3c.github.io/webrtc-nv-use-cases/#live-encoded-media

https://w3c.github.io/webrtc-nv-use-cases/#stored-encoded-media
https://w3c.github.io/webrtc-nv-use-cases/#auction
Issue link:
https://github.com/w3c/webrtc-nv-use-cases/issues/77



This change has consensus in the WebRTC Working
Group and has been merged into the WebRTC Encoded
Transform spec.


Blink component


Blink>WebRTC




TAG review


TAG review request for this specific change:
https://github.com/w3ctag/design-reviews/issues/942


The original version of the full spec was
reviewed by TAG here:
https://github.com/w3ctag/design-reviews/issues/531


TAG review status


Pending


Chromium Trial Name


RTCEncodedFrameSetMetadata


Origin Trial documentation link



https://github.com/palak8669/webrtc-encoded-transform/blob/create-encoded-explainer/create-encoded-explainer.md


WebFeature UseCounter name


RTCEncodedFrameSetMetadata


Risks




Interoperability and Compatibility


Interoperability risk: There is always the
risk that other browsers will not implement
this feature. This risk is mitigated by
alignment across browser vendors in the W3C
WebRTC Working Group around the spec.

Re: [blink-dev] Re: Intent to Ship: WebRTC encoded transform - Constructor with custom Metadata (originally Modify Metadata functions)

[Guido Urdaneta]

I just opened access to the doc.

On Wed, May 15, 2024 at 2:57 PM Daniel Bratell  wrote:

> The document seems to be an internal one. Is there anything you can share
> publicly?
>
> /Daniel
> On 2024-05-15 07:34, Domenic Denicola wrote:
>
> LGTM2
>
> On Wednesday, May 15, 2024 at 4:47:32 AM UTC+9 Mike Taylor wrote:
>
>> Thanks for the doc. It sounds like the design evolved during the OT based
>> on fedback from the WG, and at least one partner was satisfied with the
>> shape and functionality.
>>
>> LGTM1
>> On 5/14/24 8:05 AM, Guido Urdaneta wrote:
>>
>> Here is a doc with feedback from the Origin Trial. There were two
>> registrants reported with a large usage scale. We received feedback from
>> one of them and will update the doc if/when we get feedback from the other
>> one.
>>
>>
>> https://docs.google.com/document/d/1QSYbrlgE_6ZZag_VRd8Mn863Slb5-GLlJ_-X4WOiym0/edit?usp=sharing
>>
>>
>> On Wed, May 8, 2024 at 5:45 PM Alex Russell 
>> wrote:
>>
>>> Hey Guido,
>>>
>>> This is a cool feature! The Milestones section shows that an OT was run;
>>> is there a summary someplace of what we learned from the OT?
>>>
>>> Best,
>>>
>>> Alex
>>>
>>> On Thursday, May 2, 2024 at 4:40:31 AM UTC-7 Guido Urdaneta wrote:
>>>
 Contact emails h...@chromium.org, gui...@chromium.org,
 agpa...@chromium.org

 Explainer
 https://github.com/guidou/webrtc-extensions/blob/main/constructor-explainer.md

 Specification
 https://w3c.github.io/webrtc-encoded-transform/#dom-rtcencodedvideoframe-constructor
 https://w3c.github.io/webrtc-encoded-transform/#dom-rtcencodedaudioframe-constructor

 Summary

 Allow WebRTC Encoded Transform API to create encoded audio and video
 frames specifying custom metadata. This is achieved by introducing
 constructors for encoded frames that take the original frame and custom
 metadata as input. This supports use cases that involve manipulation of not
 only the payload of encoded video / audio frames but also its metadata.
 Some examples: * Changing the mime type of the frame if the transform
 changes the type of the payload * Forwarding of media to a new peer
 connection set up to use different metadata values * Altering the timestamp
 of a frame to introduce a delay
 Use cases:
 https://w3c.github.io/webrtc-nv-use-cases/#live-encoded-media
 https://w3c.github.io/webrtc-nv-use-cases/#stored-encoded-media
 https://w3c.github.io/webrtc-nv-use-cases/#auction Issue link:
 https://github.com/w3c/webrtc-nv-use-cases/issues/77

 This change has consensus in the WebRTC Working Group and has been
 merged into the WebRTC Encoded Transform spec.

 Blink component Blink>WebRTC
 

 TAG review TAG review request for this specific change:
 https://github.com/w3ctag/design-reviews/issues/942  The original
 version of the full spec was reviewed by TAG here:
 https://github.com/w3ctag/design-reviews/issues/531

 TAG review status Pending

 Chromium Trial Name RTCEncodedFrameSetMetadata

 Origin Trial documentation link
 https://github.com/palak8669/webrtc-encoded-transform/blob/create-encoded-explainer/create-encoded-explainer.md

 WebFeature UseCounter name RTCEncodedFrameSetMetadata

 Risks


 Interoperability and Compatibility

 Interoperability risk: There is always the risk that other browsers
 will not implement this feature. This risk is mitigated by alignment across
 browser vendors in the W3C WebRTC Working Group around the spec.
 Compatibility risk: This is a new feature intended to support new use
 cases. It introduces no breaking changes, so we do not expect any
 compatibility issues.

 *Gecko*: No signal (
 https://github.com/mozilla/standards-positions/issues/1009) During
 WebRTC WG meetings, Mozilla has shown positive signals and agreed with
 merging the PR in the main spec. See the exchange in
 https://github.com/w3c/webrtc-encoded-transform/pull/223

 *WebKit*: Positive (
 https://github.com/WebKit/standards-positions/issues/334)
 Marked as "Invalid" in the position request because this is a small
 change and the position was addressed in the PR review. The comments from
 WebKit in the PR review and during WebRTC WG meetings are positive and they
 have agreed with merging the PR in the main spec. See the exchange in
 https://github.com/w3c/webrtc-encoded-transform/pull/223

 *Web developers*: Positive

 *Other signals*:

 Ergonomics

 This feature is an extension to WebRTC Encoded Transform, which itself
 is an extension to WebRTC/RTCPeerConnection.


 Activation

 No significant risks identified.


 Security

 No new security risks identified.


 WebView 

Re: [blink-dev] Re: Intent to Ship: WebRTC encoded transform - Constructor with custom Metadata (originally Modify Metadata functions)

[Daniel Bratell]

The document seems to be an internal one. Is there anything you can 
share publicly?


/Daniel

On 2024-05-15 07:34, Domenic Denicola wrote:

LGTM2

On Wednesday, May 15, 2024 at 4:47:32 AM UTC+9 Mike Taylor wrote:

Thanks for the doc. It sounds like the design evolved during the
OT based on fedback from the WG, and at least one partner was
satisfied with the shape and functionality.

LGTM1

On 5/14/24 8:05 AM, Guido Urdaneta wrote:

Here is a doc with feedback from the Origin Trial. There were two
registrants reported with a large usage scale. We received
feedback from one of them and will update the doc if/when we get
feedback from the other one.


https://docs.google.com/document/d/1QSYbrlgE_6ZZag_VRd8Mn863Slb5-GLlJ_-X4WOiym0/edit?usp=sharing




On Wed, May 8, 2024 at 5:45 PM Alex Russell
 wrote:

Hey Guido,

This is a cool feature! The Milestones section shows that an
OT was run; is there a summary someplace of what we learned
from the OT?

Best,

Alex

On Thursday, May 2, 2024 at 4:40:31 AM UTC-7 Guido Urdaneta
wrote:


Contact emails


h...@chromium.org, gui...@chromium.org
,
agpa...@chromium.org 


Explainer



https://github.com/guidou/webrtc-extensions/blob/main/constructor-explainer.md




Specification



https://w3c.github.io/webrtc-encoded-transform/#dom-rtcencodedvideoframe-constructor





https://w3c.github.io/webrtc-encoded-transform/#dom-rtcencodedaudioframe-constructor




Summary


Allow WebRTC Encoded Transform API to create
encoded audio and video frames specifying custom
metadata. This is achieved by introducing
constructors for encoded frames that take the
original frame and custom metadata as input. This
supports use cases that involve manipulation of
not only the payload of encoded video / audio
frames but also its metadata. Some examples: *
Changing the mime type of the frame if the
transform changes the type of the payload *
Forwarding of media to a new peer connection set
up to use different metadata values * Altering
the timestamp of a frame to introduce a delay
Use cases:

https://w3c.github.io/webrtc-nv-use-cases/#live-encoded-media



https://w3c.github.io/webrtc-nv-use-cases/#stored-encoded-media


https://w3c.github.io/webrtc-nv-use-cases/#auction

Issue link:
https://github.com/w3c/webrtc-nv-use-cases/issues/77




This change has consensus in the WebRTC Working Group and
has been merged into the WebRTC Encoded Transform spec.


Blink component


Blink>WebRTC




TAG review


TAG review request for this specific change:
https://github.com/w3ctag/design-reviews/issues/942



The original version of the full spec was
reviewed by TAG here:
https://github.com/w3ctag/design-reviews/issues/531



TAG review status


Pending


Chromium Trial Name


RTCEncodedFrameSetMetadata


Origin Trial documentation link



https://github.com/palak8669/webrtc-encoded-transform/blob/create-encoded-explainer/create-encoded-explainer.md

[blink-dev] Re: Intent to Ship: Protected Audience: reporting timeouts & multiple-bids

[Yoav Weiss (@Shopify)]

On Monday, May 6, 2024 at 10:03:16 PM UTC+2 Paul Jensen wrote:

Contact emails

pauljen...@chromium.org


Explainer

Protected Audience reporting timeouts: https://github.com/WICG/
turtledove/pull/1101

Protected Audience multiple-bids: https://github.com/WICG/
turtledove/pull/1048


Specification

Protected Audience reporting timeouts: https://github.com/WICG/
turtledove/pull/1102

Protected Audience multiple-bids: https://github.com/WICG/
turtledove/pull/1138


Summary

Protected Audience (PA) reporting timeouts:

After a PA auction finishes selecting an ad and that ad is allowed to start 
rendering, the browser then runs a JavaScript function from the seller(s) 
and winning buyer to assemble reports that are sent back to their servers. 
These functions are currently given 50ms to run, after which they're 
aborted. We've heard feedback from users of the API that 50ms may not be 
sufficient to assemble the reports and may result in broken billing and 
other basic functionality, resulting in lower website revenue.  We’re 
proposing making the timeout configurable up to 5s. (This JavaScript 
generally runs in a separate process, i.e. off the main thread.)


I'm concerned about this timeout, tbh.
It feels very arbitrary and if set by the wrong party, it can create some 
adversarial effects.
Can you expand on why do we need a configurable timeout here, rather than 
just increasing it for everyone?
If a configurable timeout is indeed needed, am I correct that the timeout 
would be set by the publisher, and its consequences would be felt by the 
seller?

Also, can you expand on "This JavaScript generally runs in a separate 
process"? Where is it run?


Protected Audience multiple-bids:

Presently buyers participating in PA ad selection auctions are only allowed 
to return one bid per interest group stored on a user's device. This has a 
couple downsides:

   1. 
   
   When that one bid does not pass the k-anonymity threshold, the bid 
   generation logic must be invoked again which can be slow, potentially 
   doubling auction runtime.
   2. 
   
   This preferences adtechs that store more interest groups on device as a 
   way to get more bids into the auction. Many interest groups on device is 
   something we publicly have stated is undesirable: 
   https://developers.google.com/privacy-sandbox/relevance/
   protected-audience-api/latency#fewer_interest_group_owners 
   

   
To fix this we're allowing bidding scripts to return multiple bids.


Blink component

Blink>InterestGroups 



TAG review

For Protected Audience: https://github.com/w3ctag/design-reviews/issues/723


TAG review status

Completed for Protected Audience, resolved unsatisfied.


RisksInteroperability and Compatibility

Both features represent optional new behavior that shouldn’t break existing 
usage.


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


Edge: Edge has announced plans to support the Ad Selection API 
 which 
shares much of its API surface with Protected Audience.


I'd love for the Edge team to review this, if at all possible.
I know it's exceeding the bounds of our process, but given the lack of 
interest in reviewing this from the TAG, Mozilla and Apple, and the ongoing 
complexity of this feature, it's be great to try and get some deep 
technical review from a different browser team.
 


Web developers:

Protected Audience reporting timeouts: Multiple companies requesting on Github 
issue  and WICG meeting 
though notes 

 
are missing several comments from others.

Protected Audience multiple-bids: 3+ companies requesting on Github issue 
, discussed in 6 different WICG 
meetings 

.


Debuggability

PA reporting and bidding scripts are debuggable in DevTools.  Generated 
bids also show up in the Application -> Storage -> Interest Groups DevTools 
pane.


Will this feature be supported on all six Blink platforms (Windows, Mac, 
Linux, ChromeOS, 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