[blink-dev] Re: Intent to Implement: WebGL drawingBufferStorage

[Ken Russell]

Thank you Chris for implementing this and driving the spec forward! API
owners, hoping for your approval to implement this long-awaited feature.

-Ken



On Wed, Sep 20, 2023 at 4:08 AM Christopher Cameron 
wrote:

> Contact emailsccame...@chromium.org
>
> Specificationhttps://github.com/KhronosGroup/WebGL/pull/3222
>
> Summary
>
> Allows WebGL to specify the format of its backbuffer. In particular,
> allows floating-point (for use with wide color and high dynamic range) and
> sRGB-encoded (for 8-bit physically based rendering) framebuffers.
>
>
> Blink componentBlink>WebGL
> 
>
> Motivation
>
> This is required for HDR support in WebGL and has been requested by
> several partners.
>
> TAG reviewN/A
>
> Risks
>
>
> Interoperability and Compatibility
>
> None.
>
>
> *Gecko*: Positive Feature authored by Mozilla.
>
> *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
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
> No, WebGL is tested using the WebGL conformance tests.
>
> Flag name on chrome://flagsNone
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?No
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5146687245123584
>

-- 
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/CAMYvS2d4eUPWOUjstZw0O5rj2qr3t%3DB%2B-n%2B6DsfYjDHsYuBPLg%40mail.gmail.com.

[blink-dev] Intent to Ship: Protected Audiences Negative Targeting

['Orr Bernstein' via blink-dev]

Contact emails

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

Explainer

https://github.com/WICG/turtledove/pull/780

Specification

https://github.com/WICG/turtledove/pull/796

Summary

In online ad auctions for ad space, it’s sometimes useful to prevent 
showing an ad to certain audiences, a concept known as negative targeting. 
For example, you might not want to show a new customer advertisement to 
existing customers. New customer acquisition campaigns most often have this 
as a critical requirement. Protected Audience currently enables ads to 
target users that have been joined to a given interest group through some 
past activity on the web. This feature extends Protected Audience to enable 
negative targeting by allowing new ads to target only those users who have 
not been joined to a given interest group. In this way, we're enabling 
advertisers to target new groups of users using the existing 
privacy-preserving concepts of the Protected Audience API.


Blink component

Blink>InterestGroups 


TAG review

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

TAG review status

Pending

Risks

Interoperability and Compatibility

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

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

Web developers: Adtech asked for this via Protected Audience Github issue 
#319 .


Debuggability

Additional bids sent into the auction are visible in their response headers 
via DevTools. You can determine if the additional bid was sent for scoring 
by adding a breakpoint in the scoring script in DevTools. Error scenarios, 
e.g. signature verification errors and joining origin mismatch on negative 
interest groups - are written to the console. We're considering additional 
DevTools enhancements to aid additional bids debugging.

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

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

Is this feature fully tested by web-platform-tests 

?

We plan to add WPTs to cover this API in the next month.

Flag name on chrome://flags

None

Finch feature name

FledgeNegativeTargeting

Requires code in //chrome?

False

Estimated milestones

Shipping on desktop and Android in M118.

Anticipated spec changes

None related to this feature.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5021508157571072

This intent message was generated by Chrome Platform Status 
.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5ebd44f6-57b2-448f-b32c-87d63acfa471n%40chromium.org.

Re: [blink-dev] Intent to Ship: Protected Audience directFromSellerSignals via HTTP response headers

[Caleb Raitto]

Will do (once spec reviewers have approved) -- I understand your LGTM is 
contingent on those landing.

Thanks, 
-Caleb

On Wednesday, September 20, 2023 at 3:07:11 PM UTC-4 Mike Taylor wrote:

> And gentle reminder to please land the spec PRs :)
> On 9/20/23 12:54 PM, Chris Harrelson wrote:
>
> LGTM3
>
> On Wed, Sep 20, 2023 at 9:53 AM Yoav Weiss  wrote:
>
>> LGTM2 
>>
>> Talking to the team, the 10K limit is Finchable, so we'd be able to lower 
>> it if this runs into issues in the field. Also presumably, having that as a 
>> limit doesn't mean most responses would actually use that.
>>
>> On Sat, Sep 16, 2023 at 6:52 AM Yoav Weiss  
>> wrote:
>>
>>>
>>>
>>>
>>> On Fri, Sep 15, 2023 at 10:00 PM Mike Taylor  
>>> wrote:
>>>
 Thanks, LGTM1 pending the PRs landing.
 On 9/12/23 12:29 AM, Caleb Raitto wrote:

 Hi Mike,

 Pull request 695  is the 
 change to update the explainer to describe the new header-based 
 directFromSellerSignals, whereas 771 
  and 774 
  are for the spec changes.

 The explainer change describes usage of the new API and provides 
 context for the differences between header-based and the prior bundles 
 based versions of directFromSellerSignals, whereas the spec change 
 describes how to implement the header-based version.

 We intend to land all 3 pull requests.

 Thanks,

 -Caleb
 On Monday, September 11, 2023 at 11:18:26 AM UTC-4 Mike Taylor wrote:

>
> On 9/11/23 12:55 PM, Mike Taylor wrote:
>
> On 9/7/23 6:00 PM, Caleb Raitto wrote:
>
> Hi Yoav, some responses inline:
>
> On Wednesday, September 6, 2023 at 12:15:45 PM UTC-4 Yoav Weiss wrote:
>
> On Tue, Sep 5, 2023 at 9:55 PM Paul Jensen  
> wrote:
>
> Contact emails
>
>
> * pauljen...@chromium.org  *Explainer
>
> * https://github.com/WICG/turtledove/pull/69 
> 5 *
>
>
> Can you clarify what this does, as the explainer is not very explain-y?
>
> IIUC, the current flow to get directFromSellerSignals is to download a 
> response A which contains a link to a WBN, then download the WBN and that 
> contains the signal info.
> Your proposal is to change that so that the directFromSellerSignals 
> information would be embedded in a response header on response A?
>
>
> The original directFromSellerSignals worked by downloading a response 
> A, from the seller’s origin, that is a WBN containing several 
> subresources 
> that represent signals from the seller to various auction participants -- 
> no linking was involved.
>
>
>>> Can you outline that flow more explicitly? Apologies, but I'd like to 
>>> better understand its performance characteristics.
>>> IIUC, in both cases we have an initial page that triggers a request, 
>>> where in one that request is to a WBN (using a  ?) and the other it's 
>>> to a random resource using fetch({adAuctionHeaders: true}) ?
>>>
>>> I guess it's unclear to me why the former would be slower than the 
>>> latter, especially given the large payloads and the fact that headers can't 
>>> really be compressed.
>>>
>>>
> You’re correct about this header-based version of 
> directFromSellerSignals -- when Chrome downloads a response, from the 
> seller’s origin, with fetch(..., {adAuctionHeaders: true}), the 
> Ad-Auction-Signals header gets parsed as JSON to provide the signals.
>  
>
>
> If so, any more details on that header? What would be the header name? 
> What payload sizes should we expect for the header's value? In what 
> conditions will it actually be processed?
>
>
> The name of the header is Ad-Auction-Signals, as mentioned here in the 
> explainer: [0]. Currently, the payload size is limited to 1kb [1], but 
> we’re considering increasing that to 10kb based on feedback. When Chrome 
> conducts a Protected Audience auction, it processes any received 
> Ad-Auction-Signals headers whose adSlot matches that of the auction.  The 
> header contains JSON that dictates which signals are sent to which 
> auction 
> participants.
>
>
>>> 1K header is a lot. 10KB header is... really a lot.
>>> Have you tested that with a variety of CDNs and other intermediaries? I 
>>> wouldn't be surprised if those values would break some assumptions in 
>>> existing HTTP proxying software.
>>>
>>> Also, the JSON y'all are sending doesn't seem extremely nested. Have you 
>>> considered structured fields 
>>> ?
>>>  
>>>

> [0] 
> https://github.com/WICG/turtledove/pull/695/files#diff-d65ba9778fe3af46de3edfce2266b5b035192f8869280ec07179963b81f4e624R465
>
> [1] 

Re: [blink-dev] Intent to Ship: TLS Encrypted Client Hello (ECH)

['David Adrian' via blink-dev]

I'll note that Chrome does not require that the HTTPS RR be resolved over
DoH to use ECH, under the argument that some ECH is still better than no
ECH. Firefox only uses ECH when they are able to query HTTPS RR records
over encrypted DNS.

On Wed, Sep 20, 2023 at 12:54 PM David Benjamin 
wrote:

> I think this discussion is conflating two different things:
>
> 1. Whether some content (sections 1 and 3 of the spec) was extracted into
> an explainer.
> 2. Particular questions about the spec that Blink API owners wanted
> answers for.
>
> With the expectation that, had there been something under an explainer,
> the questions in (2) would have been automatically answered. But if we
> wrote an explainer, it would simply have contained sections 1 and 3. As
> this is a TLS and networking feature, everything is naturally all written
> from that context, including explainers. The norms and audiences are very
> different from, say, a JavaScript API. In the same way that a web platform
> explainer doesn't explain what origins, frames, documents, windows, and the
> DOM are, yet folks in the TLS community won't necessarily know how webpages
> are organized. (I can't tell you how many times I've had to explain the
> implications of subresources in a browser to TLSWG folks!)
>
> That's not to say non-TLS folks can't look at this... we're certainly
> interested in feedback from you all! But I'd suggest that, if something is
> unclear to you all, keep in mind the different context and not assume it's
> just due to the specification formats. Instead, just ask us! To sort out
> the formalities, I've updated chromestatus.com to just link to sections 1
> and 3 of the spec under explainer, but that doesn't do anything to change
> this fundamental difference in context.
>
> To your example question, ECH is orthogonal[*] to DNS over HTTPS. Since
> it's orthogonal, I don't think we'd have covered that in the explainer
> anyway. Rather your question is about how DoH works, independently of ECH.
> (Even without ECH, HTTPS still depends on DNS!) But I can still answer:
>
> When you visit example.com, you query A, , and HTTPS-RR records for
> example.com from your DNS resolver. (Confusingly, the DNS records are
> also called "HTTPS". I've taken to writing "HTTPS-RR" to disambiguate.) The
> ECH keys are in HTTPS-RR. Note HTTPS-RR is not specific to ECH and already
> launched. ECH is just using one more piece of service information from
> there. If we get any keys, we pass them to TLS, just as the A/
> information is passed to TCP setup.
>
> If your DNS resolver happens to be DNS over HTTPS, those queries may
> themselves require setting up a *different* HTTPS connection, to
> *different* origin. If the DoH origin is specified by IP address, there's
> no DNS lookup, including no HTTPS-RR lookup and we just don't do ECH for
> that connection. (DoH or non-DoH, ECH, deployed with keys from DNS, only
> works for DNS-based origins and not IP-based origins. But there is also
> less to protect for an IP-based origin.) If the DoH origin is specified by
> a DNS name, we indeed need a DNS lookup. That is not new with ECH... before
> ECH, we needed to look up A and  anyway. If that DNS lookup went
> through DNS over HTTPS, that would indeed be a circular dependency, but
> nothing to do with ECH. Just DoH. As that's unrelated to this launch, I
> don't know the exact details, but I believe we just use the system, non-DoH
> resolver to look up information for the DoH server. If we get ECH keys as
> part of that, we'll use them, otherwise we won't.
>
> Are there other questions we can help answer?
>
> [*] Or rather, it is mechanically orthogonal. Of course, if you're using
> cleartext DNS, the server name may be leaked from your DNS queries rather
> than the ClientHello. Whether or not that's useful will depend a bit on
> network vantage points, etc. E.g. it could be that our "cleartext" DNS
> resolver is actually pointing to a localhost caching resolver that, itself,
> forwards onto DoH outside the browser. Then ECH would be useful. We, from
> the browser side, can't tell whether that's happening, so it's simplest to
> just treat it as orthogonal.
>
> On Wed, Sep 20, 2023 at 12:25 PM Daniel Bratell 
> wrote:
>
>> We are fine with being flexible with the details when the defaults don't
>> work out, but every field/question has an underlying purpose that we try to
>> satisfy through some means. Sometimes some fields might seem superfluous,
>> but the explainer field is one that is always valuable.
>>
>> The "explainer" has a couple of different consumers (not quite
>> overlapping but why make it too easy). It serves as a way to introduce
>> non-experts to a feature, it serves as an executive summary of a
>> complicated feature and it serves to fill in some non-technical gaps for
>> web developers, possibly with usage examples. When there is a public
>> announcement of a feature in a certain Chromium version, that is most often
>> based on 

Re: [blink-dev] Intent to Ship: Horizontal rules inside select elements

[Mike Taylor]

LGTM2

On 9/20/23 12:41 PM, Joey Arhar wrote:

For developer signals:

The material design menu component supports dividers like this: 
https://m2.material.io/components/menus#anatomy:~:text=Text-,Divider,-Text%20and%20icon


Bootstrap has a "dropdown-divider" class for the "dropdown-menu" class 
which is like a select with : 
https://getbootstrap.com/docs/4.0/components/dropdowns/


This intent adds support for dividers but not styling.

On Wed, Sep 20, 2023 at 8:10 AM Joey Arhar  wrote:

> Can we file a Mozilla position? (to raise awareness on their end
if nothing else)

https://github.com/mozilla/standards-positions/issues/887

> Have you talked to devrel folks about getting some signal there?
Presumably this is something developers would want to be able to do

I just reached out to devrel about this



On Wed, Sep 20, 2023 at 7:54 AM Yoav Weiss
 wrote:

LGTM1

On Tue, Sep 19, 2023 at 7:51 PM Joey Arhar
 wrote:


Contact emails

jar...@chromium.org


Explainer

None


Specification

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


Summary

This feature makes the HTML parser allow  tags inside
 tags. These  elements create horizontal
borders in between  elements in the listbox popup,
which we already support if you manually insert an hr
element with javascript.


Neat!


WebKit implemented this and just put it in their release
notes:

https://webkit.org/blog/14445/webkit-features-in-safari-17-0/#:~:text=Horizontal%20rules%20inside%20select%20elements


Blink component

Blink>DOM




TAG review

None


You spelled "Not required as this landed in HTML and shipped
in WebKit" wrong :)



TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: No signal
(https://bugzilla.mozilla.org/show_bug.cgi?id=1830909)


Can we file a Mozilla position? (to raise awareness on their
end if nothing else)


/WebKit/: Shipped/Shipping
(https://bugs.webkit.org/show_bug.cgi?id=80686)

/Web developers/: No signals


Have you talked to devrel folks about getting some signal
there? Presumably this is something developers would want to
be able to do


/Other signals/:


WebView application risks

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

None



Debuggability

None



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

Yes


Is this feature fully tested by web-platform-tests

?

Yes


Flag name on chrome://flags

SelectHr


Finch feature name

SelectHr


Requires code in //chrome?

False


Estimated milestones

Shipping on desktop 118
DevTrial on desktop 118

Shipping on Android 118
DevTrial on Android 118

Shipping on WebView 118



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

This intent message was generated by Chrome Platform
Status .

-- 
You received this message because you are subscribed to

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

Re: [blink-dev] Intent to Ship: Protected Audience directFromSellerSignals via HTTP response headers

[Mike Taylor]

And gentle reminder to please land the spec PRs :)

On 9/20/23 12:54 PM, Chris Harrelson wrote:

LGTM3

On Wed, Sep 20, 2023 at 9:53 AM Yoav Weiss  wrote:

LGTM2

Talking to the team, the 10K limit is Finchable, so we'd be able
to lower it if this runs into issues in the field. Also
presumably, having that as a limit doesn't mean most responses
would actually use that.

On Sat, Sep 16, 2023 at 6:52 AM Yoav Weiss
 wrote:




On Fri, Sep 15, 2023 at 10:00 PM Mike Taylor
 wrote:

Thanks, LGTM1 pending the PRs landing.

On 9/12/23 12:29 AM, Caleb Raitto wrote:


Hi Mike,


Pull request 695
is the
change to update the explainer to describe the new
header-based directFromSellerSignals, whereas 771
and 774
are for the
spec changes.


The explainer change describes usage of the new API and
provides context for the differences between header-based
and the prior bundles based versions of
directFromSellerSignals, whereas the spec change
describes how to implement the header-based version.


We intend to land all 3 pull requests.


Thanks,

-Caleb

On Monday, September 11, 2023 at 11:18:26 AM UTC-4 Mike
Taylor wrote:


On 9/11/23 12:55 PM, Mike Taylor wrote:


On 9/7/23 6:00 PM, Caleb Raitto wrote:


Hi Yoav, some responses inline:

On Wednesday, September 6, 2023 at 12:15:45 PM
UTC-4 Yoav Weiss wrote:

On Tue, Sep 5, 2023 at 9:55 PM Paul Jensen
 wrote:

Contact emails*

pauljen...@chromium.org


*Explainer*

https://github.com/WICG/turtledove/pull/69
5

*


Can you clarify what this does, as the
explainer is not very explain-y?

IIUC, the current flow to
get directFromSellerSignals is to download a
response A which contains a link to a WBN, then
download the WBN and that contains the signal info.
Your proposal is to change that so that
the directFromSellerSignals information would
be embedded in a response header on response A?


The original directFromSellerSignals worked by
downloading a response A, from the seller’s origin,
that is a WBN containing several subresources that
represent signals from the seller to various
auction participants -- no linking was involved.



Can you outline that flow more explicitly? Apologies, but I'd
like to better understand its performance characteristics.
IIUC, in both cases we have an initial page that triggers a
request, where in one that request is to a WBN (using a 
?) and the other it's to a random resource using
fetch({adAuctionHeaders: true}) ?

I guess it's unclear to me why the former would be slower than
the latter, especially given the large payloads and the fact
that headers can't really be compressed.



You’re correct about this header-based version of
directFromSellerSignals -- when Chrome downloads a
response, from the seller’s origin, with fetch(...,
{adAuctionHeaders: true}), the Ad-Auction-Signals
header gets parsed as JSON to provide the signals.


If so, any more details on that header? What
would be the header name? What payload sizes
should we expect for the header's value? In
what conditions will it actually be processed?


The name of the header is Ad-Auction-Signals, as
mentioned here in the explainer: [0]. Currently,
the payload size is limited to 1kb [1], but we’re
considering increasing that to 10kb based on
feedback. When Chrome conducts a Protected Audience
auction, it processes any received
Ad-Auction-Signals headers whose adSlot matches
that of the auction.  The header contains JSON that
dictates which signals are sent to which auction
participants.



1K header is a lot. 10KB header is... really a lot.
Have you tested that with a variety of CDNs and other

Re: [blink-dev] Intent to Ship: TLS Encrypted Client Hello (ECH)

[David Benjamin]

I think this discussion is conflating two different things:

1. Whether some content (sections 1 and 3 of the spec) was extracted into
an explainer.
2. Particular questions about the spec that Blink API owners wanted answers
for.

With the expectation that, had there been something under an explainer, the
questions in (2) would have been automatically answered. But if we wrote an
explainer, it would simply have contained sections 1 and 3. As this is a
TLS and networking feature, everything is naturally all written from that
context, including explainers. The norms and audiences are very different
from, say, a JavaScript API. In the same way that a web platform explainer
doesn't explain what origins, frames, documents, windows, and the DOM are,
yet folks in the TLS community won't necessarily know how webpages are
organized. (I can't tell you how many times I've had to explain the
implications of subresources in a browser to TLSWG folks!)

That's not to say non-TLS folks can't look at this... we're certainly
interested in feedback from you all! But I'd suggest that, if something is
unclear to you all, keep in mind the different context and not assume it's
just due to the specification formats. Instead, just ask us! To sort out
the formalities, I've updated chromestatus.com to just link to sections 1
and 3 of the spec under explainer, but that doesn't do anything to change
this fundamental difference in context.

To your example question, ECH is orthogonal[*] to DNS over HTTPS. Since
it's orthogonal, I don't think we'd have covered that in the explainer
anyway. Rather your question is about how DoH works, independently of ECH.
(Even without ECH, HTTPS still depends on DNS!) But I can still answer:

When you visit example.com, you query A, , and HTTPS-RR records for
example.com from your DNS resolver. (Confusingly, the DNS records are also
called "HTTPS". I've taken to writing "HTTPS-RR" to disambiguate.) The ECH
keys are in HTTPS-RR. Note HTTPS-RR is not specific to ECH and already
launched. ECH is just using one more piece of service information from
there. If we get any keys, we pass them to TLS, just as the A/
information is passed to TCP setup.

If your DNS resolver happens to be DNS over HTTPS, those queries may
themselves require setting up a *different* HTTPS connection, to
*different* origin.
If the DoH origin is specified by IP address, there's no DNS lookup,
including no HTTPS-RR lookup and we just don't do ECH for that connection.
(DoH or non-DoH, ECH, deployed with keys from DNS, only works for DNS-based
origins and not IP-based origins. But there is also less to protect for an
IP-based origin.) If the DoH origin is specified by a DNS name, we indeed
need a DNS lookup. That is not new with ECH... before ECH, we needed to
look up A and  anyway. If that DNS lookup went through DNS over HTTPS,
that would indeed be a circular dependency, but nothing to do with ECH.
Just DoH. As that's unrelated to this launch, I don't know the exact
details, but I believe we just use the system, non-DoH resolver to look up
information for the DoH server. If we get ECH keys as part of that, we'll
use them, otherwise we won't.

Are there other questions we can help answer?

[*] Or rather, it is mechanically orthogonal. Of course, if you're using
cleartext DNS, the server name may be leaked from your DNS queries rather
than the ClientHello. Whether or not that's useful will depend a bit on
network vantage points, etc. E.g. it could be that our "cleartext" DNS
resolver is actually pointing to a localhost caching resolver that, itself,
forwards onto DoH outside the browser. Then ECH would be useful. We, from
the browser side, can't tell whether that's happening, so it's simplest to
just treat it as orthogonal.

On Wed, Sep 20, 2023 at 12:25 PM Daniel Bratell  wrote:

> We are fine with being flexible with the details when the defaults don't
> work out, but every field/question has an underlying purpose that we try to
> satisfy through some means. Sometimes some fields might seem superfluous,
> but the explainer field is one that is always valuable.
>
> The "explainer" has a couple of different consumers (not quite overlapping
> but why make it too easy). It serves as a way to introduce non-experts to a
> feature, it serves as an executive summary of a complicated feature and it
> serves to fill in some non-technical gaps for web developers, possibly with
> usage examples. When there is a public announcement of a feature in a
> certain Chromium version, that is most often based on the explainer, not
> any specification.
>
> Just as an example of something an explainer might have mentioned is why
> this involves keys in DNS and if HTTPS depends on DNS, what about DNS over
> HTTPS? It often say things that are obvious to area experts, but might not
> be obvious to everyone exposed to this change.
>
> Quite often an explainer can be lifted/extracted from another source, like
> a previous blog post, or the human 

Re: [blink-dev] Intent to Implement and Ship: CaptureStartFocusBehavior enum value "focus-capturing-application"

[Yoav Weiss]

LGTM1

On Wed, Sep 20, 2023 at 5:45 PM François Beaufort 
wrote:

>
>
> On Wed, Sep 20, 2023 at 5:26 PM Yoav Weiss  wrote:
>
>>
>>
>> On Tue, Sep 19, 2023 at 12:49 PM 'François Beaufort' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> fbeauf...@google.com
>>>
>>> elada...@google.com
>>>
>>> Explainer
>>>
>>> https://github.com/WICG/conditional-focus/blob/main/README.md
>>>
>>> Specification
>>>
>>>
>>> https://www.w3.org/TR/screen-capture/#idl-def-CaptureStartFocusBehavior.focus-capturing-application
>>>
>>> Summary
>>>
>>> The Screen Capture API lets the user select a tab, window, or screen to
>>> capture as a media stream. Using the existing CaptureController
>>> setFocusBehavior() method, web apps control whether the captured tab or
>>> window will be focused when capture starts, or whether the browser will
>>> leave focus with whichever surface last had focus.
>>>
>>>
>>> The new enum value "focus-capturing-application" allows web apps to
>>> give a hint to the browser that the capturing page prefers to remain
>>> focused. The old value "no-focus-change" now indicates that the
>>> application prefers that the user agent not change focus, leaving focus
>>> with whichever surface last had focus following the user's interaction with
>>> the user agent and/or operating system. In Chrome’s current implementation,
>>> this means leaving the capturing application focused. In the future, if
>>> Chrome adopts the macOS picker, it could behave differently on Mac. This
>>> behavior could prove useful for a11y-conscious applications that prefer to
>>> minimize the number of focus-changes a user experiences, as those can be
>>> challenging for users with screen-readers.
>>>
>>> Blink component
>>>
>>> Blink>GetDisplayMedia
>>> 
>>>
>>> TAG review
>>>
>>> N/A We didn’t file a specific TAG review for this feature as the
>>> addition of this enum doesn’t have any architectural changes impact to the
>>> spec and the web in general.
>>>
>>> TAG review status
>>>
>>> Pending
>>>
>>> Risks
>>> Interoperability and Compatibility
>>>
>>> None
>>>
>>
>> You mentioned a semantics change around "no-focus-change". I guess it
>> doesn't have any ability to break pages, at worst users will get a
>> different focus than they previously did. Is that correct?
>>
>
> "focus-capturing-application" and "no-focus-change" behave the same in
> Chrome.
> This will not break pages as Chrome is the only browser to have shipped
> Conditional Focus.
>

OK, thanks for clarifying!


>
>>
>>>
>>> Gecko: No signal
>>>
>>
>> Can we file a position, as an FYI?
>>
>
> Here it is: https://github.com/mozilla/standards-positions/issues/888
>
>
>>
>>
>>>
>>> WebKit: No signal - Youenn Fablet from Apple requested this API change
>>> in https://github.com/w3c/mediacapture-screen-share/issues/263.
>>>
>>> Web developers: No signal
>>>
>>> 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
>>>
>>> No DevTools changes are required, treated like any other attribute/enum.
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?
>>>
>>> Supported on all platforms that support getDisplayMedia. Namely, all
>>> desktop platforms.
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> Yes. See
>>> https://wpt.fyi/results/screen-capture/getdisplaymedia-capture-controller.https.window.html
>>>
>>> Flag name on chrome://flags
>>>
>>> None
>>>
>>> Finch feature name
>>>
>>> None
>>>
>>> Requires code in //chrome?
>>>
>>> No.
>>>
>>> Tracking bug
>>>
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1480383
>>>
>>> Estimated milestones
>>>
>>> Shipping on desktop
>>>
>>> 119
>>>
>>> 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/5119529898475520
>>>
>>> This intent message was generated by Chrome Platform Status
>>> .
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> 

Re: [blink-dev] Intent to Ship: Protected Audience directFromSellerSignals via HTTP response headers

[Chris Harrelson]

LGTM3

On Wed, Sep 20, 2023 at 9:53 AM Yoav Weiss  wrote:

> LGTM2
>
> Talking to the team, the 10K limit is Finchable, so we'd be able to lower
> it if this runs into issues in the field. Also presumably, having that as a
> limit doesn't mean most responses would actually use that.
>
> On Sat, Sep 16, 2023 at 6:52 AM Yoav Weiss  wrote:
>
>>
>>
>>
>> On Fri, Sep 15, 2023 at 10:00 PM Mike Taylor 
>> wrote:
>>
>>> Thanks, LGTM1 pending the PRs landing.
>>> On 9/12/23 12:29 AM, Caleb Raitto wrote:
>>>
>>> Hi Mike,
>>>
>>> Pull request 695  is the
>>> change to update the explainer to describe the new header-based
>>> directFromSellerSignals, whereas 771
>>>  and 774
>>>  are for the spec changes.
>>>
>>> The explainer change describes usage of the new API and provides context
>>> for the differences between header-based and the prior bundles based
>>> versions of directFromSellerSignals, whereas the spec change describes how
>>> to implement the header-based version.
>>>
>>> We intend to land all 3 pull requests.
>>>
>>> Thanks,
>>>
>>> -Caleb
>>> On Monday, September 11, 2023 at 11:18:26 AM UTC-4 Mike Taylor wrote:
>>>

 On 9/11/23 12:55 PM, Mike Taylor wrote:

 On 9/7/23 6:00 PM, Caleb Raitto wrote:

 Hi Yoav, some responses inline:

 On Wednesday, September 6, 2023 at 12:15:45 PM UTC-4 Yoav Weiss wrote:

 On Tue, Sep 5, 2023 at 9:55 PM Paul Jensen 
 wrote:

 Contact emails


 * pauljen...@chromium.org  *Explainer

 * https://github.com/WICG/turtledove/pull/69
 5 *


 Can you clarify what this does, as the explainer is not very explain-y?

 IIUC, the current flow to get directFromSellerSignals is to download a
 response A which contains a link to a WBN, then download the WBN and that
 contains the signal info.
 Your proposal is to change that so that the directFromSellerSignals
 information would be embedded in a response header on response A?


 The original directFromSellerSignals worked by downloading a response
 A, from the seller’s origin, that is a WBN containing several subresources
 that represent signals from the seller to various auction participants --
 no linking was involved.


>> Can you outline that flow more explicitly? Apologies, but I'd like to
>> better understand its performance characteristics.
>> IIUC, in both cases we have an initial page that triggers a request,
>> where in one that request is to a WBN (using a  ?) and the other it's
>> to a random resource using fetch({adAuctionHeaders: true}) ?
>>
>> I guess it's unclear to me why the former would be slower than the
>> latter, especially given the large payloads and the fact that headers can't
>> really be compressed.
>>
>>
 You’re correct about this header-based version of
 directFromSellerSignals -- when Chrome downloads a response, from the
 seller’s origin, with fetch(..., {adAuctionHeaders: true}), the
 Ad-Auction-Signals header gets parsed as JSON to provide the signals.



 If so, any more details on that header? What would be the header name?
 What payload sizes should we expect for the header's value? In what
 conditions will it actually be processed?


 The name of the header is Ad-Auction-Signals, as mentioned here in the
 explainer: [0]. Currently, the payload size is limited to 1kb [1], but
 we’re considering increasing that to 10kb based on feedback. When Chrome
 conducts a Protected Audience auction, it processes any received
 Ad-Auction-Signals headers whose adSlot matches that of the auction.  The
 header contains JSON that dictates which signals are sent to which auction
 participants.


>> 1K header is a lot. 10KB header is... really a lot.
>> Have you tested that with a variety of CDNs and other intermediaries? I
>> wouldn't be surprised if those values would break some assumptions in
>> existing HTTP proxying software.
>>
>> Also, the JSON y'all are sending doesn't seem extremely nested. Have you
>> considered structured fields
>> ?
>>
>>
>>>
 [0]
 https://github.com/WICG/turtledove/pull/695/files#diff-d65ba9778fe3af46de3edfce2266b5b035192f8869280ec07179963b81f4e624R465

 [1]
 https://source.chromium.org/chromium/chromium/src/+/main:content/browser/interest_group/ad_auction_url_loader_interceptor.cc;l=195;drc=dcd52bb9a48216858a950b919383c44a290273f7

 Thanks for the explanation - what's preventing
 https://github.com/WICG/turtledove/pull/695 from landing? It seems
 rather old (and references stuff that no longer exists, like
 `X-FLEDGE-Auction-Only`. (It also doesn't seem to define any error-handling
 for parsing the JSON 

Re: [blink-dev] Intent to Ship: Protected Audience directFromSellerSignals via HTTP response headers

[Yoav Weiss]

LGTM2

Talking to the team, the 10K limit is Finchable, so we'd be able to lower
it if this runs into issues in the field. Also presumably, having that as a
limit doesn't mean most responses would actually use that.

On Sat, Sep 16, 2023 at 6:52 AM Yoav Weiss  wrote:

>
>
>
> On Fri, Sep 15, 2023 at 10:00 PM Mike Taylor 
> wrote:
>
>> Thanks, LGTM1 pending the PRs landing.
>> On 9/12/23 12:29 AM, Caleb Raitto wrote:
>>
>> Hi Mike,
>>
>> Pull request 695  is the
>> change to update the explainer to describe the new header-based
>> directFromSellerSignals, whereas 771
>>  and 774
>>  are for the spec changes.
>>
>> The explainer change describes usage of the new API and provides context
>> for the differences between header-based and the prior bundles based
>> versions of directFromSellerSignals, whereas the spec change describes how
>> to implement the header-based version.
>>
>> We intend to land all 3 pull requests.
>>
>> Thanks,
>>
>> -Caleb
>> On Monday, September 11, 2023 at 11:18:26 AM UTC-4 Mike Taylor wrote:
>>
>>>
>>> On 9/11/23 12:55 PM, Mike Taylor wrote:
>>>
>>> On 9/7/23 6:00 PM, Caleb Raitto wrote:
>>>
>>> Hi Yoav, some responses inline:
>>>
>>> On Wednesday, September 6, 2023 at 12:15:45 PM UTC-4 Yoav Weiss wrote:
>>>
>>> On Tue, Sep 5, 2023 at 9:55 PM Paul Jensen 
>>> wrote:
>>>
>>> Contact emails
>>>
>>>
>>> * pauljen...@chromium.org  *Explainer
>>>
>>> * https://github.com/WICG/turtledove/pull/69
>>> 5 *
>>>
>>>
>>> Can you clarify what this does, as the explainer is not very explain-y?
>>>
>>> IIUC, the current flow to get directFromSellerSignals is to download a
>>> response A which contains a link to a WBN, then download the WBN and that
>>> contains the signal info.
>>> Your proposal is to change that so that the directFromSellerSignals
>>> information would be embedded in a response header on response A?
>>>
>>>
>>> The original directFromSellerSignals worked by downloading a response A,
>>> from the seller’s origin, that is a WBN containing several subresources
>>> that represent signals from the seller to various auction participants --
>>> no linking was involved.
>>>
>>>
> Can you outline that flow more explicitly? Apologies, but I'd like to
> better understand its performance characteristics.
> IIUC, in both cases we have an initial page that triggers a request, where
> in one that request is to a WBN (using a  ?) and the other it's to a
> random resource using fetch({adAuctionHeaders: true}) ?
>
> I guess it's unclear to me why the former would be slower than the latter,
> especially given the large payloads and the fact that headers can't really
> be compressed.
>
>
>>> You’re correct about this header-based version of
>>> directFromSellerSignals -- when Chrome downloads a response, from the
>>> seller’s origin, with fetch(..., {adAuctionHeaders: true}), the
>>> Ad-Auction-Signals header gets parsed as JSON to provide the signals.
>>>
>>>
>>>
>>> If so, any more details on that header? What would be the header name?
>>> What payload sizes should we expect for the header's value? In what
>>> conditions will it actually be processed?
>>>
>>>
>>> The name of the header is Ad-Auction-Signals, as mentioned here in the
>>> explainer: [0]. Currently, the payload size is limited to 1kb [1], but
>>> we’re considering increasing that to 10kb based on feedback. When Chrome
>>> conducts a Protected Audience auction, it processes any received
>>> Ad-Auction-Signals headers whose adSlot matches that of the auction.  The
>>> header contains JSON that dictates which signals are sent to which auction
>>> participants.
>>>
>>>
> 1K header is a lot. 10KB header is... really a lot.
> Have you tested that with a variety of CDNs and other intermediaries? I
> wouldn't be surprised if those values would break some assumptions in
> existing HTTP proxying software.
>
> Also, the JSON y'all are sending doesn't seem extremely nested. Have you
> considered structured fields 
> ?
>
>
>>
>>> [0]
>>> https://github.com/WICG/turtledove/pull/695/files#diff-d65ba9778fe3af46de3edfce2266b5b035192f8869280ec07179963b81f4e624R465
>>>
>>> [1]
>>> https://source.chromium.org/chromium/chromium/src/+/main:content/browser/interest_group/ad_auction_url_loader_interceptor.cc;l=195;drc=dcd52bb9a48216858a950b919383c44a290273f7
>>>
>>> Thanks for the explanation - what's preventing
>>> https://github.com/WICG/turtledove/pull/695 from landing? It seems
>>> rather old (and references stuff that no longer exists, like
>>> `X-FLEDGE-Auction-Only`. (It also doesn't seem to define any error-handling
>>> for parsing the JSON that a server returns, which would be good to do.)
>>>
>>> I maybe have just been confused. I'm not sure if 695 is intended to
>>> land, beyond 771 and 774, both of which have much more 

Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature detection for supported clipboard formats

['Anupam Snigdha' via blink-dev]

Thanks Chris for the clarification!
Filed TAG review: https://github.com/w3ctag/design-reviews/issues/901
Mozilla: https://github.com/mozilla/standards-positions/issues/889
Webkit: https://github.com/WebKit/standards-positions/issues/259

Please let me know if I missed anything. Thanks!

-Anupam

From: Chris Harrelson 
Sent: Wednesday, September 20, 2023 8:58 AM
To: Anupam Snigdha 
Cc: Sangwhan Moon ; blink-dev@chromium.org 
; Sanket Joshi (EDGE) ; Evan Stade 
; jsb...@google.com 
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature 
detection for supported clipboard formats

Please do file a TAG review and ask for official vendor signals. It's great 
that it was approved by the editing WG, but we also need wider TAG review for 
features, and WebKit and Gecko would like to see signals requests go through 
their official process.

On Tue, Sep 19, 2023 at 9:25 AM 'Anupam Snigdha' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
Why is it not applicable?
Note that this API is already in the clipboard spec and was approved by the 
EditingWG 
members.
 I wasn't sure if we would need TAG to review it after it was approved by 
representatives from Webkit, Firefox and Chromium so I didn't file a TAG review 
request. I can certainly do it if it's required. Please let me know.


-Anupam


From: Sangwhan Moon mailto:s...@chromium.org>>
Sent: Monday, September 18, 2023 11:10 PM
To: Anupam Snigdha mailto:sni...@microsoft.com>>
Cc: blink-dev@chromium.org 
mailto:blink-dev@chromium.org>>; Sanket Joshi (EDGE) 
mailto:sa...@microsoft.com>>; Evan Stade 
mailto:est...@chromium.org>>; 
jsb...@google.com 
mailto:jsb...@google.com>>
Subject: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature 
detection for supported clipboard formats

You don't often get email from s...@chromium.org. 
Learn why this is important
Interesting problem, never thought about this ergonomic problem.

On Sep 19, 2023, at 2:12, 'Anupam Snigdha' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:


Contact emails
sni...@microsoft.com, 
sa...@microsoft.com, 
est...@chromium.org, 
jsb...@chromium.org, 
asu...@chromium.org

Explainer
https://github.com/w3c/clipboard-apis/issues/170


Specification

https://w3c.github.io/clipboard-apis/#clipboard-item-interface
https://w3c.github.io/clipboard-apis/#dom-clipboarditem-supports

Summary

Currently during async clipboard write operation, there is no way for the web 
authors to detect if a particular mime type is supported by the UAs or not 
before attempting to actually write the formats to the clipboard. This not only 
affects developer ergonomics as now web authors have to attempt to write to the 
clipboard first in order to find out whether write failed due to a particular 
mime type not supported by the UAs (or sometimes add version checks that are 
unreliable at best), but also leads to unnecessary cost in terms of CPU cycles, 
COGS etc in order to produce an expensive web custom format which may not be 
supported by a particular browser.


Blink component
Blink>DataTransfer

Search tags
asyncclipboard

TAG review
None

TAG review status
Not applicable

Why is it not applicable?



WebFeature UseCounter name
kAsyncClipboardAPISupportsTypes

Risks


Interoperability and Compatibility

None


Gecko: Positive 
(https://github.com/w3c/clipboard-apis/issues/170#issuecomment-1064240391)

WebKit: Positive 
(https://github.com/w3c/clipboard-apis/issues/170#issuecomment-1064240391)

Web developers: Strongly positive 
(https://github.com/w3c/clipboard-apis/issues/165#issuecomment-1197976360) 
Multiple Github issues were filed for this feature: 
https://github.com/w3c/clipboard-apis/issues/165#issuecomment-1197976360 
https://github.com/w3c/clipboard-apis/issues/67#issuecomment-650439507 
https://github.com/w3c/clipboard-apis/issues/170

Other signals:

Ergonomics

N/A


Activation

N/A


Security

N/A


WebView application risks

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

N/A


Debuggability

Existing devtools support should be sufficient to query the static method from 
ClipboardItem.


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

Is this feature fully tested by 

Re: [blink-dev] Intent to Ship: Horizontal rules inside select elements

[Joey Arhar]

For developer signals:

The material design menu component supports dividers like this:
https://m2.material.io/components/menus#anatomy:~:text=Text-,Divider,-Text%20and%20icon

Bootstrap has a "dropdown-divider" class for the "dropdown-menu" class
which is like a select with :
https://getbootstrap.com/docs/4.0/components/dropdowns/

This intent adds support for dividers but not styling.

On Wed, Sep 20, 2023 at 8:10 AM Joey Arhar  wrote:

> > Can we file a Mozilla position? (to raise awareness on their end if
> nothing else)
>
> https://github.com/mozilla/standards-positions/issues/887
>
> > Have you talked to devrel folks about getting some signal there?
> Presumably this is something developers would want to be able to do
>
> I just reached out to devrel about this
>
>
>
> On Wed, Sep 20, 2023 at 7:54 AM Yoav Weiss  wrote:
>
>> LGTM1
>>
>> On Tue, Sep 19, 2023 at 7:51 PM Joey Arhar  wrote:
>>
>>> Contact emailsjar...@chromium.org
>>>
>>> ExplainerNone
>>>
>>> Specificationhttps://github.com/whatwg/html/pull/9124
>>>
>>> Summary
>>>
>>> This feature makes the HTML parser allow  tags inside  tags.
>>> These  elements create horizontal borders in between  elements
>>> in the listbox popup, which we already support if you manually insert an hr
>>> element with javascript.
>>>
>>
>> Neat!
>>
>>
>>>
>>> WebKit implemented this and just put it in their release notes:
>>> https://webkit.org/blog/14445/webkit-features-in-safari-17-0/#:~:text=Horizontal%20rules%20inside%20select%20elements
>>>
>>> Blink componentBlink>DOM
>>> 
>>>
>>> TAG reviewNone
>>>
>>
>> You spelled "Not required as this landed in HTML and shipped in WebKit"
>> wrong :)
>>
>>
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> None
>>>
>>>
>>> *Gecko*: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1830909
>>> )
>>>
>>
>> Can we file a Mozilla position? (to raise awareness on their end if
>> nothing else)
>>
>>
>>> *WebKit*: Shipped/Shipping (
>>> https://bugs.webkit.org/show_bug.cgi?id=80686)
>>>
>>> *Web developers*: No signals
>>>
>>
>> Have you talked to devrel folks about getting some signal there?
>> Presumably this is something developers would want to be able to do
>>
>>
>>>
>>> *Other signals*:
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> None
>>>
>>>
>>> Debuggability
>>>
>>> None
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?Yes
>>>
>>> Flag name on chrome://flagsSelectHr
>>>
>>> Finch feature nameSelectHr
>>>
>>> Requires code in //chrome?False
>>>
>>> Estimated milestones
>>> Shipping on desktop 118
>>> DevTrial on desktop 118
>>> Shipping on Android 118
>>> DevTrial on Android 118
>>> Shipping on WebView 118
>>>
>>> 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/6198448366026752
>>>
>>> This intent message was generated by Chrome Platform Status
>>> .
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKBrQrrtOe4FwDfYR_nx%3DhXPEv2Yu10h407iPn2y3d9mA%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/CAK6btwLQEZQdoHQXuwqx98Oy1U5pU9yc6_N0O%3DvHWC76L6CFpg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: TLS Encrypted Client Hello (ECH)

[Daniel Bratell]

We are fine with being flexible with the details when the defaults don't 
work out, but every field/question has an underlying purpose that we try 
to satisfy through some means. Sometimes some fields might seem 
superfluous, but the explainer field is one that is always valuable.


The "explainer" has a couple of different consumers (not quite 
overlapping but why make it too easy). It serves as a way to introduce 
non-experts to a feature, it serves as an executive summary of a 
complicated feature and it serves to fill in some non-technical gaps for 
web developers, possibly with usage examples. When there is a public 
announcement of a feature in a certain Chromium version, that is most 
often based on the explainer, not any specification.


Just as an example of something an explainer might have mentioned is why 
this involves keys in DNS and if HTTPS depends on DNS, what about DNS 
over HTTPS? It often say things that are obvious to area experts, but 
might not be obvious to everyone exposed to this change.


Quite often an explainer can be lifted/extracted from another source, 
like a previous blog post, or the human friendly part of specification, 
but it still has to be packaged in non-scary way. You mentioned a 
release note, maybe that one was all that was needed?


/Daniel

On 2023-09-19 01:04, 'David Adrian' via blink-dev wrote:

> Could we please request a signal?

Done (and positive!). I had forgotten to add it to Chrome Status. 
https://github.com/WebKit/standards-positions/issues/46


As for the explainer, between sending the I2S and now, I updated the 
Chrome Status description to cover most of what David Benjamin 
discussed, and match what was previously communicated in Chrome 
release notes. I should have done this before sending the I2S, 
although I was under the impression that an RFC would be a sufficient 
explainer. I do understand why it is useful to provide information at 
a slightly higher and holistic level---I hope the updated description 
and David Benjamin's comments can stand as that for this Intent.


More broadly, David Benjamin is right that we are effectively jamming 
a TLS change from the IETF through a process designed for the Web 
Platform and W3C. We mostly do this so that launches show up in Chrome 
Status, and organizations who are interested in following TLS changes 
can see them there.


Now that launches show up in Chrome Status regardless of whether or 
not they are a Blink launch, we may want to consider no longer sending 
TLS launches through the Intent process, since they exist outside of 
the Web Platform, and primarily cause discussion about process 
confusion (we're trying our best to fit them in!), and not actual impact.






On Mon, Sep 18, 2023 at 9:53 AM David Benjamin  
wrote:


On Mon, Sep 18, 2023 at 10:06 AM Yoav Weiss
 wrote:



On Sat, Sep 16, 2023 at 5:35 PM David Benjamin
 wrote:

On Sat, Sep 16, 2023 at 1:12 AM Yoav Weiss
 wrote:



On Fri, Sep 15, 2023 at 10:05 PM Mike Taylor
 wrote:

On 9/11/23 6:34 PM, 'David Adrian' via blink-dev
wrote:



Contact emails

david...@chromium.org, dadr...@google.com


Explainer

None


I think a short explainer that outlines what this is
and what's the typical flow would be helpful. While
that content could've been part of the draft, that
doesn't seem to be the case, at least at a glance.


This is a process mismatch that comes up for every
networking protocol. The expected audiences and also style
of spec are very different. Explainers make sense for
W3C-style specs where the other consumer of the feature is
a web developer who wants to understand how to use the API
and not how to implement it step-by-step. The audience for
a network protocol is completely different. The other
consumer of the feature is a TLS server software
implementer, who /also/ needs to understand the full protocol.


Explainers are not destined only for web developers.
In this particular case, I'd think the audience for this is
the API owners (who may or may not have time to read the full
I-D), as well as the broader Blink community that keeps tabs
on what we're shipping, and may want to understand more about
this feature and what it gives them as users. Note that I'm
not necessarily asking for a long and complex document - a
short explainer that outlines the status quo, what this is
changing and how the new flow works would do the trick.


When it gets filtered up to web developers and server
operators, all they see is how to configure their server
  

Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Feature detection for supported clipboard formats

[Chris Harrelson]

Please do file a TAG review and ask for official vendor signals. It's great
that it was approved by the editing WG, but we also need wider TAG review
for features, and WebKit and Gecko would like to see signals requests go
through their official process.

On Tue, Sep 19, 2023 at 9:25 AM 'Anupam Snigdha' via blink-dev <
blink-dev@chromium.org> wrote:

> Why is it not applicable?
>
> Note that this API is already in the clipboard spec and was approved by
> the EditingWG members
> .
> I wasn't sure if we would need TAG to review it after it was approved by
> representatives from Webkit, Firefox and Chromium so I didn't file a TAG
> review request. I can certainly do it if it's required. Please let me know.
>
>
> -Anupam
>
> --
> *From:* Sangwhan Moon 
> *Sent:* Monday, September 18, 2023 11:10 PM
> *To:* Anupam Snigdha 
> *Cc:* blink-dev@chromium.org ; Sanket Joshi
> (EDGE) ; Evan Stade ;
> jsb...@google.com 
> *Subject:* [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship:
> Feature detection for supported clipboard formats
>
> You don't often get email from s...@chromium.org. Learn why this is
> important 
> Interesting problem, never thought about this ergonomic problem.
>
> On Sep 19, 2023, at 2:12, 'Anupam Snigdha' via blink-dev <
> blink-dev@chromium.org> wrote:
>
> 
> Contact emails
> sni...@microsoft.com, sa...@microsoft.com, est...@chromium.org,
> jsb...@chromium.org, asu...@chromium.org
>
> Explainer
> https://github.com/w3c/clipboard-apis/issues/170
>
>
> Specification
>
> https://w3c.github.io/clipboard-apis/#clipboard-item-interface
> https://w3c.github.io/clipboard-apis/#dom-clipboarditem-supports
>
> Summary
>
> Currently during async clipboard write operation, there is no way for the
> web authors to detect if a particular mime type is supported by the UAs or
> not before attempting to actually write the formats to the clipboard. This
> not only affects developer ergonomics as now web authors have to attempt to
> write to the clipboard first in order to find out whether write failed due
> to a particular mime type not supported by the UAs (or sometimes add
> version checks that are unreliable at best), but also leads to unnecessary
> cost in terms of CPU cycles, COGS etc in order to produce an expensive web
> custom format which may not be supported by a particular browser.
>
>
> Blink component
> Blink>DataTransfer
> 
>
> Search tags
> asyncclipboard 
>
> TAG review
> None
>
>
> TAG review status
> Not applicable
>
>
> Why is it not applicable?
>
>
>
> WebFeature UseCounter name
> kAsyncClipboardAPISupportsTypes
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: Positive (
> https://github.com/w3c/clipboard-apis/issues/170#issuecomment-1064240391)
>
> *WebKit*: Positive (
> https://github.com/w3c/clipboard-apis/issues/170#issuecomment-1064240391)
>
> *Web developers*: Strongly positive (
> https://github.com/w3c/clipboard-apis/issues/165#issuecomment-1197976360)
> Multiple Github issues were filed for this feature:
> https://github.com/w3c/clipboard-apis/issues/165#issuecomment-1197976360
> https://github.com/w3c/clipboard-apis/issues/67#issuecomment-650439507
> https://github.com/w3c/clipboard-apis/issues/170
>
> *Other signals*:
>
> Ergonomics
>
> N/A
>
>
> Activation
>
> N/A
>
>
> Security
>
> N/A
>
>
> WebView application risks
>
> *Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?*
>
> N/A
>
>
> Debuggability
>
> Existing devtools support should be sufficient to query the static method
> from ClipboardItem.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
> Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ?
> Yes
>
> Flag name on chrome://flags
> ClipboardSupportedTypes
>
> Finch feature name
> None
>
> Non-finch justification
> None
>
> Requires code in //chrome?
> False
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1483026
>
> Measurement
> Added usage metrics: AsyncClipboardAPISupportsTypes
>
> Adoption expectation
> Excel online is ready to use this API for adding web custom format support.
>
> Adoption plan
> Support for web custom format is already in inner rings, so once this gets
> added to the clipboard API, Excel would be ready to use it right away.
>
> Sample links
>
> https://lake-cobalt-way.glitch.me
>
> Estimated milestones
>
> Shipping on desktop
> 119
> DevTrial on desktop
> 119
> Shipping on Android
> 119
> DevTrial on Android
> 119
>
>
> Link to entry on 

Re: [blink-dev] Intent to Ship: Private Network Access restrictions for automotive

[Chris Harrelson]

LGTM3

On Mon, Sep 18, 2023 at 6:21 AM Yoav Weiss  wrote:

> LGTM2
>
> On Mon, Sep 18, 2023 at 3:16 PM Mike Taylor 
> wrote:
>
>> LGTM1. Curious to know (but happy to not know) how many local servers are
>> running in my car...
>> On 9/18/23 5:30 AM, Jonathan Hao wrote:
>>
>> Contact emails p...@chromium.org
>>
>> Explainer
>> https://github.com/WICG/private-network-access/blob/main/explainer.md
>>
>> Specification https://github.com/WICG/private-network-access
>>
>> Design docs
>>
>> https://docs.google.com/document/d/1ozjh-G6faEEkgVp__mjq6c_4U93sS4kK4zoelTE7Awg/edit?usp=sharing
>>
>> Summary
>>
>> Enforce (instead of just warn) Private Network Access restrictions on
>> Chrome for Android Automotive (if BuildInfo::is_automotive), including: -
>> Private Network Access preflight requests for subresources. See
>> https://chromestatus.com/feature/5737414355058688, and - Private Network
>> Access for Workers. See https://chromestatus.com/feature/5742979561029632
>>
>>
>> Blink component Blink>SecurityFeature>CORS>PrivateNetworkAccess
>> 
>>
>> TAG review https://github.com/w3ctag/design-reviews/issues/572
>>
>> TAG review status Issues addressed
>>
>> Origin Trial documentation link
>> https://github.com/WICG/private-network-access/blob/main/explainer.md
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Android Automotive is going to be a new platform, so no websites should
>> rely on making private network requests yet. And our purpose is to ship
>> this from the beginning to avoid future compatibility risks.
>>
>>
>> *Gecko*: Positive (
>> https://github.com/mozilla/standards-positions/issues/143)
>>
>> *WebKit*: Positive (
>> https://github.com/WebKit/standards-positions/issues/163)
>>
>> *Web developers*: Mixed signals Anecdotal evidence so far suggests that
>> most web developers are OK with this new requirement, though some do not
>> control the target endpoints and would be negatively impacted.
>>
>> *Other signals*:
>>
>> Security
>>
>> This change aims to be security-positive, preventing CSRF attacks against
>> soft and juicy targets such as router admin interfaces. It does not cover
>> navigation requests, which are to be addressed in followup launches. DNS
>> rebinding threats were of particular concern during the design of this
>> feature:
>> https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit#heading=h.189j5gnadts9
>>
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None
>>
>>
>> Debuggability
>>
>> Relevant information (client and resource IP address space) is already
>> piped into the DevTools network panel. Deprecation warnings and errors will
>> be surfaced in the DevTools issues panel explaining the problem when it
>> arises.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)? No
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ? Yes
>>
>> Flag name on chrome://flags None
>>
>> Finch feature name PrivateNetworkAccessRestrictionsForAutomotive
>>
>> Requires code in //chrome? False
>>
>> Estimated milestones
>> Shipping on Android (only when is_automotive=true) 119
>>
>> 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/5082807021338624
>>
>> Links to previous Intent discussions Intent to prototype:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/MO2HmKaFe8c/m/vljPBcxdAQAJ
>>
>> This intent message was generated by Chrome Platform Status
>> .
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOC%3DiP%2BAu2epCdGTM-VgyBXj61C%2BJ4WUv3WTO9SZ_OAeaf2JmQ%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 

Re: [blink-dev] Re: Intent to Prototype And Ship: Allow transferring ArrayBuffer into VideoFrame, AudioData, EncodedVideoChunk, EncodedAudioChunk, ImageDecoder constructors

[Mike Taylor]

LGTM3

On 9/20/23 11:48 AM, Chris Harrelson wrote:

LGTM2

Would be great to file official vendor signals just so they know this 
is happening, if you're willing.


On Wed, Sep 20, 2023 at 7:41 AM Yoav Weiss  wrote:

LGTM1 given the consistency here with other platform APIs and the
need to extend this in the future.

On Tue, Sep 5, 2023 at 8:39 PM Dale Curtis
 wrote:

I wouldn't say it's urgent, but I would hope for feedback
within a week or two. Thanks!

- dale

On Sun, Sep 3, 2023 at 4:32 AM Sangwhan Moon
 wrote:

Thank you for filing this. If it is urgent, I could flag
it as time constrained.


On Aug 31, 2023, at 7:14, 'Eugene Zemtsov' via blink-dev
 wrote:


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

On Wed, Aug 30, 2023 at 9:50 AM Dale Curtis
 wrote:

Alex, I assume you mean TAG's views on consistency
regarding transfer ergonomics? Otherwise
https://www.w3.org/TR/design-principles/#consistency
is what we followed here. We have not asked, given
that we felt this was a small performance
improvement, with pre-existing ergonomics, and
already has Media WG approval. We can certainly file
a TAG request, but as you know, litigating minor
features like this through TAG is unlikely to have a
timely resolution.

Regarding Yoav's proposal above of a single boolean,
that might make sense today where we have a single
transfer, but we expect more input ArrayBuffers over
time for some of these APIs, which would mean it
becomes all-or-nothing for developers. E.g., we are
likely to accept arrays of metadata, HDR data, etc.
The boolean would mean they must transfer everything,
which may lead to them making temporary copies of
smaller buffers to get transfer effects on the larger
ones.

Daniel, sorry, that's just an oversight in the
chromestatus entry. There are tests added (here's the
one for videoFrame):

https://chromium-review.googlesource.com/c/chromium/src/+/4529012/17/third_party/blink/web_tests/external/wpt/webcodecs/videoFrame-construction.any.js

- dale

On Wed, Aug 30, 2023 at 9:19 AM Daniel Bratell
 wrote:

In addition to Alex's question, I also noticed
that you answered the web-platform-tests with a
"no", which is a bit unexpected to me. Is there a
reason this cannot or won't be tested in
web-platform-tests?

/Daniel

On 2023-08-30 18:03, Alex Russell wrote:

Hey Eugene,

I'm a little worried that we're debating API
shape here when there hasn't been any guidance
from the TAG on design consistency. Have you
either asked the TAG to weigh in (didn't see a
review link in the Intent) or asked Chromium
(ex)TAG members to give the API a once-over?

Best,

Alex

On Thursday, August 24, 2023 at 9:45:42 AM UTC-7
Eugene Zemtsov wrote:

> Can you clarify if this was in response to
my questions or to Jonathan's?

Yours.
Sorry, I missed Jonathan's question.

> Once an ArrayBuffer is transferred and
detached, any further access will result in
some sort of TypeError, right?

Detached ArrayBuffers look like an empty
ArrayBuffers.
you can play with them using this code

let ab = new ArrayBuffer(100);
let ab2 = structuredClone(ab,  { transfer:
[ab] })
ab is empty now


On Thu, Aug 24, 2023 at 12:51 AM Yoav Weiss
 wrote:



On Wed, Aug 23, 2023 at 12:26 PM
Jonathan Hao  wrote:

Thanks for the clarification!

On Tue, Aug 22, 2023 at 9:20 PM
Eugene Zemtsov 
wrote:

A transfer list is consistent
with the approach taken by
  

Re: [blink-dev] Re: Intent to Prototype And Ship: Allow transferring ArrayBuffer into VideoFrame, AudioData, EncodedVideoChunk, EncodedAudioChunk, ImageDecoder constructors

[Chris Harrelson]

LGTM2

Would be great to file official vendor signals just so they know this is
happening, if you're willing.

On Wed, Sep 20, 2023 at 7:41 AM Yoav Weiss  wrote:

> LGTM1 given the consistency here with other platform APIs and the need to
> extend this in the future.
>
> On Tue, Sep 5, 2023 at 8:39 PM Dale Curtis 
> wrote:
>
>> I wouldn't say it's urgent, but I would hope for feedback within a week
>> or two. Thanks!
>>
>> - dale
>>
>> On Sun, Sep 3, 2023 at 4:32 AM Sangwhan Moon  wrote:
>>
>>> Thank you for filing this. If it is urgent, I could flag it as time
>>> constrained.
>>>
>>> On Aug 31, 2023, at 7:14, 'Eugene Zemtsov' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
>>> 
>>> TAG review: https://github.com/w3ctag/design-reviews/issues/889
>>>
>>> On Wed, Aug 30, 2023 at 9:50 AM Dale Curtis 
>>> wrote:
>>>
 Alex, I assume you mean TAG's views on consistency regarding transfer
 ergonomics? Otherwise
 https://www.w3.org/TR/design-principles/#consistency is what we
 followed here. We have not asked, given that we felt this was a small
 performance improvement, with pre-existing ergonomics, and already has
 Media WG approval. We can certainly file a TAG request, but as you know,
 litigating minor features like this through TAG is unlikely to have a
 timely resolution.

 Regarding Yoav's proposal above of a single boolean, that might make
 sense today where we have a single transfer, but we expect more input
 ArrayBuffers over time for some of these APIs, which would mean it becomes
 all-or-nothing for developers. E.g., we are likely to accept arrays of
 metadata, HDR data, etc. The boolean would mean they must transfer
 everything, which may lead to them making temporary copies of smaller
 buffers to get transfer effects on the larger ones.

 Daniel, sorry, that's just an oversight in the chromestatus entry.
 There are tests added (here's the one for videoFrame):

 https://chromium-review.googlesource.com/c/chromium/src/+/4529012/17/third_party/blink/web_tests/external/wpt/webcodecs/videoFrame-construction.any.js

 - dale

 On Wed, Aug 30, 2023 at 9:19 AM Daniel Bratell 
 wrote:

> In addition to Alex's question, I also noticed that you answered the
> web-platform-tests with a "no", which is a bit unexpected to me. Is there 
> a
> reason this cannot or won't be tested in web-platform-tests?
>
> /Daniel
> On 2023-08-30 18:03, Alex Russell wrote:
>
> Hey Eugene,
>
> I'm a little worried that we're debating API shape here when there
> hasn't been any guidance from the TAG on design consistency. Have you
> either asked the TAG to weigh in (didn't see a review link in the Intent)
> or asked Chromium (ex)TAG members to give the API a once-over?
>
> Best,
>
> Alex
>
> On Thursday, August 24, 2023 at 9:45:42 AM UTC-7 Eugene Zemtsov wrote:
>
>> > Can you clarify if this was in response to my questions or to
>> Jonathan's?
>>
>> Yours.
>> Sorry, I missed Jonathan's question.
>>
>> >  Once an ArrayBuffer is transferred and detached, any further
>> access will result in some sort of TypeError, right?
>>
>> Detached ArrayBuffers look like an empty ArrayBuffers.
>> you can play with them using this code
>>
>> let ab = new ArrayBuffer(100);
>> let ab2 = structuredClone(ab,  { transfer: [ab] })
>> ab is empty now
>>
>>
>> On Thu, Aug 24, 2023 at 12:51 AM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Wed, Aug 23, 2023 at 12:26 PM Jonathan Hao 
>>> wrote:
>>>
 Thanks for the clarification!

 On Tue, Aug 22, 2023 at 9:20 PM Eugene Zemtsov 
 wrote:

> A transfer list is consistent with the approach taken by
> structuredClone
> 
>  and postMessage
> 
> .
> And it's already a part of the WebCodecs spec.
>

>>> Can you clarify if this was in response to my questions or to
>>> Jonathan's?
>>>
>>>

>
> On Tue, Aug 22, 2023 at 7:36 AM Yoav Weiss 
> wrote:
>
>>
>>
>> On Tuesday, August 22, 2023 at 11:08:24 AM UTC+2 Jonathan Hao
>> wrote:
>>
>> Hi Eugene,
>>
>> Just to double check.  Once an ArrayBuffer is transferred and
>> detached, any further access will result in some sort of TypeError, 
>> right?
>>
>> Thanks,
>> Jonathan
>>
>> On Wednesday, August 16, 2023 at 10:22:00 PM UTC+1 Eugene Zemtsov
>> wrote:
>>
>> Contact emailsezemt...@google.com
>>
>> 

Re: [blink-dev] Intent to Implement and Ship: CaptureStartFocusBehavior enum value "focus-capturing-application"

['François Beaufort' via blink-dev]

On Wed, Sep 20, 2023 at 5:26 PM Yoav Weiss  wrote:

>
>
> On Tue, Sep 19, 2023 at 12:49 PM 'François Beaufort' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails
>>
>> fbeauf...@google.com
>>
>> elada...@google.com
>>
>> Explainer
>>
>> https://github.com/WICG/conditional-focus/blob/main/README.md
>>
>> Specification
>>
>>
>> https://www.w3.org/TR/screen-capture/#idl-def-CaptureStartFocusBehavior.focus-capturing-application
>>
>> Summary
>>
>> The Screen Capture API lets the user select a tab, window, or screen to
>> capture as a media stream. Using the existing CaptureController
>> setFocusBehavior() method, web apps control whether the captured tab or
>> window will be focused when capture starts, or whether the browser will
>> leave focus with whichever surface last had focus.
>>
>>
>> The new enum value "focus-capturing-application" allows web apps to give
>> a hint to the browser that the capturing page prefers to remain focused.
>> The old value "no-focus-change" now indicates that the application
>> prefers that the user agent not change focus, leaving focus with whichever
>> surface last had focus following the user's interaction with the user agent
>> and/or operating system. In Chrome’s current implementation, this means
>> leaving the capturing application focused. In the future, if Chrome adopts
>> the macOS picker, it could behave differently on Mac. This behavior could
>> prove useful for a11y-conscious applications that prefer to minimize the
>> number of focus-changes a user experiences, as those can be challenging for
>> users with screen-readers.
>>
>> Blink component
>>
>> Blink>GetDisplayMedia
>> 
>>
>> TAG review
>>
>> N/A We didn’t file a specific TAG review for this feature as the addition
>> of this enum doesn’t have any architectural changes impact to the spec and
>> the web in general.
>>
>> TAG review status
>>
>> Pending
>>
>> Risks
>> Interoperability and Compatibility
>>
>> None
>>
>
> You mentioned a semantics change around "no-focus-change". I guess it
> doesn't have any ability to break pages, at worst users will get a
> different focus than they previously did. Is that correct?
>

"focus-capturing-application" and "no-focus-change" behave the same in
Chrome.
This will not break pages as Chrome is the only browser to have shipped
Conditional Focus.

>
>
>>
>> Gecko: No signal
>>
>
> Can we file a position, as an FYI?
>

Here it is: https://github.com/mozilla/standards-positions/issues/888


>
>
>>
>> WebKit: No signal - Youenn Fablet from Apple requested this API change
>> in https://github.com/w3c/mediacapture-screen-share/issues/263.
>>
>> Web developers: No signal
>>
>> 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
>>
>> No DevTools changes are required, treated like any other attribute/enum.
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> Supported on all platforms that support getDisplayMedia. Namely, all
>> desktop platforms.
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Yes. See
>> https://wpt.fyi/results/screen-capture/getdisplaymedia-capture-controller.https.window.html
>>
>> Flag name on chrome://flags
>>
>> None
>>
>> Finch feature name
>>
>> None
>>
>> Requires code in //chrome?
>>
>> No.
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1480383
>>
>> Estimated milestones
>>
>> Shipping on desktop
>>
>> 119
>>
>> 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/5119529898475520
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5KrkGMo%3DyATVuio-rpiLcbPJb6FGyk3i%2BdfvXGuBoE-kg%40mail.gmail.com
>> 

[blink-dev] Intent to Prototype: HTMLSelectElement showPicker()

['Luke Warlow' via blink-dev]

Contact emails
lukewarlow...@gmail.com , l...@warlow.dev 


Explainer
https://github.com/whatwg/html/pull/9754

Specification
https://whatpr.org/html/9754/input.html#dom-select-showpicker

Summary
Developers have been asking for a way to programmatically open the option 
picker of a select element. See 
https://www.google.com/search?q=programmatically+open+select+site%3Astackoverflow.com

This is currently impossible in almost every browser. Providing showPicker() 
gives developers a supported way to do this. Following the pattern of 
input.showPicker().


Blink component
Blink>Forms 


Motivation
Developers have been asking for a way to programmatically open the option 
picker of a select element. See 
https://www.google.com/search?q=programmatically+open+select+site%3Astackoverflow.com

This is currently impossible in almost every browser. Providing showPicker() 
gives developers a supported way to do this. Following the pattern of 
input.showPicker().


Initial public proposal
https://github.com/whatwg/html/issues/7957

Search tags
showPicker 

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

TAG review status
Pending

Risks


Interoperability and Compatibility
None


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

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

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
No specific DevTools changes are required. This feature is treated like any 
other JS method.


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

Flag name on chrome://flags
None

Finch feature name
None

Non-finch justification
None

Requires code in //chrome?
False

Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1485010

Estimated milestones
No milestones specified


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

This intent message was generated by Chrome Platform Status 
.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/100B2378-0905-4586-8032-21F84367ED5A%40icloud.com.

Re: [blink-dev] Re: Intent to Prototype & Ship: Cookie Expires/Max-Age attribute upper limit for prior storage

[Chris Harrelson]

LGTM3

On Fri, Sep 15, 2023 at 11:43 PM Yoav Weiss  wrote:

> LGTM2
>
> On Wed, Sep 13, 2023 at 5:44 PM Daniel Bratell 
> wrote:
>
>> LGTM1
>>
>> There will be some day late in 2024, early in 2025 that will be the death
>> of many cookies. I now believe the risk of that being a problem is low
>> enough.
>>
>> /Daniel
>> On 2023-09-13 13:12, Ari Chivukula wrote:
>>
>> Re-opening this since it's been a month and we're a week after the
>> September 6th cliff where cookies in stable that were limited to 400 days
>> as of M104 start expiring (if they were not subsequently renewed).
>>
>> I haven't seen any negative feedback or questions around unexpected
>> cookie expirations in the past week and the latest metrics show < .035% of
>> page loads (and falling) sending cookies that had not been renewed in the
>> last 350-400 days.
>>
>> I think it's reasonable to impose the same limit on cookies that happened
>> to be stored before M104 as the limit imposed on those after (the 400 day
>> expiration cap) and we should do so in M119.
>>
>> It's important to note this cap will *not* simply retroactively expire
>> all older cookies but instead cap any cookies with expirations more than
>> 400 days after M119+ is first launched by a user to expire no more than 400
>> days after that time. For example:
>>
>> Site X stored Cookie Y pre-M104 expires January 1, .
>> M119 first launched by user January 1, 2024.
>> Cookie Y now expires February 4, 2025.
>> Site X renews Cookie Y by storing it again January 1, 2025.
>> Cookie Y now expires February 5, 2026.
>>
>> ~ Ari Chivukula (Their/There/They're)
>>
>>
>> On Fri, Aug 11, 2023 at 6:23 PM Ari Chivukula 
>> wrote:
>>
>>> I have no objections to delaying until M119. I'll check back in a week
>>> or two after the September 6 cliff when cookies in stable that were limited
>>> to 400 days as of M104 start expiring. It's important to note we will only
>>> be able to discuss the presence of lack of bug reports from sites and users
>>> (there won't be other additional data available).
>>>
>>> ~ Ari Chivukula (Their/There/They're)
>>>
>>> On Fri, Aug 11, 2023, 07:14 Mike Taylor  wrote:
>>>
 Perhaps we could delay this change until M119 as I understand that the
 first cookies that were set more than 400 days ago are due to expire in the
 M118 window. That should give us some time to understand the impact in more
 concrete terms and mitigate some of the impact, were it to turn out to that
 400 days is not the right balance between utility and protecting users.

 (I should note that I'm supportive of this change as proposed as a net
 positive for security, but am recused from voting on it.)
 On 8/10/23 9:52 AM, Ari Chivukula wrote:

 It's true we don't have a lot of data on the impact of this
 specifically, but part of that is due to 400 day lag between enforcement
 and anyone in prod feeling the effects. We could try to produce data on the
 amount of cookies already in the store that would be newly capped, but that
 won't really tell us what will happen if they expire a year from now.

 Some sites may have to adapt their preferences to be re-written to the
 cookie store if they haven't already, but this change is starting another
 400 day counter for sites to adapt the same way was done a year ago.

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

 On Thu, Aug 3, 2023, 05:45 Daniel Bratell  wrote:

> So my assumption is the pessimistic one that most sites won't notice
> this policy change even if we publish posts about it. And even if users 
> and
> sites can survive lost cookies, it might still be a disruption that was
> unexpected and unwanted. But I don't have any good idea of how disruptive
> and how common it will be. It might not be a real problem at all, but I am
> missing the knowledge and data to understand what the size of the risk is.
>
> My hope was that you would have some information or data that would
> show to me that there is nothing to be concerned about. I don't think I'm
> there yet, but if cookies are already limited to 400 days, that is a good
> indication it can't be too much of a problem.
>
> /Daniel
> On 2023-08-03 14:03, Ari Chivukula wrote:
>
> I guess I'm a little confused on the direction of the conversation. If
> a user starts using chrome today no cookie can set an expiration date more
> than 400 days in the future, so all sites must already adapt to that
> present reality.
>
> Some users with cookies stored before this limit was imposed around a
> year ago have cookies that expire years in the future. After this change
> via a DB migration, those cookies would be capped to 400 days after the DB
> migration was run. No user will lose cookies in the DB migration itself.
>
> I don't think we know how many sites depend on cookies that are set
> once and 

Re: [blink-dev] Intent to Implement and Ship: CaptureStartFocusBehavior enum value "focus-capturing-application"

[Yoav Weiss]

On Tue, Sep 19, 2023 at 12:49 PM 'François Beaufort' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> fbeauf...@google.com
>
> elada...@google.com
>
> Explainer
>
> https://github.com/WICG/conditional-focus/blob/main/README.md
>
> Specification
>
>
> https://www.w3.org/TR/screen-capture/#idl-def-CaptureStartFocusBehavior.focus-capturing-application
>
> Summary
>
> The Screen Capture API lets the user select a tab, window, or screen to
> capture as a media stream. Using the existing CaptureController
> setFocusBehavior() method, web apps control whether the captured tab or
> window will be focused when capture starts, or whether the browser will
> leave focus with whichever surface last had focus.
>
>
> The new enum value "focus-capturing-application" allows web apps to give
> a hint to the browser that the capturing page prefers to remain focused.
> The old value "no-focus-change" now indicates that the application
> prefers that the user agent not change focus, leaving focus with whichever
> surface last had focus following the user's interaction with the user agent
> and/or operating system. In Chrome’s current implementation, this means
> leaving the capturing application focused. In the future, if Chrome adopts
> the macOS picker, it could behave differently on Mac. This behavior could
> prove useful for a11y-conscious applications that prefer to minimize the
> number of focus-changes a user experiences, as those can be challenging for
> users with screen-readers.
>
> Blink component
>
> Blink>GetDisplayMedia
> 
>
> TAG review
>
> N/A We didn’t file a specific TAG review for this feature as the addition
> of this enum doesn’t have any architectural changes impact to the spec and
> the web in general.
>
> TAG review status
>
> Pending
>
> Risks
> Interoperability and Compatibility
>
> None
>

You mentioned a semantics change around "no-focus-change". I guess it
doesn't have any ability to break pages, at worst users will get a
different focus than they previously did. Is that correct?


>
> Gecko: No signal
>

Can we file a position, as an FYI?


>
> WebKit: No signal - Youenn Fablet from Apple requested this API change in
> https://github.com/w3c/mediacapture-screen-share/issues/263.
>
> Web developers: No signal
>
> 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
>
> No DevTools changes are required, treated like any other attribute/enum.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> Supported on all platforms that support getDisplayMedia. Namely, all
> desktop platforms.
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes. See
> https://wpt.fyi/results/screen-capture/getdisplaymedia-capture-controller.https.window.html
>
> Flag name on chrome://flags
>
> None
>
> Finch feature name
>
> None
>
> Requires code in //chrome?
>
> No.
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1480383
>
> Estimated milestones
>
> Shipping on desktop
>
> 119
>
> 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/5119529898475520
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5KrkGMo%3DyATVuio-rpiLcbPJb6FGyk3i%2BdfvXGuBoE-kg%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/CAL5BFfUZTKkRj2wZ%2B%3DbQ2sX7uZBnAPjBCku8zpChQfRx02QkdA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: WebRTC Codec Selection API

[Yoav Weiss]

LGTM1

On Wed, Sep 20, 2023 at 11:48 AM Florent Castelli 
wrote:

> Contact emailsorp...@chromium.org
>
> Explainer
> https://github.com/Orphis/webrtc-extensions/blob/explainer/explainers/codec-selection.md
>
> Specification
> https://w3c.github.io/webrtc-extensions/#dom-rtcrtpencodingparameters-codec
>
> Summary
>
> This new API extends WebRTC encoding parameters to allow developers to
> choose a specific negotiated codec to be used for encoding an RTP stream.
>
>
> Blink componentBlink>WebRTC>PeerConnection
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/836
>
> TAG review statusIssues addressed
>
> Risks
>
>
> Interoperability and Compatibility
>
> Interoperability risks are low. This is a new dictionary member and API
> surface, if it isn't used by current applications, it should not cause any
> impact on compatibility.
>
>
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/789)
>
> *WebKit*: Positive (
> https://github.com/WebKit/standards-positions/issues/179)
>
> *Web developers*: No signals
>

Presumably this is something WebRTC developers are interested in. Any ways
you can think of to extract such a signal for WebRTC things in the future?


>
> Ergonomics
>
> No ergonomic risks. This API is part of WebRTC and will be used with other
> encoding parameters. One of its goals is to improve the WebRTC ergonomics
> by removing the need to make several calls with possible side effects to
> change the active codec, which should improve performance as well.
>
>
> Debuggability
>
> WebRTC is not supported by DevTools at the moment.
> chrome://webrtc-internals will reflect in the RTP stream statistics which
> codec is currently used.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
> Flag name on chrome://flags
>
> Finch feature nameRTCRtpEncodingParametersCodec
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1442194
>
> Estimated milestones
> Shipping on desktop 119
> Shipping on Android 119
> Shipping on WebView 119
> Shipping on WebView 119
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5200982281027584
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADRnnSXEi2i3DzkXQo1ptX-KR%2BULh-4LOt5zpOi14BTstZN_9g%40mail.gmail.com
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADRnnSXo_QcNo%3DSXCxq_bh%2BMEhoUY6FCDJK%3D3q%3DkDr4xs1yUbw%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/CAL5BFfWiHahdq-JhnJwLPTQrPSycYPdQby3ri_zJBzqhvT8s5w%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Horizontal rules inside select elements

[Joey Arhar]

> Can we file a Mozilla position? (to raise awareness on their end if
nothing else)

https://github.com/mozilla/standards-positions/issues/887

> Have you talked to devrel folks about getting some signal there?
Presumably this is something developers would want to be able to do

I just reached out to devrel about this



On Wed, Sep 20, 2023 at 7:54 AM Yoav Weiss  wrote:

> LGTM1
>
> On Tue, Sep 19, 2023 at 7:51 PM Joey Arhar  wrote:
>
>> Contact emailsjar...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://github.com/whatwg/html/pull/9124
>>
>> Summary
>>
>> This feature makes the HTML parser allow  tags inside  tags.
>> These  elements create horizontal borders in between  elements
>> in the listbox popup, which we already support if you manually insert an hr
>> element with javascript.
>>
>
> Neat!
>
>
>>
>> WebKit implemented this and just put it in their release notes:
>> https://webkit.org/blog/14445/webkit-features-in-safari-17-0/#:~:text=Horizontal%20rules%20inside%20select%20elements
>>
>> Blink componentBlink>DOM
>> 
>>
>> TAG reviewNone
>>
>
> You spelled "Not required as this landed in HTML and shipped in WebKit"
> wrong :)
>
>
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> None
>>
>>
>> *Gecko*: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1830909)
>>
>
> Can we file a Mozilla position? (to raise awareness on their end if
> nothing else)
>
>
>> *WebKit*: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=80686
>> )
>>
>> *Web developers*: No signals
>>
>
> Have you talked to devrel folks about getting some signal there?
> Presumably this is something developers would want to be able to do
>
>
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None
>>
>>
>> Debuggability
>>
>> None
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes
>>
>> Flag name on chrome://flagsSelectHr
>>
>> Finch feature nameSelectHr
>>
>> Requires code in //chrome?False
>>
>> Estimated milestones
>> Shipping on desktop 118
>> DevTrial on desktop 118
>> Shipping on Android 118
>> DevTrial on Android 118
>> Shipping on WebView 118
>>
>> 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/6198448366026752
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKBrQrrtOe4FwDfYR_nx%3DhXPEv2Yu10h407iPn2y3d9mA%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/CAK6btw%2BmiJ6t4dK_AbdZLfZQ5DCRc1oR%2B-D66U3cU0sssrQPEg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Horizontal rules inside select elements

[Yoav Weiss]

LGTM1

On Tue, Sep 19, 2023 at 7:51 PM Joey Arhar  wrote:

> Contact emailsjar...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://github.com/whatwg/html/pull/9124
>
> Summary
>
> This feature makes the HTML parser allow  tags inside  tags.
> These  elements create horizontal borders in between  elements
> in the listbox popup, which we already support if you manually insert an hr
> element with javascript.
>

Neat!


>
> WebKit implemented this and just put it in their release notes:
> https://webkit.org/blog/14445/webkit-features-in-safari-17-0/#:~:text=Horizontal%20rules%20inside%20select%20elements
>
> Blink componentBlink>DOM
> 
>
> TAG reviewNone
>

You spelled "Not required as this landed in HTML and shipped in WebKit"
wrong :)


>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1830909)
>

Can we file a Mozilla position? (to raise awareness on their end if nothing
else)


> *WebKit*: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=80686)
>
> *Web developers*: No signals
>

Have you talked to devrel folks about getting some signal there? Presumably
this is something developers would want to be able to do


>
> *Other signals*:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Debuggability
>
> None
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
> Flag name on chrome://flagsSelectHr
>
> Finch feature nameSelectHr
>
> Requires code in //chrome?False
>
> Estimated milestones
> Shipping on desktop 118
> DevTrial on desktop 118
> Shipping on Android 118
> DevTrial on Android 118
> Shipping on WebView 118
>
> 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/6198448366026752
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKBrQrrtOe4FwDfYR_nx%3DhXPEv2Yu10h407iPn2y3d9mA%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/CAL5BFfVsOQOUXm%3DXJvHms%2BSaca-PxXSN-bN0dXWz2SfR78XsOA%40mail.gmail.com.

[blink-dev] PSA: Minor additions to WebGPU

[Corentin Wallez]

Hey all,

We are doing two minor additions to WebGPU that we believe have zero
compatibility risk:

   - The addition of "rgb10a2uint"
   
   as a GPUTextureFormat. This format was forgotten by the WebGPU group when
   making the initial list of GPUTextureFormats. Both WebKit and Firefox were
   in favor of adding it during the WebGPU meeting
   

   .
   - The enablement of the "float32-filterable"
    optional feature.
   Likewise it was easily agreed to in the WebGPU group, see minutes
   

   .

Cheers,

Corentin

-- 
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/CAGdfWNP0P-iWMb5hqW53Oc1eSoVwOiKUjnczq%2BRxJ8RN7s6qVw%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Prototype And Ship: Allow transferring ArrayBuffer into VideoFrame, AudioData, EncodedVideoChunk, EncodedAudioChunk, ImageDecoder constructors

[Yoav Weiss]

LGTM1 given the consistency here with other platform APIs and the need to
extend this in the future.

On Tue, Sep 5, 2023 at 8:39 PM Dale Curtis  wrote:

> I wouldn't say it's urgent, but I would hope for feedback within a week or
> two. Thanks!
>
> - dale
>
> On Sun, Sep 3, 2023 at 4:32 AM Sangwhan Moon  wrote:
>
>> Thank you for filing this. If it is urgent, I could flag it as time
>> constrained.
>>
>> On Aug 31, 2023, at 7:14, 'Eugene Zemtsov' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>> 
>> TAG review: https://github.com/w3ctag/design-reviews/issues/889
>>
>> On Wed, Aug 30, 2023 at 9:50 AM Dale Curtis 
>> wrote:
>>
>>> Alex, I assume you mean TAG's views on consistency regarding transfer
>>> ergonomics? Otherwise
>>> https://www.w3.org/TR/design-principles/#consistency is what we
>>> followed here. We have not asked, given that we felt this was a small
>>> performance improvement, with pre-existing ergonomics, and already has
>>> Media WG approval. We can certainly file a TAG request, but as you know,
>>> litigating minor features like this through TAG is unlikely to have a
>>> timely resolution.
>>>
>>> Regarding Yoav's proposal above of a single boolean, that might make
>>> sense today where we have a single transfer, but we expect more input
>>> ArrayBuffers over time for some of these APIs, which would mean it becomes
>>> all-or-nothing for developers. E.g., we are likely to accept arrays of
>>> metadata, HDR data, etc. The boolean would mean they must transfer
>>> everything, which may lead to them making temporary copies of smaller
>>> buffers to get transfer effects on the larger ones.
>>>
>>> Daniel, sorry, that's just an oversight in the chromestatus entry. There
>>> are tests added (here's the one for videoFrame):
>>>
>>> https://chromium-review.googlesource.com/c/chromium/src/+/4529012/17/third_party/blink/web_tests/external/wpt/webcodecs/videoFrame-construction.any.js
>>>
>>> - dale
>>>
>>> On Wed, Aug 30, 2023 at 9:19 AM Daniel Bratell 
>>> wrote:
>>>
 In addition to Alex's question, I also noticed that you answered the
 web-platform-tests with a "no", which is a bit unexpected to me. Is there a
 reason this cannot or won't be tested in web-platform-tests?

 /Daniel
 On 2023-08-30 18:03, Alex Russell wrote:

 Hey Eugene,

 I'm a little worried that we're debating API shape here when there
 hasn't been any guidance from the TAG on design consistency. Have you
 either asked the TAG to weigh in (didn't see a review link in the Intent)
 or asked Chromium (ex)TAG members to give the API a once-over?

 Best,

 Alex

 On Thursday, August 24, 2023 at 9:45:42 AM UTC-7 Eugene Zemtsov wrote:

> > Can you clarify if this was in response to my questions or to
> Jonathan's?
>
> Yours.
> Sorry, I missed Jonathan's question.
>
> >  Once an ArrayBuffer is transferred and detached, any further
> access will result in some sort of TypeError, right?
>
> Detached ArrayBuffers look like an empty ArrayBuffers.
> you can play with them using this code
>
> let ab = new ArrayBuffer(100);
> let ab2 = structuredClone(ab,  { transfer: [ab] })
> ab is empty now
>
>
> On Thu, Aug 24, 2023 at 12:51 AM Yoav Weiss 
> wrote:
>
>>
>>
>> On Wed, Aug 23, 2023 at 12:26 PM Jonathan Hao 
>> wrote:
>>
>>> Thanks for the clarification!
>>>
>>> On Tue, Aug 22, 2023 at 9:20 PM Eugene Zemtsov 
>>> wrote:
>>>
 A transfer list is consistent with the approach taken by
 structuredClone
 
  and postMessage
 
 .
 And it's already a part of the WebCodecs spec.

>>>
>> Can you clarify if this was in response to my questions or to
>> Jonathan's?
>>
>>
>>>

 On Tue, Aug 22, 2023 at 7:36 AM Yoav Weiss 
 wrote:

>
>
> On Tuesday, August 22, 2023 at 11:08:24 AM UTC+2 Jonathan Hao
> wrote:
>
> Hi Eugene,
>
> Just to double check.  Once an ArrayBuffer is transferred and
> detached, any further access will result in some sort of TypeError, 
> right?
>
> Thanks,
> Jonathan
>
> On Wednesday, August 16, 2023 at 10:22:00 PM UTC+1 Eugene Zemtsov
> wrote:
>
> Contact emailsezemt...@google.com
>
> Explainerhttps://gist.github.com/Djuffi
> n/1c8fac486ca9f402be85074166e89a16
>
> Specificationhttps://www.w3.org/TR/webcodec
> s/#dictdef-videoframeinit
>
> Summary
>
> This will allow detaching array buffers and using corresponding
> buffers inside VideoFrame, ImageDecoder, 

Re: [EXTERNAL]_Re: [blink-dev] Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

[Chinmay Manchanda]

Thanks for the update,

Would you please clarify these for me?


  *   The disclosure in the deprecation trial mentions a 0.5% limit on using 
the feature tracked on the chrome page loads. Is that limit per origin or on 
all chrome page loads globally?
  *   The thirdPartyStoragePartitioning will only be rolled out to Chrome 115 
and above, is that correct?
  *   We noticed a couple of cases where it seems to be disabled on windows 10 
setups, is that in the rollout by design or is it a happy coincidence that 
these setups were not in the 50% rollout?

Cheers,
Chinmay

Get Outlook for iOS

From: Kyra Seevers 
Sent: Wednesday, September 20, 2023 10:53:11 PM
To: Chinmay Manchanda 
Cc: blink-dev ; Kyra Seevers 
Subject: [EXTERNAL]_Re: [blink-dev] Intent to Ship: Partitioning Storage, 
Service Workers, and Communication APIs

Hi Chinmay,

Thanks for reaching out! Due to internal delays, we won't be rolling out to 
Stable 100% likely until the end of the week or the beginning of next week. 
I'll keep the thread updated with any further delays.

Thanks,
Kyra

On Tue, Sep 19, 2023 at 7:50 PM Chinmay Manchanda 
mailto:cmancha...@tyro.com>> wrote:
Hi Kyra,

Do we have an update on what time the feature will be rolled out today?

Cheers,
Chinmay

On Tuesday, 12 September 2023 at 18:06:57 UTC+10 Kyra Seevers wrote:
Hi Muhammad,

I have filed this bug for the issue: 
https://bugs.chromium.org/p/chromium/issues/detail?id=1481485. We would 
appreciate it if you could describe your set-up with more detail in this bug. 
Have you registered for the deprecation trial described here?: 
https://developer.chrome.com/en/blog/storage-partitioning-deprecation-trial/

Thanks,
Kyra

On Mon, Sep 11, 2023 at 10:48 PM Muhammad Ahmed Mallick  
wrote:
Hi All,
I'm also facing challenges with the current situation. We're loading my own 
website within the Chrome extension, and we manage the user's login state 
(tokens) on my website. The extension's iframe is supposed to retrieve the 
token from local storage, but it's currently broken. It's not feasible to ask 
the user to log in twice just to access the extension's content.

Please let me know if there is any solution to get it fixed asap.

Thanks
Ahmed

On Wednesday, September 6, 2023 at 2:03:55 PM UTC+5 Kyra Seevers wrote:
Hi all,

Another quick update: we began the rollout to 50% stable today.

We will roll-out to 100% of Stable users on approximately Sept. 20th, 2023.

Thanks,
Kyra

On Thu, Aug 24, 2023 at 3:48 PM Mike Taylor  wrote:

I've filed https://bugs.chromium.org/p/chromium/issues/detail?id=1475667 - it 
would be great if you both could give more context about your embedded 
application, and how you deal with Safari and Firefox as comments in the bug 
(same goes for anyone else facing this issue).

thanks,
Mike

On 8/24/23 8:45 AM, Tim Williams wrote:
We have the same situation as Junji here.
For us, it means that our solution would be broken across all websites since 
the platforms are using our iframe URL and we have 0 ability to inject code at 
their top Domain (nor do we want to).
On Wednesday, August 23, 2023 at 8:33:57 PM UTC+3 Junji Genesys wrote:
Our application has no access to the top-level context, so there is no way for 
us to include our third-party trial script in the top-level context.
We basically provide Salesforce with our embedded client URL, and they use it 
to load and embed our client in their iframe.

On Wed, Aug 23, 2023 at 11:30 AM Mike Taylor  wrote:

Yes, if you sign up for a 3rd party token and inject that into the site 
embedding your iframe before your iframe is created, that will give you access 
to unpartitioned storage (until the Deprecation Trial expires).

Here's a demo that injects an 3P origin trial token then creates an iframe:

https://rogue-lace-join.glitch.me/

And the relevant source files:

https://glitch.com/edit/#!/rogue-lace-join?path=index.html%3A9%3A8
https://miketaylr.com/misc/3pspdt.js

Feel free to reach out to me off-list to discuss more or if you have any 
further questions.

On 8/22/23 11:40 PM, Yoav Weiss wrote:
Is your application running script in the top level context? Since the 
deprecation trial is implemented as a third-party origin trial, you may be able 
to sign up as a third party.

On Tue, Aug 22, 2023, 23:48 Junji Genesys  wrote:
Hello Kyra,

Thank you for communicating about the rollout plan for the storage partitioning.

We've found that the new storage partitioning behavior has impacted our 
product, which is a web client application embedded in an iframe inside 
Salesforce and provides call center agents functionality such as handling phone 
calls. We use browser-based phone (WebRTC phone) that can pop out as a separate 
window, which communicates with the embedded client frame via localStorage and 
BroadcastChannel. The new storage partitioning restriction blocks this 
communication as our application is running as an embedded iframe with a 

Re: [blink-dev] Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

['Kyra Seevers' via blink-dev]

Hi Chinmay,

Thanks for reaching out! Due to internal delays, we won't be rolling out to
Stable 100% likely until the end of the week or the beginning of next week.
I'll keep the thread updated with any further delays.

Thanks,
Kyra

On Tue, Sep 19, 2023 at 7:50 PM Chinmay Manchanda 
wrote:

> Hi Kyra,
>
> Do we have an update on what time the feature will be rolled out today?
>
> Cheers,
> Chinmay
>
> On Tuesday, 12 September 2023 at 18:06:57 UTC+10 Kyra Seevers wrote:
>
>> Hi Muhammad,
>>
>> I have filed this bug for the issue:
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1481485. We would
>> appreciate it if you could describe your set-up with more detail in this
>> bug. Have you registered for the deprecation trial described here?:
>> https://developer.chrome.com/en/blog/storage-partitioning-deprecation-trial/
>>
>> Thanks,
>> Kyra
>>
>> On Mon, Sep 11, 2023 at 10:48 PM Muhammad Ahmed Mallick <
>> amal...@folio3.com> wrote:
>>
>>> Hi All,
>>> I'm also facing challenges with the current situation. We're loading my
>>> own website within the Chrome extension, and we manage the user's login
>>> state (tokens) on my website. The extension's iframe is supposed to
>>> retrieve the token from local storage, but it's currently broken. It's not
>>> feasible to ask the user to log in twice just to access the extension's
>>> content.
>>>
>>> Please let me know if there is any solution to get it fixed asap.
>>>
>>> Thanks
>>> Ahmed
>>>
>>> On Wednesday, September 6, 2023 at 2:03:55 PM UTC+5 Kyra Seevers wrote:
>>>
 Hi all,

 Another quick update: we began the rollout to 50% stable today.

 We will roll-out to 100% of Stable users on approximately Sept. 20th,
 2023.

 Thanks,
 Kyra

 On Thu, Aug 24, 2023 at 3:48 PM Mike Taylor 
 wrote:

> I've filed
> https://bugs.chromium.org/p/chromium/issues/detail?id=1475667 - it
> would be great if you both could give more context about your embedded
> application, and how you deal with Safari and Firefox as comments in the
> bug (same goes for anyone else facing this issue).
>
> thanks,
> Mike
> On 8/24/23 8:45 AM, Tim Williams wrote:
>
> We have the same situation as Junji here.
> For us, it means that our solution would be broken across all websites
> since the platforms are using our iframe URL and we have 0 ability to
> inject code at their top Domain (nor do we want to).
> On Wednesday, August 23, 2023 at 8:33:57 PM UTC+3 Junji Genesys wrote:
>
>> Our application has no access to the top-level context, so there is
>> no way for us to include our third-party trial script in the top-level
>> context.
>> We basically provide Salesforce with our embedded client URL, and
>> they use it to load and embed our client in their iframe.
>>
>> On Wed, Aug 23, 2023 at 11:30 AM Mike Taylor 
>> wrote:
>>
>>> Yes, if you sign up for a 3rd party token and inject that into the
>>> site embedding your iframe before your iframe is created, that will give
>>> you access to unpartitioned storage (until the Deprecation Trial 
>>> expires).
>>>
>>> Here's a demo that injects an 3P origin trial token then creates an
>>> iframe:
>>>
>>> https://rogue-lace-join.glitch.me/
>>>
>>> And the relevant source files:
>>>
>>> https://glitch.com/edit/#!/rogue-lace-join?path=index.html%3A9%3A8
>>> https://miketaylr.com/misc/3pspdt.js
>>>
>>> Feel free to reach out to me off-list to discuss more or if you have
>>> any further questions.
>>> On 8/22/23 11:40 PM, Yoav Weiss wrote:
>>>
>>> Is your application running script in the top level context? Since
>>> the deprecation trial is implemented as a third-party origin trial, you 
>>> may
>>> be able to sign up as a third party.
>>>
>>> On Tue, Aug 22, 2023, 23:48 Junji Genesys 
>>> wrote:
>>>
 Hello Kyra,

 Thank you for communicating about the rollout plan for the storage
 partitioning.

 We've found that the new storage partitioning behavior has impacted
 our product, which is a web client application embedded in an iframe 
 inside
 Salesforce and provides call center agents functionality such as 
 handling
 phone calls. We use browser-based phone (WebRTC phone) that can pop 
 out as
 a separate window, which communicates with the embedded client frame 
 via
 localStorage and BroadcastChannel. The new storage partitioning 
 restriction
 blocks this communication as our application is running as an embedded
 iframe with a top-level domain that differs from our browser phone 
 running
 in a popped out window. Our browser phone does not work properly in 
 that
 scenario, and as a result, users are not able to answer 

[blink-dev] Intent to Implement: WebGL drawingBufferStorage

['Christopher Cameron' via blink-dev]

Contact emailsccame...@chromium.org

Specificationhttps://github.com/KhronosGroup/WebGL/pull/3222

Summary

Allows WebGL to specify the format of its backbuffer. In particular, allows
floating-point (for use with wide color and high dynamic range) and
sRGB-encoded (for 8-bit physically based rendering) framebuffers.


Blink componentBlink>WebGL


Motivation

This is required for HDR support in WebGL and has been requested by several
partners.

TAG reviewN/A

Risks


Interoperability and Compatibility

None.


*Gecko*: Positive Feature authored by Mozilla.

*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


Is this feature fully tested by web-platform-tests

?
No, WebGL is tested using the WebGL conformance tests.

Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?No

Estimated milestones

No milestones specified


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

-- 
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/CAGnfxj-HFt%3Dk5NBHb5SyNT0ERn6w13S3U8%3DBjV8-4EB4EUoAkw%40mail.gmail.com.

[blink-dev] Intent to Ship: WebRTC Codec Selection API

[Florent Castelli]

Contact emailsorp...@chromium.org

Explainer
https://github.com/Orphis/webrtc-extensions/blob/explainer/explainers/codec-selection.md

Specification
https://w3c.github.io/webrtc-extensions/#dom-rtcrtpencodingparameters-codec

Summary

This new API extends WebRTC encoding parameters to allow developers to
choose a specific negotiated codec to be used for encoding an RTP stream.


Blink componentBlink>WebRTC>PeerConnection


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

TAG review statusIssues addressed

Risks


Interoperability and Compatibility

Interoperability risks are low. This is a new dictionary member and API
surface, if it isn't used by current applications, it should not cause any
impact on compatibility.


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

*WebKit*: Positive (https://github.com/WebKit/standards-positions/issues/179
)

*Web developers*: No signals

Ergonomics

No ergonomic risks. This API is part of WebRTC and will be used with other
encoding parameters. One of its goals is to improve the WebRTC ergonomics
by removing the need to make several calls with possible side effects to
change the active codec, which should improve performance as well.


Debuggability

WebRTC is not supported by DevTools at the moment.
chrome://webrtc-internals will reflect in the RTP stream statistics which
codec is currently used.


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

Is this feature fully tested by web-platform-tests

?Yes

Flag name on chrome://flags

Finch feature nameRTCRtpEncodingParametersCodec

Requires code in //chrome?False

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

Estimated milestones
Shipping on desktop 119
Shipping on Android 119
Shipping on WebView 119
Shipping on WebView 119


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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADRnnSXEi2i3DzkXQo1ptX-KR%2BULh-4LOt5zpOi14BTstZN_9g%40mail.gmail.com

This intent message was generated by Chrome Platform Status
.

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