[blink-dev] Intent to Extend Experiment: Tabbed web apps

[Brett Wilson]

Hi Blink owners,

We would like to apply to extend the Tabbed web apps
 origin trial until
November 26th, 2024.

This API is already approved to ship in 126 (Intent to Ship thread
)
and the flag has been enabled in the 126 branch.

However, we have noticed an issue with the origin trial system which will
create a significant gap in functionality for ChromeOS Long-Term Support
(LTS) users. Currently, the origin trial is set to expire

on August 7th, 2024, which is 6 weeks after 126 stable starts rolling out
on ChromeOS. However, per Chromium Dash
, M126 will only be released to
ChromeOS LTS users on October 1, 2024, which is 8 weeks after the origin
trial expires. This means ChromeOS LTS users who have installed apps that
use the Tabbed Mode origin trial in M120 will see those apps automatically
revert to standalone (non-tabbed) windows, which may be an experience the
application authors never intended users to see, and have that unintended
experience linger for over 8 weeks.

Therefore, we are taking the unusual step of asking for an extension even
though the API is already shipping. Since ChromeOS LTS begins rolling out
on October 1, we are asking for an extension until 8 weeks after that date,
which is November 26th. This will ensure a majority of LTS users have
upgraded to 126 before the origin trial expires.

We understand that the extension of origin trials is taken seriously to
avoid burn-in risk and also to avoid an incentive to hold back on older
versions of browsers. However, neither of those apply in this case: with
the API already shipping in 126, the burn-in issue is moot. And there is no
incentive to hold back the browser version as the API will be available in
newer versions anyway. Therefore, this is not extending the exposure risk
of the API, it is just ensuring that users who are still on older versions
will have enough time to upgrade before the feature disappears from those
old versions.

Thank you,
Brett

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

[blink-dev] Intent to Extend Deprecation Trial: Restrict "private network requests" for subresources from public websites to secure contexts.

[Emily Stark]

Contact emailsest...@google.com, jdebla...@google.com, dadr...@google.com,
l...@chromium.org, tito...@chromium.org, cl...@chromium.org,
mk...@chromium.org, v...@chromium.org

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

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

Design docs
https://docs.google.com/document/d/1x1a1fQLOrcWogK3tpFBgQZQ5ZjcONTvD0IqqXkgrg5I/edit#heading=h.7nki9mck5t64

Summary

Requires that private network requests for subresources from public
websites may only be initiated from a secure context. Examples include
internet to intranet requests and internet to loopback requests. This is a
first step towards fully implementing Private Network Access:
https://wicg.github.io/private-network-access/


Blink componentBlink>SecurityFeature>CORS>PrivateNetworkAccess


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

TAG review statusIssues addressed

Chromium Trial NamePrivateNetworkAccessNonSecureContextsAllowed

Link to origin trial feedback summary
https://docs.google.com/spreadsheets/d/1z5ZdCslNCnSVR7TNlUTHjSvunMFmT_9G9NOx8-O78-I/edit?usp=sharing=0-DITlG8tDuFDWHiBUHnlSoQ

Origin Trial documentation link
https://developer.chrome.com/blog/private-network-access-update/

WebFeature UseCounter name
kPrivateNetworkAccessNonSecureContextsAllowedDeprecationTrial

Risks


Interoperability and Compatibility

No interoperability risks. Compatibility risk is small but non-negligible.
UseCounters show ~0.1% of page visit making use of this feature. Direct
outreach to the largest users per UKM data revealed no objections to this
launch. Rolling this deprecation out to beta per the previous I2S resulted
in more feedback about the compatibility risk and the need for a time
extension. See the following doc for an extensive discussion:
https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit


*Gecko*: Closed Without a Position (
https://github.com/mozilla/standards-positions/issues/143) Tentatively
positive, but no formal position yet.

*WebKit*: Positive (
https://lists.webkit.org/pipermail/webkit-dev/2021-May/031837.html)

*Web developers*: Mixed signals (
https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit)
In our recent survey, most of websites are able to migrate if our new
permission prompt can be landed as a way for them to relax mixed content
checks.
https://docs.google.com/spreadsheets/d/1z5ZdCslNCnSVR7TNlUTHjSvunMFmT_9G9NOx8-O78-I/edit?resourcekey=0-DITlG8tDuFDWHiBUHnlSoQ#gid=309953809

Some websites, broadly falling in the category of controller webapps for
IoT devices, find this change incompatible with their use cases. While many
use cases can be solved with specific workarounds, some still require
further engagement.

*Other signals*:

Activation

Developers of non-secure sites that rely upon local servers will need to
upgrade to HTTPS. This might cause some complications, as mixed-content
checks will begin to apply. Chrome carves out HTTP access to loopback (as
perhttps://w3c.github.io/webappsec-secure-contexts/#localhost), which is a
release valve for folks who don't want to go through the effort of
securely-distributing certs for local servers. The initial launch in M92
was delayed due to compatibility risks surfaced during the rollout to beta.
See this doc for a lot more details:
https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit


Security

This change should be security-positive.


WebView application risks

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



Goals for experimentation



Reason this experiment is being extended

The blocker to shipping this feature is that some websites can't create
HTTPS connections to subresources on the private network due to various
constraints (e.g., unable to obtain a publicly trusted HTTPS certificate).
A permission prompt is in development (
https://groups.google.com/a/chromium.org/g/blink-dev/c/sL15TKGmXqM/m/rD0SF8sQBwAJ)
to allow such subresources to be loaded over HTTP (whereas they would
usually be blocked by mixed content rules). However, the permission prompt
currently only works for fetch() and does not work in iframes, thus we need
to investigate whether we need to support use cases not supported by the
current implementation. The overall Private Network Access project is also
currently being transitioned between teams, so the extension request
includes some time for handoff/rampup.

Ongoing technical constraints

None.


Debuggability

When a request is made that violates this restriction and the feature is
not enabled, three things happen: 1. A warning message is logged to the
DevTools console. 2. A deprecation report is filed against the initiator
website's 

Re: [blink-dev] Intent to Ship: Dispatch selectionchange event per element

[Chris Harrelson]

LGTM3 for the first CL

On Thu, May 30, 2024 at 6:22 PM Domenic Denicola 
wrote:

> LGTM2, to land the first CL.
>
> Thanks for explaining. It sounds like the first CL, which this Intent is
> covering, is purely additive and should not have significant compatibility
> risk. It also brings us in line with the behavior Firefox has had for a
> long time, and the behavior that WebKit has recently adopted.
>
> I look forward to your second Intent to Ship for the second CL, which will
> require more caution.
>
> On Thursday, May 30, 2024 at 4:52:23 PM UTC+9 shuangsh...@intel.com wrote:
>
>> Hi Yoav, thanks for the feedback. I'll make it more clear.
>>
>> Generally speaking, the final goal is that, we want to avoid queuing a
>> task to dispatch a selectionchange event when there is already a task
>> scheduled to do that. This is to catch up the latest spec:
>> https://w3c.github.io/selection-api/#scheduling-selectionhange-event.
>> Currently we divide this into 2 steps with one CL for each step to
>> impelment this goal.
>>
>> In this issue, we'd like to land *the first CL* that updates the
>> implementation of selectionchange event to be fired on input element and
>> textarea element instead of document. So the difference in the first CL is:
>>
>>1. The old behaviour:  When the element(input/textarea) provides a
>>text selectionchange or its selection changes, we dispatch a
>>selectionchange event on the document directly.
>>2. The new behaviour: The new codes goes to that, in the same
>>situations, if the selection changes, we fire this event first on the
>>element(input/textarea) itself, and then it would be bubbled to the 
>> doument.
>>
>>
>> So, the final results are the same that, we finally get a selectionchange
>> event on the document. *The feature in this issue* is mainly to do this
>> change. After the first CL is landed, then we come to the second CL. The
>> main change of the behaviour would be in the second CL.
>>
>> In *the second CL*, we will change the behaviour:
>>
>>1. The old behaviour: When the element(input/textarea) provides a
>>text selectionchange or its selection changes, we dispatch a
>>selectionchange event on the element. We don't care whether this event is
>>executed, and we just dipatch it.
>>2. The new behaviour: Now based on the new spec(
>>https://w3c.github.io/selection-api/#scheduling-selectionhange-event),
>>we dispatch this event only when there is no scheduled one in the queue. 
>> If
>>we have already scheduled one but not get callbacked, we would skip to
>>dispatch this event.
>>
>> To sum up, in this issue or mail thread, we only focus on what we did in
>> the first CL. So previouly we think this is low-risk because we don't
>> change anything at all. The real impact would happen in the second CL. So
>> for the compat risk or maybe the potential for site breakage, maybe we
>> could collect these data in the second CL.
>>
>> These are the main difference between the first CL and the second CL. If
>> you have any other concerns, feel free to ping me!
>>
>> Thanks!
>>
>> On Wednesday, May 29, 2024 at 11:52:57 PM UTC+8 sligh...@chromium.org
>> wrote:
>>
>>> hey folks,
>>>
>>> We spent a lot of time in API OWNERs today trying to understand this
>>> change, and we couldn't crisply describe:
>>>
>>>
>>>- What the old behaviour was
>>>- What the new behaviour is going to be
>>>- If we've analysed the potential for site breakage, and if not, if
>>>we should be adding usecounters ahead of the change
>>>
>>> Most of this is stuff we'd expect to see in an Explainer. Is it possible
>>> to produce one? Seeing example code for whatw this improves would be
>>> helpful.
>>>
>>> Best,
>>>
>>> Alex
>>>
>>> On Wednesday, May 29, 2024 at 1:43:00 AM UTC-7 Yoav Weiss wrote:
>>>
 I'm sorry, but re-reading this, I realized that I don't fully
 understand this change and the plan here.
 Can you elaborate on:
 * What is the behavior change that we want to drive here?
 * Which part of that would be covered by the first CL? which by the
 second?
 * Where do we predict compat risk here? How can we estimate it?

 Thanks! :)


 On Tue, May 28, 2024 at 1:54 AM Shuangshuang Zhou <
 shuangsh...@intel.com> wrote:

> Hi Yoav, thanks for the question! From chromium's side, currently I
> don't have any usecounters to trace how many sites would be impacted. I
> checked WebKit' status, seems they don't have any data. Maybe Olli could
> comment this from Gecko's side.
>
> Since the first CL doesn't change the original logic, we might collect
> some data in the second CL(avoid to dispatch events that are already
> scheduled but not executed).
>
> Thanks!
>
> On Monday, May 27, 2024 at 3:08:29 PM UTC+8 yoav...@chromium.org
> wrote:
>
>> Given Olli's comments on this change being backwards-incompatible, do
>> we have any 

Re: [blink-dev] Intent to Extend Experiment: Compression Dictionary Transport

['Jason Robbins' via blink-dev]

Tsuyoshi,

Previously your third OT stage on ChromeStatus got associated with your 
second trial on OT Console.  That is probably due to a bug in ChromeStatus. 
We'll look into that.

To let you continue with requesting this new trial, I have cleared out the 
trial ID for that third OT stage on ChromeStatus.  Now you should see a 
"Request Trial Creation" button on that stage that looks like:
https://screenshot.googleplex.com/4RZcpmCHJgxSnaT

You will need to change some fields in the form to indicate that this is 
for your "V3" trial.
Please note that each distinct trial requires a distinct trial name with an 
entry in 
https://chromium.googlesource.com/chromium/src/+/main/third_party/blink/renderer/platform/runtime_enabled_features.json5
The "Request Trial Creation" form handler now checks that file when you 
submit, so you may need to land a change to that file before you can 
successfully submit the form.

Thanks,
jason!




On Friday, May 31, 2024 at 6:24:37 AM UTC-7 mike...@chromium.org wrote:

> Thanks Domenic - I agree.
> On 5/30/24 9:31 PM, Domenic Denicola wrote:
>
> LGTM for a new OT from 127 to 129. 
>
> (Speaking generally, I think starting new OTs is better than extending 
> existing ones, so I am glad the team has taken this route. From an 
> ecosystem perspective, new OTs make it easier for the team to make breaking 
> changes, and encourages OT participants to continually re-engage with the 
> process.)
>
> On Friday, May 31, 2024 at 10:07:00 AM UTC+9 jrob...@google.com wrote:
>
>> Mike or other API Owners, still approved given that this is actually 
>> requesting a new OT? 
>>
>> Thanks,
>> jason!
>>
>> On Wednesday, May 29, 2024 at 5:10:54 PM UTC-7 Tsuyoshi Horo wrote:
>>
>>> Ah, sorry for the confusion. 
>>>
>>> This request is for the V3 Origin Trial.
>>>
>>> V1 OT was from 117 to 122.
>>> V2 OT was from 122 to 125.
>>> And this V3 OT is from 127 to 129.
>>>
>>>
>>> On Thu, May 30, 2024 at 8:32 AM Patrick Meenan  
>>> wrote:
>>>
>> Sorry, probably some confusion with the process. 

 This is for the 3rd round of OT on the platform status entry 
 (CompressionDictionaryTransportV3) so "extend" may not be the right 
 terminology.  V1 really ended at 122 and we had the same confusion the 
 last 
 time around and the V2 trial was created that went from 123-125 (and is 
 the 
 current active trial).

 I'll leave it to Tsuyoshi so I don't accidentally break anything, but I 
 assume we need to mark the v3 trial as the active stage.

 On Wed, May 29, 2024 at 7:16 PM Panos Astithas  
 wrote:

>>> Hi Tsuyoshi,
>
> Is this a request to extend the V1 OT as it appears in Chromestatus 
> and in the title of this thread or are you trying to create a new V3 
> trial 
> as it seems to be the intent based on the content of your intent? Note 
> that 
> V1 ended at M125, so teh extension would be for 4 milestones.
>
> On Wed, May 29, 2024 at 10:22 AM Mike Taylor  
> wrote:
>
 Thanks all. LGTM to extend from 127 to 129 inclusive.
>> On 5/29/24 10:51 AM, Patrick Meenan wrote:
>>
> On the spec side of things, there is one more issue outstanding in the 
>> IETF discussion but it's not API-impacting and we expect that this 
>> latest 
>> draft 
>> ,
>>  
>> which this OT implements, has the final API shape. There will be some 
>> tweaks around the edges as we go through the final steps of the RFC 
>> process 
>> but the V3 OT will give sites something to test against that matches 
>> what 
>> we expect to ship. 
>>
>> There are some fairly substantial changes from the previous OT 
>> that it would be useful to get feedback on. In particular, the change to 
>> the file format that embeds the dictionary hash into the file itself 
>> instead of being a separate response header.
>>
>> On Wed, May 29, 2024 at 10:37 AM Yoav Weiss (@Shopify) <
>> yoav...@chromium.org> wrote:
>>
>>>
>>>
>>> On Wed, May 29, 2024 at 4:31 PM Mike Taylor  
>>> wrote:
>>>
 Hi there,

 Would you mind commenting on progress for the following items, per 
 OT renewal guidelines:

>>>  
>>>
 Draft spec (early draft is ok, but must be spec-like and associated 
 with the appropriate standardization venue, or WICG)

>>> Recently published 
>>> 
>>>  with 
>>> above-mentioned changes. 
>>> +Patrick Meenan can probably add precision there, but it's making 
>>> good progress in the HTTPWG.  
>>>
>>> TAG review (see exceptions)

>>> https://github.com/w3ctag/design-reviews/issues/877 
>>>
 bit.ly/blink-signals requests

>>> Both Mozilla 
>>> 

Re: [blink-dev] Intent-to-Ship: MediaRecorder keyframe configurability

[Peter Kasting]

0 is actually the one unambiguous case -- it clearly means you want a key
frame every frame.

Seems strange that someone whose steam has a key frame every 30 frames
should specify a count of 29. I dunno though, if that's also what other
vendors do then changing is far more trouble than benefit. Do we know what
other vendors do? Is there any kind of wpt test for this, or similar?

PK


On Fri, May 31, 2024, 7:37 AM Markus Handell  wrote:

> It was a while, but the discussions we had were not revolving around this
> corner case.
> I think it makes sense for the implementation to keep adhering to the
> "exclusive of" to get rid of the ambiguity of what 0 means in Interval. I
> also don't see another way to interpret the spec text.
> For the duration I don't think it practically matters whether >= or > is
> used as we're talking microseconds. If you think this is important, please
> file a MediaRecorder bug.
>
> Thanks!
> Markus
>
> On Fri, May 31, 2024 at 3:28 PM Peter Kasting 
> wrote:
>
>>
>>
>> On Fri, May 31, 2024, 5:43 AM Markus Handell  wrote:
>>
>>> Hi Peter, from the spec text:
>>>
>>> "If videoKeyFrameIntervalCount is not null ... the video encoder
>>> produces a keyframe on the *first* frame arriving *after* 
>>> *videoKeyFrameIntervalCount
>>> frames passed* *since* the last key frame"
>>>
>>> It sounds to me like the blink impl is correctly implementing the spec
>>> meaning. If videoKeyFrameIntervalCount is 0, the spec text implies every
>>> frame should be a key frame. If your alternative interpretation were true,
>>> what would a value of 0 mean?
>>>
>>
>> A value of 0 would in practice have the same effect as a value of 1, both
>> meaning, "key frame every frame". Though also in practice I don't think
>> either actually works, given that the blink impl API only requests key
>> frames in response to receiving delta frames.
>>
>> If "first frame after" is intended to imply "exclusive of", then the
>> count part is correct but the time part is wrong (it would need to switch
>> to > from >=). I think the intent of the wording was to imply "inclusive
>> of", though. But I wasn't in the meetings, so I'm not sure.
>>
>> PK
>>
>>
>>> On Thu, May 30, 2024 at 7:50 PM Peter Kasting 
>>> wrote:
>>>
 On Thursday, May 30, 2024 at 9:32:50 AM UTC-7 Peter Kasting wrote:

 The spec says that both the duration and frame count refer to the
 interval "between key frames".


 More spec text: "If videoKeyFrameIntervalCount is not null and
 videoKeyFrameIntervalDuration is null, the video encoder produces a
 keyframe on the first frame arriving after videoKeyFrameIntervalCount
 frames passed since the last key frame." I think that means Blink's current
 impl is indeed off-by-one.

 PK

>>>

-- 
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/CAAHOzFD82DaDcGgrGARc9JhNNL4cT%2Bck3ec7a1RxQ-Yqe6RHdA%40mail.gmail.com.

[blink-dev] Intent to Ship: Protected Audience: Allow trusted bidding signals to trigger interest group updates

[Paul Jensen]

Contact emails

pauljen...@chromium.org


Explainer

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


Specification

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


Summary

The Protected Audience API allows bidders to store information, called an
interest group, from a single site in the browser that can only be read
later in the context of an auction.  Today, interest groups can be updated
by fetching new values from a server.  For all interest groups, the
frequency of these updates is rate limited to at most once a day to
conserve network traffic and avoid overwhelming servers.  However, we've
heard from developers that certain ad campaigns need much more timely
updates.  During Protected Audience auctions, the browser fetches real-time
signals from bidders' key-value servers.  This proposal allows the response
to these fetches to indicate a subset of interest groups they’d like
updated more frequently than once a day.


Blink component

Blink>InterestGroups



TAG review

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


TAG review status

Completed for Protected Audience, resolved unsatisfied.


RisksInteroperability and Compatibility

Feature represents optional new behavior that shouldn’t break existing
usage.


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


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


Web developers:

Feature requested by Microsoft in GitHub issue
.


Debuggability

Protected Audience trusted bidding signals show up in the DevTools Network
pane. Updates show up in the Application -> Storage -> Interest Groups
DevTools pane.


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

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


Is this feature fully tested by web-platform-tests

?

Yes

.


Flag name on chrome://flags

None


Finch feature name

InterestGroupUpdateIfOlderThan


Requires code in //chrome?

False


Estimated milestones

Shipping on desktop and Android in M125.


Anticipated spec changes

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5162656775536640


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/CABQTWr%3DWxOenJmSZ5oW%3DVDdJ9q1nwovSJdgPw_91Fp3fkV01ew%40mail.gmail.com.

Re: [blink-dev] Intent-to-Ship: MediaRecorder keyframe configurability

['Markus Handell' via blink-dev]

It was a while, but the discussions we had were not revolving around this
corner case.
I think it makes sense for the implementation to keep adhering to the
"exclusive of" to get rid of the ambiguity of what 0 means in Interval. I
also don't see another way to interpret the spec text.
For the duration I don't think it practically matters whether >= or > is
used as we're talking microseconds. If you think this is important, please
file a MediaRecorder bug.

Thanks!
Markus

On Fri, May 31, 2024 at 3:28 PM Peter Kasting  wrote:

>
>
> On Fri, May 31, 2024, 5:43 AM Markus Handell  wrote:
>
>> Hi Peter, from the spec text:
>>
>> "If videoKeyFrameIntervalCount is not null ... the video encoder produces
>> a keyframe on the *first* frame arriving *after* *videoKeyFrameIntervalCount
>> frames passed* *since* the last key frame"
>>
>> It sounds to me like the blink impl is correctly implementing the spec
>> meaning. If videoKeyFrameIntervalCount is 0, the spec text implies every
>> frame should be a key frame. If your alternative interpretation were true,
>> what would a value of 0 mean?
>>
>
> A value of 0 would in practice have the same effect as a value of 1, both
> meaning, "key frame every frame". Though also in practice I don't think
> either actually works, given that the blink impl API only requests key
> frames in response to receiving delta frames.
>
> If "first frame after" is intended to imply "exclusive of", then the count
> part is correct but the time part is wrong (it would need to switch to >
> from >=). I think the intent of the wording was to imply "inclusive of",
> though. But I wasn't in the meetings, so I'm not sure.
>
> PK
>
>
>> On Thu, May 30, 2024 at 7:50 PM Peter Kasting 
>> wrote:
>>
>>> On Thursday, May 30, 2024 at 9:32:50 AM UTC-7 Peter Kasting wrote:
>>>
>>> The spec says that both the duration and frame count refer to the
>>> interval "between key frames".
>>>
>>>
>>> More spec text: "If videoKeyFrameIntervalCount is not null and
>>> videoKeyFrameIntervalDuration is null, the video encoder produces a
>>> keyframe on the first frame arriving after videoKeyFrameIntervalCount
>>> frames passed since the last key frame." I think that means Blink's current
>>> impl is indeed off-by-one.
>>>
>>> PK
>>>
>>

-- 
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/CAJjiFfG_9%3DObuYGAsf24B4hWcSrjxzwrDdtPiPK_zHdtNkH%3DmQ%40mail.gmail.com.

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

[Mike Taylor]

LGTM3

On 5/31/24 4:08 AM, Yoav Weiss (@Shopify) wrote:

LGTM2

On Fri, May 31, 2024 at 5:52 AM 'Jiaming Cheng' via blink-dev 
 wrote:


Thanks Domenic :]

On Thu, May 30, 2024 at 6:28 PM Domenic Denicola
 wrote:

LGTM1.

This feature and its spec fits well with the existing
MediaMetadata. It has received a positive position from
Mozilla. The TAG review solicited a good discussion of
considered alternatives.

I agree with Alex that this would have gone better with a
proper explainer, including considered alternatives and
example code. But the feature is simple enough, and thankfully
we got a chance to spell out the reasoning about alternatives
in the TAG review, so I think we can proceed.

On Saturday, May 18, 2024 at 1:53:09 AM UTC+9 Alex Russell wrote:

Sorry for the slow reply here.

Glad to see this works for Audio too. This might have been
a bit more obvious of there were an explainer in the usual
format. I expect the TAG will ask for one of those too.
Please pay particular attention to considered alternatives
and example code, both for the proposed design and for
discarded alternatives.

https://w3ctag.org/explainers/

Best,

Alex

On Wednesday, May 15, 2024 at 12:14:18 PM UTC-7 Jiaming
Cheng wrote:

Thanks Domenic and Mike for the reply!

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

Best,
Jiaming

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

Hi Jiaming,

Per our process

,
we give the TAG and other vendors at least one
month to comment on changes. (This is why it is
recommended to start these reviewers earlier,
before sending the Intent to Ship.) So it might be
a bit more time before we can consider this
feature for shipping. Of course, if you get
responses and engagement before that point, we can
proceed earlier.

-Domenic

On Tuesday, May 14, 2024 at 11:06:55 AM UTC+9
Jiaming Cheng wrote:

Hi team,

Those reviews have been posted for 10 days,
there's no opposing comments on any of them so
far. Could you please take another look at
this intent?

Let me know if you have any further questions
or concerns.

Thanks,
Jiaming

On Fri, May 3, 2024 at 6:25 PM Jiaming Cheng
 wrote:

Hi Alex, Chris and Daniel,

Thank you for your valuable feedback!

I've addressed your comments and taken the
following updates:

Hey Alex, the ChapterInformation *does*
apply to audio as well as video, since
MediaSession is for both audio and video.
I've updated the Chrome status to reflect
this.

Additionally, I've taken the following
actions:

  * Added WPT test:

https://chromium-review.googlesource.com/c/chromium/src/+/5516503

  * Filed TAG review:

https://github.com/w3ctag/design-reviews/issues/952
  * Filed WebKit review:

https://github.com/WebKit/standards-positions/issues/344
  * Filed Gecko review:

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



I will keep you updated on the progress of
these reviews and notify you once they are
approved. Let me know if you have any
questions :]

Best,
Jiaming

On Wed, May 1, 2024 at 8:57 AM Alex
  

Re: [blink-dev] Intent-to-Ship: MediaRecorder keyframe configurability

[Peter Kasting]

On Fri, May 31, 2024, 5:43 AM Markus Handell  wrote:

> Hi Peter, from the spec text:
>
> "If videoKeyFrameIntervalCount is not null ... the video encoder produces
> a keyframe on the *first* frame arriving *after* *videoKeyFrameIntervalCount
> frames passed* *since* the last key frame"
>
> It sounds to me like the blink impl is correctly implementing the spec
> meaning. If videoKeyFrameIntervalCount is 0, the spec text implies every
> frame should be a key frame. If your alternative interpretation were true,
> what would a value of 0 mean?
>

A value of 0 would in practice have the same effect as a value of 1, both
meaning, "key frame every frame". Though also in practice I don't think
either actually works, given that the blink impl API only requests key
frames in response to receiving delta frames.

If "first frame after" is intended to imply "exclusive of", then the count
part is correct but the time part is wrong (it would need to switch to >
from >=). I think the intent of the wording was to imply "inclusive of",
though. But I wasn't in the meetings, so I'm not sure.

PK


> On Thu, May 30, 2024 at 7:50 PM Peter Kasting 
> wrote:
>
>> On Thursday, May 30, 2024 at 9:32:50 AM UTC-7 Peter Kasting wrote:
>>
>> The spec says that both the duration and frame count refer to the
>> interval "between key frames".
>>
>>
>> More spec text: "If videoKeyFrameIntervalCount is not null and
>> videoKeyFrameIntervalDuration is null, the video encoder produces a
>> keyframe on the first frame arriving after videoKeyFrameIntervalCount
>> frames passed since the last key frame." I think that means Blink's current
>> impl is indeed off-by-one.
>>
>> PK
>>
>

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

Re: [blink-dev] Re: Intent to Ship: WebGPU: GPUAdapter info attribute

[Mike Taylor]

LGTM3

On 5/31/24 4:07 AM, Yoav Weiss (@Shopify) wrote:

LGTM2

On Fri, May 31, 2024 at 7:35 AM Domenic Denicola 
 wrote:


In that case, LGTM1.

On Fri, May 31, 2024 at 2:31 PM François Beaufort
 wrote:



On Fri, May 31, 2024 at 3:16 AM Domenic Denicola
 wrote:



On Thursday, May 30, 2024 at 1:34:03 PM UTC+9
fbea...@google.com wrote:

Contact emailsfbeauf...@google.com

ExplainerNone


Specificationhttps://gpuweb.github.io/gpuweb/#dom-gpuadapter-info


Summary

Functionality added to the WebGPU spec after its first
shipment in a browser. Adds a synchronous GPUAdapter
info attribute to retrieve the same information about
the physical adapter as with the asynchronous
GPUAdapter requestAdapterInfo() method. A separate
Intent will be sent to deprecate and remove the
asynchronous GPUAdapter requestAdapterInfo() method.



Blink componentBlink>WebGPU



TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

The GPUAdapter info attribute has not yet been
implemented in any browser. It has been approved by
the GPU for the Web Community Group, with
representatives from Chrome, Firefox, and Safari. See
minutes at

https://github.com/gpuweb/gpuweb/wiki/GPU-Web-2024-05-22#add-synchronous-gpuadapterinfo-4550






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


/WebKit/: Closed Without a Position

(https://github.com/WebKit/standards-positions/issues/294#issuecomment-1877411933

)

/Web developers/: Positive
(https://github.com/gpuweb/gpuweb/issues/4536
)

/Other signals/:

WebView application risks

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

None



Debuggability

None



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

All platforms will eventually have support. Will
immediately be available on Android, Android WebView,
ChromeOS, Mac, and Windows, since those platforms
already support WebGPU. Linux is planned to have
WebGPU support in the future, so this feature will
become available when WebGPU does.



Is this feature fully tested by web-platform-tests

?Yes


See https://github.com/gpuweb/cts/pull/3679
 WebGPU/WGSL
have a conformance test suite
(https://github.com/gpuweb/cts) that is regularly
pulled into Chromium and part of the testing of
Dawn/Tint in Chromium.



Flag name on chrome://flagsNone

Finch feature nameNone


Per

https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md#when-is-a-flag-required
, a feature flag is required for any web platform addition.


We'll have a blink runtime feature flag named
"WebGPUAdapterInfoAttribute" for this.
Thanks for catching Domenic!



Non-finch justificationNone

Requires code in //chrome?False

Tracking
bughttps://issues.chromium.org/issues/335383516


Estimated milestonesShipping on desktop127Shipping on
Android127Shipping on WebView127

Anticipated spec changes

Open questions about a feature may be a source of
future web compat or interop issues. Please list open

Re: [blink-dev] Intent to Extend Experiment: Compression Dictionary Transport

[Mike Taylor]

Thanks Domenic - I agree.

On 5/30/24 9:31 PM, Domenic Denicola wrote:

LGTM for a new OT from 127 to 129.

(Speaking generally, I think starting new OTs is better than extending 
existing ones, so I am glad the team has taken this route. From an 
ecosystem perspective, new OTs make it easier for the team to make 
breaking changes, and encourages OT participants to continually 
re-engage with the process.)


On Friday, May 31, 2024 at 10:07:00 AM UTC+9 jrob...@google.com wrote:

Mike or other API Owners, still approved given that this is
actually requesting a new OT?

Thanks,
jason!

On Wednesday, May 29, 2024 at 5:10:54 PM UTC-7 Tsuyoshi Horo wrote:

Ah, sorry for the confusion.

This request is for the V3 Origin Trial.

V1 OT was from 117 to 122.
V2 OT was from 122 to 125.
And this V3 OT is from 127 to 129.


On Thu, May 30, 2024 at 8:32 AM Patrick Meenan
 wrote:

Sorry, probably some confusion with the process.

This is for the 3rd round of OT on the platform status
entry (CompressionDictionaryTransportV3) so "extend" may
not be the right terminology.  V1 really ended at 122 and
we had the same confusion the last time around and the V2
trial was created that went from 123-125 (and is the
current active trial).

I'll leave it to Tsuyoshi so I don't accidentally break
anything, but I assume we need to mark the v3 trial as the
active stage.

On Wed, May 29, 2024 at 7:16 PM Panos Astithas
 wrote:

Hi Tsuyoshi,

Is this a request to extend the V1 OT as it appears in
Chromestatus and in the title of this thread or are
you trying to create a new V3 trial as it seems to be
the intent based on the content of your intent? Note
that V1 ended at M125, so teh extension would be for 4
milestones.

On Wed, May 29, 2024 at 10:22 AM Mike Taylor
 wrote:

Thanks all. LGTM to extend from 127 to 129 inclusive.

On 5/29/24 10:51 AM, Patrick Meenan wrote:


On the spec side of things, there is one more
issue outstanding in the IETF discussion but it's
not API-impacting and we expect that this latest
draft

,
which this OT implements, has the final API
shape. There will be some tweaks around the edges
as we go through the final steps of the RFC
process but the V3 OT will give sites something
to test against that matches what we expect to ship.

There are some fairly substantial changes from
the previous OT that it would be useful to get
feedback on. In particular, the change to the
file format that embeds the dictionary hash into
the file itself instead of being a separate
response header.

On Wed, May 29, 2024 at 10:37 AM Yoav Weiss
(@Shopify)  wrote:



On Wed, May 29, 2024 at 4:31 PM Mike Taylor
 wrote:

Hi there,

Would you mind commenting on progress for
the following items, per OT renewal
guidelines:



Draft spec (early draft is ok, but must
be spec-like and associated with the
appropriate standardization venue, or WICG)

Recently published

 
with
above-mentioned changes.
+Patrick Meenan can probably add precision
there, but it's making good progress in the
HTTPWG.

TAG review (see exceptions)

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



bit.ly/blink-signals
 requests

Both Mozilla


and WebKit


are positive (with ongoing discussion about
  

Re: [blink-dev] Intent-to-Ship: MediaRecorder keyframe configurability

['Markus Handell' via blink-dev]

Hi Peter, from the spec text:

"If videoKeyFrameIntervalCount is not null ... the video encoder produces a
keyframe on the *first* frame arriving *after* *videoKeyFrameIntervalCount
frames passed* *since* the last key frame"

It sounds to me like the blink impl is correctly implementing the spec
meaning. If videoKeyFrameIntervalCount is 0, the spec text implies every
frame should be a key frame. If your alternative interpretation were true,
what would a value of 0 mean?

On Thu, May 30, 2024 at 7:50 PM Peter Kasting  wrote:

> On Thursday, May 30, 2024 at 9:32:50 AM UTC-7 Peter Kasting wrote:
>
> The spec says that both the duration and frame count refer to the interval
> "between key frames".
>
>
> More spec text: "If videoKeyFrameIntervalCount is not null and
> videoKeyFrameIntervalDuration is null, the video encoder produces a
> keyframe on the first frame arriving after videoKeyFrameIntervalCount
> frames passed since the last key frame." I think that means Blink's current
> impl is indeed off-by-one.
>
> PK
>

-- 
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/CAJjiFfGoyJGGzRdbFZ3b7TyyWBYzc593%3DL%2BHQH3wp71LUSCYmQ%40mail.gmail.com.

[blink-dev] Intent to Implement and Ship: Line-breakable ruby

[TAMURA, Kent]

Contact emailstk...@chromium.org

Explainer
https://docs.google.com/document/d/1hzvrwoE_0aw08X_CaU40zV5bXbMQjY2SHQHj3Np4sDo/edit?pli=1#heading=h.acpilydj9j1d

Specificationhttps://drafts.csswg.org/css-ruby/#break-within

Design docs
https://docs.google.com/document/d/1hzvrwoE_0aw08X_CaU40zV5bXbMQjY2SHQHj3Np4sDo/edit?usp=sharing

Summary

Line-breaks are possible within elements with `display: ruby`. A single
pair of a ruby-base and a ruby-text has never been line-breakable, and it
has been pushed to the next line if the current line had no enough space
for the entire pair. Now each of the ruby-base and the ruby-text can be
split into multiple lines.


Blink componentBlink>Layout>Ruby


Search tagsruby 

TAG reviewNone; This is a small behavior change, and there is no API to
cover this behavior.

TAG review statusNot applicable

Risks


Interoperability and Compatibility

Compatibility risk: * Web authors might expect rubies are not
line-breakable. They need to specify `text-wrap: nowrap` or something to
disable line-breaking if they don't want line-breaking. Interoperability
risk: * This would be the first implementation of the behavior.

 appears in about 0.14% of page views [1].  Rubies with long content
are very rare, and this change will affect much less than 0.14% page views.

[1] https://chromestatus.com/metrics/feature/timeline/popularity/576

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

*WebKit*: Support (https://github.com/WebKit/standards-positions/issues/232)
It seems the latest Safari has implemented line-breakable ruby partially.

*Web developers*: Positive (
https://docs.google.com/document/d/1hzvrwoE_0aw08X_CaU40zV5bXbMQjY2SHQHj3Np4sDo/edit?pli=1#heading=h.giqn8tqur4ig
)

*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

Existing DevTools functionalities are enough.


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

Is this feature fully tested by web-platform-tests

?Yes

https://wpt.fyi/results/css/css-ruby/break-within-bases


Flag name on chrome://flagsenable-experimental-web-platform-features

Finch feature nameRubyLineBreakable

Requires code in //chrome?False

Tracking bughttps://issues.chromium.org/issues/324111880

Estimated milestones
Shipping on desktop 128
DevTrial on desktop 127
Shipping on Android 128
DevTrial on Android 127
Shipping on WebView 128

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

This intent message was generated by Chrome Platform Status
.


-- 
TAMURA Kent
Software Engineer, Google

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

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

[Yoav Weiss (@Shopify)]

LGTM2

On Fri, May 31, 2024 at 5:52 AM 'Jiaming Cheng' via blink-dev <
blink-dev@chromium.org> wrote:

> Thanks Domenic :]
>
> On Thu, May 30, 2024 at 6:28 PM Domenic Denicola 
> wrote:
>
>> LGTM1.
>>
>> This feature and its spec fits well with the existing MediaMetadata. It
>> has received a positive position from Mozilla. The TAG review solicited a
>> good discussion of considered alternatives.
>>
>> I agree with Alex that this would have gone better with a proper
>> explainer, including considered alternatives and example code. But the
>> feature is simple enough, and thankfully we got a chance to spell out the
>> reasoning about alternatives in the TAG review, so I think we can proceed.
>>
>> On Saturday, May 18, 2024 at 1:53:09 AM UTC+9 Alex Russell wrote:
>>
>>> Sorry for the slow reply here.
>>>
>>> Glad to see this works for Audio too. This might have been a bit more
>>> obvious of there were an explainer in the usual format. I expect the TAG
>>> will ask for one of those too. Please pay particular attention to
>>> considered alternatives and example code, both for the proposed design and
>>> for discarded alternatives.
>>>
>>> https://w3ctag.org/explainers/
>>>
>>> Best,
>>>
>>> Alex
>>>
>>> On Wednesday, May 15, 2024 at 12:14:18 PM UTC-7 Jiaming Cheng wrote:
>>>
 Thanks Domenic and Mike for the reply!

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

 Best,
 Jiaming

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

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

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

 Best,

 Alex

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

> I was curious about WPT coverage for this and found
> https://wpt.fyi/results/mediasession/mediametadata.html
>
>
>
> Maybe that could be updated to check for the basics of the new
> attribute?
>
>
>
> -- Dan
>
>
>
> *From:* 'Jiaming Cheng' via blink-dev 
> *Sent:* Tuesday, April 30, 2024 1:50 PM
> *To:* blink-dev@chromium.org
> *Cc:* Alex Newcomer ; Megan Fu <
> megan...@google.com>; Tommy Steimel ; Andrew
> Xu 
> *Subject:* [blink-dev] Intent to Ship: Support 

Re: [blink-dev] Re: Intent to Ship: WebGPU: GPUAdapter info attribute

[Yoav Weiss (@Shopify)]

LGTM2

On Fri, May 31, 2024 at 7:35 AM Domenic Denicola 
wrote:

> In that case, LGTM1.
>
> On Fri, May 31, 2024 at 2:31 PM François Beaufort 
> wrote:
>
>>
>>
>> On Fri, May 31, 2024 at 3:16 AM Domenic Denicola 
>> wrote:
>>
>>>
>>>
>>> On Thursday, May 30, 2024 at 1:34:03 PM UTC+9 fbea...@google.com wrote:
>>>
>>> Contact emailsfbeauf...@google.com
>>>
>>> ExplainerNone
>>>
>>> Specificationhttps://gpuweb.github.io/gpuweb/#dom-gpuadapter-info
>>>
>>> Summary
>>>
>>> Functionality added to the WebGPU spec after its first shipment in a
>>> browser. Adds a synchronous GPUAdapter info attribute to retrieve the same
>>> information about the physical adapter as with the asynchronous GPUAdapter
>>> requestAdapterInfo() method. A separate Intent will be sent to deprecate
>>> and remove the asynchronous GPUAdapter requestAdapterInfo() method.
>>>
>>>
>>> Blink componentBlink>WebGPU
>>> 
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> The GPUAdapter info attribute has not yet been implemented in any
>>> browser. It has been approved by the GPU for the Web Community Group, with
>>> representatives from Chrome, Firefox, and Safari. See minutes at
>>> https://github.com/gpuweb/gpuweb/wiki/GPU-Web-2024-05-
>>> 22#add-synchronous-gpuadapterinfo-4550
>>>
>>>
>>> *Gecko*: No signal (https://github.com/mozilla/
>>> standards-positions/issues/1033)
>>>
>>>
>>> *WebKit*: Closed Without a Position (https://github.com/WebKit/
>>> standards-positions/issues/294#issuecomment-1877411933)
>>>
>>> *Web developers*: Positive (https://github.com/gpuweb/gpuweb/issues/4536
>>> )
>>>
>>> *Other signals*:
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> None
>>>
>>>
>>> Debuggability
>>>
>>> None
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, ChromeOS, Android, and Android WebView)?No
>>>
>>> All platforms will eventually have support. Will immediately be
>>> available on Android, Android WebView, ChromeOS, Mac, and Windows, since
>>> those platforms already support WebGPU. Linux is planned to have WebGPU
>>> support in the future, so this feature will become available when WebGPU
>>> does.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?Yes
>>>
>>> See https://github.com/gpuweb/cts/pull/3679 WebGPU/WGSL have a
>>> conformance test suite (https://github.com/gpuweb/cts) that is
>>> regularly pulled into Chromium and part of the testing of Dawn/Tint in
>>> Chromium.
>>>
>>>
>>> Flag name on chrome://flagsNone
>>>
>>> Finch feature nameNone
>>>
>>>
>>> Per
>>> https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md#when-is-a-flag-required
>>> , a feature flag is required for any web platform addition.
>>>
>>
>> We'll have a blink runtime feature flag named
>> "WebGPUAdapterInfoAttribute" for this.
>> Thanks for catching Domenic!
>>
>>>
>>>
>>>
>>>
>>> Non-finch justificationNone
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://issues.chromium.org/issues/335383516
>>>
>>> Estimated milestonesShipping on desktop127Shipping on Android127Shipping
>>> on WebView127
>>>
>>> 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 Statushttps://chromestatus.com/
>>> feature/5087914701881344?gate=5141800569536512
>>>
>>> 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/CAM0wra8zntEfiC5SBHcPeOAKV2SOfUM%3DTn9P8Wrq4L3d%3D_pXyQ%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