Re: [blink-dev] New API owner: Domenic Denicola

[Johnny Stenback]

It makes me very happy to see Domenic added to API owners. Congratulations
Domenic!

Cheers,
Johnny

On Mon, Jan 22, 2024 at 7:29 AM Christian Biesinger 
wrote:

> Congratulations!
>
> Christian
>
> On Mon, Jan 22, 2024 at 3:34 AM 'Thomas Steiner' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Congratulations, Dominic, and thanks for your time!
>>
>> On Fri, Jan 19, 2024 at 9:59 PM Rick Byers  wrote:
>>
>>> Hi blink-dev,
>>> +Domenic Denicola  has volunteered to donate his
>>> time and considerable web platform expertise to reviewing intent threads as
>>> an API owner. Domenic is very active in the web standards community
>>> including as an HTML editor, runs our spec mentors
>>>  program and has
>>> contributed helpfully to a wide variety of intent discussions over the past
>>> year. His nomination
>>> 
>>> was reviewed and approved 
>>> by the existing API owners today.
>>>
>>> Thank you Domenic!
>>>Rick
>>>
>>> --
>>> 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/CAFUtAY-Zq2WDWz0_UhfweWd4e4c1dr8OTaCaLXiW289pNKfDDg%40mail.gmail.com
>>> 
>>> .
>>>
>>
>>
>> --
>> Thomas Steiner, PhD—Developer Relations Engineer (blog.tomayac.com,
>> toot.cafe/@tomayac)
>>
>> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
>> Geschäftsführer: Paul Manicle, Liana Sebastian
>> Registergericht und -nummer: Hamburg, HRB 86891
>>
>> - BEGIN PGP SIGNATURE -
>> Version: GnuPG v2.4.3 (GNU/Linux)
>>
>> iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck
>> 0fjumBl3DCharaCTersAttH3b0ttom.xKcd.cOm/1181.
>> - END PGP SIGNATURE -
>>
>> --
>> 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/CALgRrLkyJ10QJrWZmfWkxj2YQ25FtsjizdwmqBwhAA93u2%3DqeQ%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/CAPTJ0XFV0LYjaX6AgdYGz3O%3DcTG2b-30uvn1DYZjnsfpFVje7w%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/CACZRgz4CBN9SOoSiwVmCcMEp%2BadbqRzsrGO-C9fRRrekaFs%2B6Q%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Array.fromAsync

[Johnny Stenback]

+1 to what Chris said. And if you feel a gate doesn't apply, you can state
in a comment that you believe the result of the review should be n/a. And
we're in fact in the midst of landing a short-hand button that does that
for all approval gate chips.

Cheers,
Johnny

On Thu, Oct 26, 2023 at 8:21 AM Chris Harrelson 
wrote:

>
>
> On Wed, Oct 25, 2023 at 5:05 PM Shu-yu Guo  wrote:
>
>> Those gates are not applicable for most TC39 stage 3 features, including
>> this one. Are you asking them to be marked as such or that we requested
>> reviews for it?
>>
>
> I think they are. TC39 stage 3 features can skip a TAG review and signals,
> but the other fields are still required.
>
>
>>
>> On Wed, Oct 25, 2023 at 4:00 PM Mike Taylor 
>> wrote:
>>
>>> Oops... sent too early. Can you also please request reviews for the rest
>>> of the review gates
>>> 
>>> in the chromestatus entry?
>>> On 10/25/23 6:57 PM, Mike Taylor wrote:
>>>
>>> LGTM1. It's encouraging that Firefox Nightly shipped this a few months
>>> back  with no
>>> reported regressions thus far.
>>> On 10/25/23 6:39 PM, Rezvan Mahdavi Hezaveh wrote:
>>>
>>> Contact emails s...@chromium.org, rez...@chromium.org
>>>
>>> Explainer https://github.com/tc39/proposal-array-from-async
>>>
>>> Specification https://tc39.es/proposal-array-from-async
>>>
>>> Summary
>>>
>>> Array.fromAsync is the async version of Array.from. It takes async
>>> iterables, iterates them, and collects the results into an array.
>>>
>>>
>>> Blink component Blink>JavaScript>Language
>>> 
>>>
>>> TAG review None
>>>
>>> TAG review status Not applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> No known interop or web compat risk.
>>>
>>>
>>> *Gecko*: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1746209)
>>> This is a TC39 Stage 3 proposal.
>>>
>>> *WebKit*: Positive This is a TC39 Stage 3 proposal.
>>>
>>> *Web developers*: Positive (
>>> https://twitter.com/erickwendel_/status/1555206623836127232) Seems
>>> positive, lots of likes on Twitter.
>>>
>>> *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
>>>
>>> It is debugged as any other static method in JavaScript.
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)? Yes
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ? Yes
>>>
>>> https://github.com/tc39/test262/issues/3725
>>>
>>>
>>> Flag name on chrome://flags --harmony_array_from_async
>>>
>>> Finch feature name None
>>>
>>> Non-finch justification None
>>>
>>> Requires code in //chrome? False
>>>
>>> Tracking bug https://bugs.chromium.org/p/v8/issues/detail?id=13321
>>>
>>> Estimated milestones
>>> DevTrial on desktop 120
>>> DevTrial on Android 120
>>>
>>> Anticipated spec changes
>>>
>>> Open questions about a feature may be a source of future web compat or
>>> interop issues. Please list open issues (e.g. links to known github issues
>>> in the project for the feature specification) whose resolution may
>>> introduce web compat/interop risk (e.g., changing to naming or structure of
>>> the API in a non-backward-compatible way).
>>> None
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5069575759069184
>>>
>>> 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/CACJ3t%2Bg4MwKGhiGJg%2B0WdgJXTD0rGJ22ZFGAF8bnOtGoLhszzA%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/591771b3-56e8-4f56-aba2-f66241221d29%40chromium.org
>>> 

[blink-dev] [ChromesStatus] Launching streamlined intent process

['Johnny Stenback' via blink-dev]

Hi all,

We are pleased to announce that a streamlined and more transparent intent
process has launched in the ChromeStatus tool!🎉

As some of you might have already seen, ChromeStatus now has the following
review/approval gates enabled. These gates will be applicable to features
that are targeting M118 and onwards.

   - Privacy
   - Security
   - Enterprise
   - Debuggability
   - Testing
   - API Owners

*Screenshot of Prepare to ship in the Chromestatus tool*

This change should drastically reduce the cases where features must go
through the Google internal launch processes before they can ship, and it
should also make it clear to Google internal and external contributors when
the Google internal launch process is necessary (rarely) and when it is not
(most of the time). Approvals should be requested as soon as there’s enough
information for the approvers to review (err on the side of early if
unsure), and as usual, start the Intent-to-* steps and email blink-dev as
soon as you’re ready and API Owners will help make sure the relevant
approvals are in place, as they’ve always done. This will help us all make
more informed decisions, improve transparency with all contributors and web
developers, and launch features more seamlessly.

The user guide 
will help you navigate through the ChromeStatus for the various intent
processes. And please note that this work is still very fresh and we’re
still ironing out some details as we learn more. If you bump into any rough
edges or have feature requests, please file a ticket here
.

Thank you to everyone who has worked on this project!

- jstenback (he/him)

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

Re: [blink-dev] Intent to Deprecate and Remove: WebRTC's RTCStats of type "track" and "stream".

[Johnny Stenback]

Deprecation trials require changes to servers which an enterprise may not
have access to or ability to affect changes to, whereas enterprise policies
are entirely within the enterprise's control. I'd recommend reaching out to
the enterprise team for their perspective on usage policies and perspective
on whether a policy should be included here or not (I'm still of the
opinion that it's in our interest to include one).

Thanks,
Johnny

On Tue, Feb 7, 2023 at 2:36 AM Henrik Boström  wrote:

> I have the same concern as Harald regarding corporate policies. Why not a
> Deprecation Origin Trial in that case for list of users and more concrete
> timeline?
>
> On Tuesday, February 7, 2023 at 9:10:40 AM UTC+1 Harald Alvestrand wrote:
>
>> Do we have trackable statistics on the usage of corporate policies?
>> ie if nobody uses the policy in 2 milestones, can we detect that and
>> decide that it is not needed and delete it, or will we be as unsure as we
>> are now?
>>
>>
>> On Mon, Feb 6, 2023 at 9:41 PM Mike Taylor 
>> wrote:
>>
>>> We don't know what we don't know, but it's not hard to imagine an
>>> in-house enterprise WebRTC application that is using "stats" or "track".
>>> Twilio is the breakage we know about (because a developer took the time to
>>> report a bug). Having a policy so an app continues to work while a fix is
>>> made is a good thing - and comes with the nice side effect of appearing on
>>> the Enterprise release notes, increasing awareness.
>>>
>>> On 2/4/23 3:28 AM, Harald Alvestrand wrote:
>>>
>>> What's the imagined scenario in which an enterprise policy would be
>>> useful?
>>>
>>> The only place I could imagine it being relevant is if there exists a
>>> WebRTC application that is only used within a single enterprise (neither
>>> hosting nor usage exists outside the enterprise), and that WebRTC
>>> application depends on non-upgraded Twilio libraries.
>>>
>>> I don't know that we have evidence that such applications exist.
>>>
>>>
>>>
>>> On Fri, Feb 3, 2023 at 6:14 PM Mike Taylor 
>>> wrote:
>>>
>>>> I agree with Johnny that an enterprise policy would be useful, at least
>>>> for a few milestones.
>>>>
>>>> On 1/30/23 5:16 AM, 'Harald Alvestrand' via blink-dev wrote:
>>>>
>>>> I'm not sure an enterprise policy is appropriate - I see the same
>>>> problem with sunsetting the policy as with sunsetting the stat in general,
>>>> and usage of enterprise policies is (as far as I know) far more opaque to
>>>> us than origin trials or Finch feature usage.
>>>>
>>>>
>>>> On Mon, Jan 30, 2023 at 11:13 AM Henrik Boström 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Friday, January 27, 2023 at 7:24:58 PM UTC+1 Johnny Stenback wrote:
>>>>> Is there an enterprise policy in place for this deprecation already?
>>>>> If not, adding one seems appropriate given the challenges of rolling out
>>>>> even simple fixes in some enterprise environments.
>>>>>
>>>>> One does not exist at the moment but I can add one
>>>>> <https://chromium.googlesource.com/chromium/src/+/HEAD/docs/enterprise/add_new_policy.md>
>>>>> .
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Johnny
>>>>>
>>>>> On Fri, Jan 27, 2023 at 5:16 AM Henrik Boström 
>>>>> wrote:
>>>>> Delaying the enabled-by-default to M112 is fine by me but I'll wait
>>>>> for a resolution here before taking action. Currently it is
>>>>> enabled-by-default in Canary.
>>>>>
>>>>> On Friday, January 27, 2023 at 12:41:23 PM UTC+1
>>>>> philipp...@googlemail.com wrote:
>>>>> Am Fr., 27. Jan. 2023 um 11:49 Uhr schrieb Henrik Boström <
>>>>> h...@chromium.org>:
>>>>> *Contact emails*
>>>>> h...@chromium.org, h...@chromium.org
>>>>>
>>>>> *Background*
>>>>> I attempted to remove this feature before but had forgotten to file an
>>>>> intent to deprecate, background here
>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/RsIktnGhHqw/>.
>>>>>
>>>>> *Specification*
>>>>> The getStats() API spec is here <https://w3c.github.io

Re: [blink-dev] Intent to Deprecate and Remove: WebRTC's RTCStats of type "track" and "stream".

[Johnny Stenback]

Is there an enterprise policy in place for this deprecation already? If
not, adding one seems appropriate given the challenges of rolling out even
simple fixes in some enterprise environments.

Thanks,
Johnny

On Fri, Jan 27, 2023 at 5:16 AM Henrik Boström  wrote:

> Delaying the enabled-by-default to M112 is fine by me but I'll wait for a
> resolution here before taking action. Currently it is enabled-by-default in
> Canary.
>
> On Friday, January 27, 2023 at 12:41:23 PM UTC+1 philipp...@googlemail.com
> wrote:
>
>> Am Fr., 27. Jan. 2023 um 11:49 Uhr schrieb Henrik Boström <
>> h...@chromium.org>:
>>
>>> *Contact emails*
>>> h...@chromium.org, h...@chromium.org
>>>
>>> *Background*
>>> I attempted to remove this feature before but had forgotten to file an
>>> intent to deprecate, background here
>>> .
>>>
>>> *Specification*
>>> The getStats() API spec is here  and
>>> it contains all the metrics. The deprecated metrics are also listed, but in
>>> the obsolete section
>>> .
>>> There's an open issue to remove obsolete metrics from the spec as soon as
>>> they are unshipped from modern browsers. This is considered a blocker for
>>> the document to reach Proposed Recommendation status.
>>>
>>> *Summary*
>>> WebRTC is a set of JavaScript APIs (spec
>>> ) that allow real-time communication
>>> between browsers. For the relevant metrics being removed, we're only
>>> talking about the WebRTC use case that is sending or receiving audio or
>>> video (typically Video Conferencing use cases), not the data channel use
>>> cases that is a popular WebRTC use case, since data channel only use cases
>>> would never have any tracks/streams.
>>>
>>> RTCPeerConnection.getStats() returns a map of string-to-objects, where
>>> each object is one of the dictionaries defined in the stats spec. The
>>> reason an app calls getStats() is mostly to report quality metrics (send
>>> and receive resolutions, bitrates, glitches, video QP, etc) which can be
>>> important for A/B experimentation. It can also be used in a way that
>>> impacts app logic or even UX inside the app. Most common use case I can
>>> think of: poll getStats() at 10 Hz and render volume bars for each
>>> participant based on volume levels from stats objects.
>>>
>>> The deprecation in question is to remove some stats objects that were
>>> made obsolete several years ago: all metrics on the "track" dictionary have
>>> been moved to non-obsolete objects ("inbound-rtp", "outbound-rtp",
>>> "media-source"). Reasons for wanting to deprecate include:
>>>
>>>- Spec-compliance: needed for browser implementations to align and
>>>for the spec to become Proposed Recommendation.
>>>- Web compat: Firefox never implement "track" or "steam"
>>>
>>> 
>>>  due
>>>to them being obsolete.
>>>- Performance: the duplicated metrics make up ~40% of the stats
>>>report size, which can be a significant number of bytes in larger 
>>> meetings
>>>and it is common for apps to poll getStats() 10 times per second.
>>>- Tech debt: unblock removal of 1400 LOC.
>>>
>>> In the meantime, the obsolete metrics is duplicated in several places of
>>> the stats report.
>>>
>>> *Risks*
>>> *- Impossible to properly measure usage*
>>> Because stats objects are exposed as JavaScript dictionaries, and
>>> because apps have to iterate all objects of the stats report in order to
>>> find the ones they are interested in or if they just dump all the data
>>> without filtering, there is no way to measure how big the dependency is on
>>> track in the real world.
>>>
>>> While we lack use counters, we have some positive signs:
>>>
>>>- Because Firefox does not have "track" or "stream" stats, any app
>>>that can run on Firefox already exercises the paths of these not 
>>> existing.
>>>
>>>
>>>- An experiment to "unship deprecated metrics" has been running at 50%
>>>Canary since October
>>>
>>> ,
>>>giving developers testing Canary a heads-up. Nobody complained until the
>>>experiment reached Stable.
>>>- We got to 50% Stable in M109 and while we're in the process of
>>>rolling it back now due to breaking twilio-video.js
>>>, it's
>>>interesting to note that this is the only breakage we are aware of (that
>>>does not mean there aren't more breakages, but I believe this at least 
>>> says
>>>something about the severity).
>>>
>>> *- Selenium et al typically starts browsers from fresh profiles and
>>> hence does not know the finch trial seed*
>>> The most likely explanation for 

Re: [blink-dev] Intent to extend experiment: Privacy Sandbox Ads APIs

[Johnny Stenback]

Sounds like API Owners are happy with the proposed approach of handling
these all through the single intent (thanks Yoav, I was unaware of your
earlier conversation). Given that and as long as all the relevant
chromestatus entries are kept up to date I'm fine with that approach.

Cheers,
Johnny

On Tue, Aug 2, 2022 at 5:34 AM Josh Karlin  wrote:

> I can do individual intents if that's necessary. Here are the affected
> status entries:
>
> Overall <https://chromestatus.com/feature/5100526168440832>
>
> Topics <https://chromestatus.com/feature/5680923054964736>
> Attribution Reporting <https://chromestatus.com/feature/6412002824028160>
> FLEDGE <https://chromestatus.com/feature/5733583115255808>
> Fenced Frames <https://chromestatus.com/feature/5699388062040064>
> Shared Storage <https://chromestatus.com/feature/6256348582903808>
>
>
> On Tue, Aug 2, 2022 at 2:29 AM Yoav Weiss  wrote:
>
>> Hey Johnny!
>>
>> Josh consulted with me whether he should send a single intent or several
>> ones, and I asked him to send a single consolidated one. Since the
>> different features are all bundled as a single OT, a single intent makes it
>> easier to make sure they are all in sync, and we're not
>> inadvertently approving an extension for all the features when approving an
>> extension for one of them.
>> Maybe it's possible to list all the different status entries in this
>> extension request, so that we'd make sure they're all up to date?
>>
>> Cheers :)
>> Yoav
>>
>> On Wed, Jul 27, 2022 at 8:33 PM Johnny Stenback 
>> wrote:
>>
>>> Hey Josh,
>>>
>>> As a general rule, please send one intent per feature as that'll help
>>> ensure all the intents get marked as approved in Chromestatus appropriately
>>> and we can help ensure that OT milestones etc are all up to date.
>>>
>>> Thanks,
>>> Johnny
>>>
>>> On Wed, Jul 27, 2022 at 9:48 AM Josh Karlin 
>>> wrote:
>>>
>>>> Greetings. The Privacy Sandbox Ads APIs experiment includes several
>>>> APIs and we'd like to extend all of them another three milestones to M107,
>>>> with the expectation that we will likely continue to ask for extensions to
>>>> support ecosystem testing.
>>>>
>>>> This OT covers several APIs (Attribution Reporting
>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/jEnNpideO1Y/m/UeR03hitAAAJ>,
>>>> FLEDGE
>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/0VmMSsDWsFg/m/6mN8yFl4AwAJ>,
>>>> Topics
>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/oTwd6VwCwqs/m/jPkW3T-mCgAJ>,
>>>> Fenced Frames
>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/y6G3cvKXjlg/m/DSNrBtxyAgAJ>,
>>>> and Shared Storage
>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/jDx8z5a6ovk/m/8CQXQL_LAwAJ>)
>>>> that are part of the Privacy Sandbox initiative. Based on feedback we
>>>> have already received
>>>> <https://developer.chrome.com/docs/privacy-sandbox/feedback/#reports>,
>>>> it will take more time before experimenters can provide the feedback that
>>>> we need to validate and improve them. We also expect to add several new
>>>> features for testing (including Shared Storage and support for FLEDGE on
>>>> mobile) in upcoming releases.
>>>>
>>>> I've bundled the requests for each API into a single intent to extend
>>>> since they are part of the same OT and all require the extension. If you'd
>>>> like, they can instead be requested individually.
>>>>
>>>> Thanks,
>>>>
>>>> Josh
>>>>
>>>> --
>>>> 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/CAANMuaO4BR3PMHJ8r-%2BzBpb2cDfbMKs%2Bg8syM-8ZUnSnrA5KTw%40mail.gmail.com
>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAANMuaO4BR3PMHJ8r-%2BzBpb2cDfbMKs%2Bg8syM-8ZUnSnrA5KTw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>> --
>>> You received this message because you ar

Re: [blink-dev] Intent to extend experiment: Privacy Sandbox Ads APIs

[Johnny Stenback]

Hey Josh,

As a general rule, please send one intent per feature as that'll help
ensure all the intents get marked as approved in Chromestatus appropriately
and we can help ensure that OT milestones etc are all up to date.

Thanks,
Johnny

On Wed, Jul 27, 2022 at 9:48 AM Josh Karlin  wrote:

> Greetings. The Privacy Sandbox Ads APIs experiment includes several APIs
> and we'd like to extend all of them another three milestones to M107, with
> the expectation that we will likely continue to ask for extensions to
> support ecosystem testing.
>
> This OT covers several APIs (Attribution Reporting
> ,
> FLEDGE
> ,
> Topics
> ,
> Fenced Frames
> ,
> and Shared Storage
> )
> that are part of the Privacy Sandbox initiative. Based on feedback we
> have already received
> , it
> will take more time before experimenters can provide the feedback that we
> need to validate and improve them. We also expect to add several new
> features for testing (including Shared Storage and support for FLEDGE on
> mobile) in upcoming releases.
>
> I've bundled the requests for each API into a single intent to extend
> since they are part of the same OT and all require the extension. If you'd
> like, they can instead be requested individually.
>
> Thanks,
>
> Josh
>
> --
> 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/CAANMuaO4BR3PMHJ8r-%2BzBpb2cDfbMKs%2Bg8syM-8ZUnSnrA5KTw%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/CACZRgz5tN-jpoSkqM2%3DxXj1%3DzXe5zZR-HYjMoNTm4KeEtSsK%3Dw%40mail.gmail.com.

[blink-dev] Upcoming chromestatus.com home page change

[Johnny Stenback]

Hello blink-dev,

I wanted to give everyone a heads up that what you’ll see when you visit
chromestatus.com about a week from now will change from being the “All
features” view to the “Roadmap” view. This change is to give visitors who
are not intimately involved in the development of Chromium a more
action-focused view of recent and upcoming features that they may want to
incorporate into the sites they are developing. For feature owners, this
change is a reminder that the feature entries they produce are, in fact,
consumed by go-to-market efforts and by web developers.  The “All features”
view will remain in place and function as it has been.

A side effect of this change is that the importance of the data in
chromestatus being accurate increases. And please be aware that that’s a
trend in that more and more downstream users of this tool are working
towards relying more and more on the correctness of this data. So please,
continue to pay attention to the data in your feature entries as they
evolve through the launch process and fix anything that is out of date any
time you’re made aware of errors, especially as your features get close to
launching.

Cheers,
Johnny

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

Re: [blink-dev] Duplicate entries for AudioContext.outputLatency

[Johnny Stenback]

https://chromestatus.com/feature/5679218739380224 has now been deleted.

Cheers,
Johnny

On Wed, Mar 23, 2022 at 11:03 AM Johnny Stenback 
wrote:

> Hey Ajay,
>
> Yep, we can delete one of those. I'm waiting on confirmation, and once I
> receive that then I'll delete...
>
> Cheers,
> Johnny
>
> On Wed, Mar 23, 2022 at 10:51 AM 'Ajay Rahatekar' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Hi blink-dev,
>>
>> There are 2 chromestatus.com entries for AudioContext.outputLatency
>> https://chromestatus.com/feature/5679218739380224 and
>> https://chromestatus.com/feature/5682265146261504
>>
>> Is there a procedure to request deleting
>> https://chromestatus.com/feature/5679218739380224?
>>
>> Thanks in advance,
>>
>> Ajay
>>
>>
>> --
>> 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/5186411f-61a7-46fe-82c4-4dcc81ec10dcn%40chromium.org
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5186411f-61a7-46fe-82c4-4dcc81ec10dcn%40chromium.org?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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/CACZRgz5OBuuW56-khkpfYiPzTeQCPAF1%2BCo-BvWrR9hnWRovng%40mail.gmail.com.

Re: [blink-dev] Duplicate entries for AudioContext.outputLatency

[Johnny Stenback]

Hey Ajay,

Yep, we can delete one of those. I'm waiting on confirmation, and once I
receive that then I'll delete...

Cheers,
Johnny

On Wed, Mar 23, 2022 at 10:51 AM 'Ajay Rahatekar' via blink-dev <
blink-dev@chromium.org> wrote:

> Hi blink-dev,
>
> There are 2 chromestatus.com entries for AudioContext.outputLatency
> https://chromestatus.com/feature/5679218739380224 and
> https://chromestatus.com/feature/5682265146261504
>
> Is there a procedure to request deleting
> https://chromestatus.com/feature/5679218739380224?
>
> Thanks in advance,
>
> Ajay
>
>
> --
> 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/5186411f-61a7-46fe-82c4-4dcc81ec10dcn%40chromium.org
> 
> .
>

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

Re: [blink-dev] Intent to Ship: Remove clamping of setTimeout(..., 0)

[Johnny Stenback]

M97 is also a better alternative in that it's not a release that will be
supported for 8 weeks, as M96 would be, and thus we'll be in a better
position to handle any fallout from this in M97.

On Thu, Oct 14, 2021 at 6:32 AM Mike Taylor  wrote:

> Ah, yeah. I think I intended to write M97 (but I'm admittedly terrible
> with calendars). That seems like a good milestone to try to ship.
>
> On 10/14/21 5:01 AM, Yoav Weiss wrote:
>
> If I'm reading the Chromium Dashboard schedule
>  correctly, M97 stable will be
> released early January, so after the holiday season. It seems worthwhile to
> try and ship this at that point (but not in M96).
>
>
> On Thu, Oct 14, 2021 at 4:12 AM Wanming Lin  wrote:
>
>> Thank you all for your great support!
>>
>> There's no more outstanding questions or bugs in my mind that might block
>> shipping this, but I need to get 3 LGTMs from you to process the final
>> ship.
>> Is that possible we could cherry-pick it to M96?  Otherwise we have to
>> wait about 4 months for M98 stable, and M96 stable release at Nov 16, 2021,
>> we may have some latency for bug reports. But it's up to your opinions. :)
>>
>>
>> Thanks,
>> Wanming
>> On Wednesday, October 13, 2021 at 9:54:59 PM UTC+8 mike...@chromium.org
>> wrote:
>>
>>> It does seem worth trying to ship this given the lack of (known) bugs,
>>> but maybe we should consider waiting until M98 to avoid sites needing to
>>> deploy fixes during the holiday season, assuming a few weeks of latency
>>> for bug reports.
>>>
>>> On 10/13/21 9:18 AM, Philip Jägenstedt wrote:
>>> > Thanks for explaining this, Rakina, I definitely didn't get the whole
>>> > context on my first pass.
>>> >
>>> > In particular the fact that current behavior matches Firefox is a
>>> > strong reason to not make any further changes.
>>> >
>>> > Wanming, are you aware of any other outstanding questions or bugs that
>>> > might crop up if we attempt to ship this?
>>> >
>>> > On Wed, Oct 13, 2021 at 11:14 AM Rakina Zata Amni 
>>> wrote:
>>> >> I had a quick chat with Philip about whether we want to fix
>>> crbug.com/1209717 or not, and I think we don't need to fix that bug for
>>> shipping this.
>>> >> In the bug, the code expected a same-document history navigation (and
>>> its scroll restoration) would happen synchronously, so any scroll changes
>>> that happen after the navigation was initiated won't be overwritten by the
>>> history scroll restore. Because all history navigation in Chrome needs to
>>> go through the browser process, the same-document history navigation is
>>> actually asynchronous, and so the history scroll restoration is also
>>> asynchronous. Looks like this was fast enough before that the history
>>> scroll restoration might happen before code with clamping of setTimeout,
>>> but now that the clamping is being removed it's not fast enough, so we got
>>> that regression.
>>> >>
>>> >> That bug was derived from crbug.com/1205285, which is noted as
>>> having been fixed by Wikipedia since it's showing a similar behavior on
>>> Firefox with Fission. The fix itself is very simple: they just needed to
>>> set history.scrollRestoration to "manual". As the motivating bug has been
>>> fixed with a simple fix, and asynchronous same-document history navigation
>>> has been in Chrome for a while (and is also what Firefox is doing), I think
>>> we don't need to reland/make the full fix for crbug.com/1209717.
>>> >>
>>> >>
>>> >> On Tue, Oct 12, 2021 at 11:16 PM Philip Jägenstedt <
>>> foo...@chromium.org> wrote:
>>> >>> Hi Wanming,
>>> >>>
>>> >>> If the reason for reverting no longer applies, then trying to reland
>>> the fix sounds like a reasonable next step. If that is done and it sticks
>>> this time, it seems to me we might be ready for a final Intent to Ship for
>>> this. At least I don't know what more could be done to vet the change
>>> before trying to let it reach stable.
>>> >>>
>>> >>> Best regards,
>>> >>> Philip
>>> >>>
>>> >>> On Tue, Oct 12, 2021 at 10:14 AM Wanming Lin 
>>> wrote:
>>>  Hi all,
>>> 
>>>  Thanks Philip's bridge, I've been connected with the release
>>> managers and completed the new round of origin trial on M95 (we reached an
>>> agreement on reverting the change after the first M95 Beta release itself).
>>> During this period, I didn't receive any relevant bugs.
>>> 
>>>  But unfortunately, after the origin trial, the fix for the previous
>>> block issue #1209717 was reverted due to regression at issue #1254867,
>>> @rakina is considering that maybe we can do nothing here because per
>>> crbug.com/1205285#c16, the original bug on Wikipedia has been fixed on
>>> Wikipedia's side.
>>
>>
> Do I understand correctly and the only relationship between this change
> and the scroll restoration issue is that the bug is revealed when a 0
> timeout is present?
>
>
>>> 
>>>  So we are looking forward your feedbacks, on both the bug of
>>> #1209717 and what's the next step t