Re: [blink-dev] Intent to ship: MP4 container support for MediaRecorder

[Yoav Weiss (@Shopify)]

LGTM1

On Tue, Mar 5, 2024 at 5:01 PM 'Michaela Merz' via blink-dev <
blink-dev@chromium.org> wrote:

> Thank you for adding this. Finally we're going to be able to do
> cross-browser video-recordings and playing. Can't wait to see it in
> production.
>
> M.
>
>
> On Monday, March 4, 2024 at 3:50:13 PM UTC-7 sun...@microsoft.com wrote:
>
>> Mike, I've added feature detection and developer engagement on
>> https://docs.google.com/document/d/1WV795DHY3Jf2p_htuAKZ9DXUefiGdQs29mCb8vRiHt8/edit?usp=sharing
>> .
>>
>> On Monday, March 4, 2024 at 2:13:11 PM UTC-8 Sunggook Chue wrote:
>>
>>> Yoav,
>>>
>>> Philipp's answer is correct, please let me know if you need any more
>>> info to unblock.
>>>
>>> On Thursday, February 29, 2024 at 11:53:47 AM UTC-8
>>> philipp...@googlemail.com wrote:
>>>
 Yoav,

 in WebRTC land "we have a sample for that" (thanks to the one and only
 WebRTC devrel guy Sam Dutton, I think I stole this tagline from him)!
   https://webrtc.github.io/samples/src/content/getusermedia/record/
 with recent changes to improve MP4 support.

 Discovery currently happens with isTypeSupported but it seems the WG
 just decided to deprecate that:

 https://github.com/w3c/mediacapture-record/issues/202#issuecomment-1956065141
 (not sure how I feel about that, I'd rather nuke MediaRecorder entirely
 in favor of WebCodecs + IndexedDB)

 Am Do., 29. Feb. 2024 um 09:13 Uhr schrieb Yoav Weiss (@Shopify) <
 yoav...@chromium.org>:

>
>
> On Thu, Feb 29, 2024 at 1:46 AM 'Sunggook Chue' via blink-dev <
> blin...@chromium.org> wrote:
>
>> Here is an explainer, summary only.
>>
>>
>> https://docs.google.com/document/d/1WV795DHY3Jf2p_htuAKZ9DXUefiGdQs29mCb8vRiHt8/edit?usp=sharing
>
>
> Thanks! That's very useful! :)
>
> What's the feature detection story? How can developers know which
> formats are supported?
>
>
>>
>>
>> On Wednesday, February 28, 2024 at 7:53:29 AM UTC-8
>> yoav...@chromium.org wrote:
>>
>>> On Tue, Feb 27, 2024 at 1:45 AM Mike Taylor 
>>> wrote:
>>>

 On 2/22/24 9:21 PM, 'Sunggook Chue' via blink-dev wrote:

 Contact emails

 sun...@microsoft.com

 dalec...@chromium.com (reviewer and mentor).

 Explainer

 https://www.w3.org/TR/mediastream-recording/

 That's not an explainer..
>>> Could you maybe write a short (inline?) explainer that outlines what
>>> it is that we want to ship, what it would help developers achieve, how 
>>> we
>>> envision them using this feature, etc.?
>>>
>>>

 Specification

 https://www.w3.org/TR/mediastream-recording/

 Summary

 Adds support for muxing audio/video into MP4 containers with
 MediaRecorder.

 Developers can record media format, container, with MP4 of H264
 video and AAC audio codecs in the MediaRecorder API.


 Blink component

 Blink::MediaRecording

 TAG review
 TAG review status
 Risks

 No Additional risks on existing containers such as webm.

 Interoperability and Compatibility

 This is missing vendor and developer signals - can you add (or
 request) them please?

 Ergonomics

 N/A


 Activation

 Unchallenging to use.


 Security

 N/A


 WebView Application Risks

 N/A


 Debuggability

 Developers can see the API failure on DevTools.

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

 Yes

 Flag name

 MediaRecorderEnableMp4Muxer

 Tracking bug

 https://issues.chromium.org/issues/40127044

 Launch bug

 https://issues.chromium.org/issues/40127044

 Sample links

 https://webrtc.github.io/samples/src/content/getusermedia/record/

 Estimated milestones

 Dev Trial on Desktop: 120


 Link to entry on the Chrome Platform Status

 https://chromestatus.com/feature/5163469011943424

 Links to previous Intent discussions

 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 

Re: [blink-dev] Intent to Ship: Compute Pressure

[Yoav Weiss (@Shopify)]

On Tue, Mar 5, 2024 at 7:14 PM Reilly Grant  wrote:

> On Tue, Mar 5, 2024 at 5:56 AM Mike Taylor  wrote:
>
>>
>> On 3/5/24 6:57 AM, Mandy, Arnaud wrote:
>>
>> Contact emails
>>
>> kenneth.r.christian...@intel.com, arnaud.ma...@intel.com,
>> wei4.w...@intel.com, raphael.kubo.da.co...@intel.com
>>
>> Explainer
>>
>> https://github.com/w3c/compute-pressure/blob/main/README.md
>>
>> Specification
>>
>> https://www.w3.org/TR/compute-pressure
>>
>> Summary
>>
>> The Compute Pressure API offers high-level states that represent the
>> pressure on the system. It allows the implementation to use underlying
>> hardware/platform metrics to inform the API users of possible stress (high
>> CPU load at the moment) on the system and consequently take the corrective
>> actions needed.
>>
>> “Pressure” is a generic term by design – at the moment it is calculated
>> based on CPU load, but future plans include using signals from temperature
>> and battery status, for example.
>>
>> https://developer.chrome.com/docs/web-platform/compute-pressure/
>>
>> Blink component
>>
>> Blink>PerformanceAPIs>ComputePressure
>> 
>>
>> Search tags
>>
>> compute pressure
>> 
>>
>> TAG review
>>
>> spec review: https://github.com/w3ctag/design-reviews/issues/795
>>
>> wide review tracker: https://github.com/w3c/compute-pressure/issues/177
>>
>> TAG review status
>>
>> Issues addressed
>>
>> Chromium Trial Name
>>
>> ComputePressure
>>
>> Origin Trial documentation link
>>
>> https://developer.chrome.com/docs/web-platform/compute-pressure/
>>
>> Origin Trials history
>>
>> The first Origin Trial
>> 
>>  was
>> run between M92-94.
>>
>> The Compute Pressure API was widely redesigned after this OT to resemble
>> existing observer-based web APIs and also to provide better privacy and
>> security guarantees after discussions with PING.
>>
>> The second Origin Trial
>>  took
>> place during M115-M120.
>> During this origin trial we realized that the full capacity of the API
>> couldn’t be tested due to a lack of support for third-party tokens. An Origin
>> Trial extension
>> 
>>  was
>> necessary until M123.
>>
>> Is there any developer feedback that can be shared from the origin
> trials? I'm looking for signals that developers have been able to improve
> user experiences by using the new signals.
>

+1. That would be great feedback to have!

>
>> Risks Interoperability and Compatibility
>>
>> *Gecko*: No signal (
>> https://github.com/mozilla/standards-positions/issues/521)
>>
>> Can you add a comment to this issue pointing to this I2S, and any
>> relevant changes since the original issue was opened?
>>
>>
>> *WebKit*: Negative (
>> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031845.html) This
>> issue has been taken into account:
>> https://github.com/w3c/compute-pressure/issues/24
>>
>> Skimming through the issues raised from WebKit folks, I believe y'all
addressed the privacy issues in
https://github.com/w3c/compute-pressure/issues/197.

The other issue raised is around the usefulness (or lack thereof) of apps
changing behavior based on system load, rather than based on the time is
takes them to achieve certain tasks. Was that discussed somewhere?

https://github.com/w3c/compute-pressure/issues/24#issuecomment-1022516116
>> suggests asking for re-review once issue 24 is settled (at least that's my
>> interpretation). Do you know if that ever happened?
>>
>>
>> *Web developers*: Positive (
>> https://github.com/w3c/compute-pressure/issues/14)
>>
>> *Other signals*:
>>
>> Security
>>
>> https://github.com/w3c/compute-pressure/issues/79
>>
>> WebView application risks
>>
>> No
>>
>> Debuggability
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, ChromeOS, Android, and Android WebView)?
>>
>> No,
>> Windows, Linux, ChromeOs, Mac.
>>
>> Support on Android (incl. Android WebView) has been deprioritized as
>> there is no current way to access the telemetry needed after Android 11,
>> and the current partners we are engaging with have no need as they are
>> using native solutions on Android at this point.
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Yes
>> https://wpt.fyi/results/compute-pressure?run_id=5116280230641664
>>
>> The wpt.fyi results are flaky due to WPT bug 44438
>> 
>>
>> DevTrial instructions
>>
>> https://github.com/w3c/compute-pressure/blob/main/HOWTO.md
>>
>> Flag name on chrome://flags
>>
>> see https://github.com/w3c/co

Re: [blink-dev] Re: Intent to Ship: WebSocketStream

[Yoav Weiss (@Shopify)]

LGTM3

On Tue, Mar 5, 2024 at 10:16 AM 'Thomas Steiner' via blink-dev <
blink-dev@chromium.org> wrote:

> As an additional developer signal showing that developers want this,
> there's a polyfill: https://github.com/CarterLi/websocketstream-polyfill.
>
> On Tue, Mar 5, 2024 at 10:10 AM Domenic Denicola 
> wrote:
>
>> LGTM2.
>>
>> I appreciate Adam's careful attention to all portions of the process
>> here, and also Alex's probing as to whether we're meeting the developer
>> interest portion. Although this would be more of a slam-dunk if we were
>> able to get that partner to comment publicly on their experience, I'm
>> willing to take Adam's word on it about the private feedback.
>>
>> Combined with the general positive sentiment, e.g. from Deno (which is a
>> server-side runtime, but I think we have a good amount of experience
>> showing that people like writing the same code across server and browser),
>> and in response to the 2020 article
>> ,
>> and the repeated "when is this coming" comments in the tracking bug
>> ... I think we have enough
>> evidence that this will move the web forward in a positive way.
>>
>> With my API owner hat off, I'm also just happy about this API existing,
>> as I think it's generally good for the platform when we go back and take
>> older, but still popular technologies, and retrofit them with modern
>> capabilities and APIs like backpressure-supporting streams. It makes the
>> web feel more cohesive and well-designed.
>>
>> On Tuesday, March 5, 2024 at 8:46:59 AM UTC+9 Adam Rice wrote:
>>
>>> Thanks Alex,
>>>
>>> We have a partner who need backpressure to avoid jank in their app. I've
>>> been waiting for them to comment, but it's taking a while.
>>>
>>> Adam
>>>
>>> On Thu, 22 Feb 2024 at 01:53, Alex Russell 
>>> wrote:
>>>
 Hey Adam,

 Sorry for the slow follow up. Were there folks beyond the Deno
 ecosystem that expressed interest and/or satisfaction with the design?
 We're need to make a case in API OWNERS that there's enough developer
 interest to surmount the lack of other vendor interest. Are you able to
 share more?

 Thanks,

 Alex

 On Friday, February 16, 2024 at 12:10:50 AM UTC-8 Adam Rice wrote:

> Any reason the PR for the spec hasn't landed yet?
>
>
> We don't have interest from a second implementer yet. As far as I
> know, Deno doesn't count for this purpose.
>
> On Fri, 16 Feb 2024 at 03:50, Chris Harrelson 
> wrote:
>
>> Hi,
>>
>> Any reason the PR for the spec hasn't landed yet?
>>
>> On Thu, Feb 15, 2024 at 7:54 AM Mike Taylor 
>> wrote:
>>
>>> Thank you - LGTM1
>>> On 2/15/24 7:16 AM, Adam Rice wrote:
>>>
>>> Thanks Mike,
>>>
>>> I have requested the approvals. Sorry for the delay, I didn't
>>> understand the interface.
>>>
>>> Adam
>>>
>>> On Thu, 15 Feb 2024 at 01:39, Mike Taylor 
>>> wrote:
>>>
 Hi Adam,

 Would you mind requesting approvals in the chromestatus entry for
 the various review gates?
 On 2/8/24 1:30 AM, Adam Rice wrote:

 Unfortunately, no partners were ready when we did the OT, so there
 was no feedback at all. However, we have subsequently received private
 feedback that the API works well.

 On Thu, 8 Feb 2024 at 04:23, Alex Russell 
 wrote:

> Hey Adam,
>
> Glad to see this moving forward! Has there been a summary
> somewhere of the OT feedback? Also, we noted that the other reviews 
> were
> marked as unstarted in chromestatus; we will likely hold off voting 
> until
> those are in flight.
>
> Thanks!
>
> On Tuesday, February 6, 2024 at 1:43:46 PM UTC-8 Adam Rice wrote:
>
>> Contact emails ri...@chromium.org
>>
>> Explainer
>> https://github.com/ricea/websocketstream-explainer/blob/master/README.md
>>
>> https://docs.google.com/document/d/1XuxEshh5VYBYm1qRVKordTamCOsR-uGQBCYFcHXP4L0/edit
>>
>> Specification https://github.com/whatwg/websockets/pull/48
>>
>> Design docs
>> https://web.dev/websocketstream/
>>
>> Summary
>>
>> The WebSocket API provides a JavaScript interface to the RFC6455
>> WebSocket protocol. While it has served well, it is awkward from an
>> ergonomics perspective and is missing the important feature of
>> backpressure. The intent of the WebSocketStream API is to resolve 
>> these
>> deficiencies by integrating WHATWG Streams with the WebSocket API.
>>
>>
>> Blink component Blink>Network>WebSockets
>> 

Re: [blink-dev] Intent to Ship: Used color scheme root scrollbars

['Yaroslav Shalivskyy' via blink-dev]

Mike and Daniel, thank you for the suggestions!

I requested browser vendor positions as well as reviews for chromestatus 
entry.

Mozilla: [css-color-adjust-1] Root non-overlay scrollbars used color scheme 
· Issue #995 · mozilla/standards-positions (github.com) 

WebKit: [css-color-adjust-1] Root non-overlay scrollbars used color scheme 
· Issue #326 · WebKit/standards-positions (github.com) 


I updated the chromestatus entry with these links as well.

On Monday, March 4, 2024 at 12:08:23 PM UTC-8 mike...@chromium.org wrote:

> Thanks for the summary of the experiment results on Edge - sounds positive.
>
> If this is purely a browser UI change, then we don't really need the 
> blink-dev process at all. However, if we're relying on concepts defined in 
> a CSSWG draft, and devs can change the outcome w/ some CSS (or maybe here, 
> the lack of CSS to result in non-`normal` computed value...) it would be if 
> there were interoperability in UI choices across browsers. I don't 
> necessarily think we should block on the outcome, but requesting vendor 
> positions could be useful.
>
> (and Daniel, if you scroll down a bit - I did ask about TAG and browser 
> signals. :))
> On 3/2/24 1:10 PM, Daniel Bratell wrote:
>
> Mike didn't refer to the TAG review or browser signals, but the review 
> steps in chromestatus. The intent should request, privacy, security, 
> enterprise, and the other steps there.
>
> I agree that this lives in the borderland between user agent UI and a web 
> visible change so some shortcuts might be possible to motivate, but you 
> still need to click the the appropriate buttons in the chromestatus tool.
>
> /Daniel
> On 2024-03-01 21:10, 'Yaroslav Shalivskyy' via blink-dev wrote:
>
> Hello Mike,
>
> Thank you for taking a look!
>
> I am seeking consensus on how to approach the feature from a 
> standardization perspective. I think the feature can be considered a 
> browser UI change, which is why I haven't requested a TAG review or 
> signals from other engines. However, I am open to doing so if necessary.
>
> I apologize for any confusion. We did the general experimentation in Edge 
> (not the "origin trials" as I mentioned in the email). Retention reports 
> were neutral, and we observed no regressions in scorecards. Also, we have 
> not received any negative user feedback thus far.
>
> I am working on requesting reviews for my chromestatus entry. Thanks for 
> pointing this out!
>
> Thanks,
> Yaroslav
>
> On Friday, March 1, 2024 at 5:52:55 AM UTC-8 mike...@chromium.org wrote:
>
>> Hi there,
>>
>>
>> Would you mind requesting reviews for the various review gates in your 
>> chromestatus entry?
>>
>>
>> On 2/29/24 4:12 PM, 'Yaroslav Shalivskyy' via blink-dev wrote:
>>
>> Contact emails 
>> gerc...@microsoft.com, yshal...@microsoft.com
>>
>> Explainer 
>> None
>>
>> Specification 
>> https://www.w3.org/TR/css-color-adjust-1
>>
>> Summary 
>>
>> Makes the browser use the user's preferred color scheme to render the 
>> viewport scrollbars if the value of "page’s supported color schemes" is 
>> 'normal' or not specified, and the computed value of the color-scheme for 
>> the root element is 'normal'. Viewport scrollbars can be considered to be 
>> outside the web content. Therefore, the user agents should honor the user's 
>> preferred color scheme when rendering viewport scrollbars if page authors 
>> have not explicitly specified support for color schemes.
>>
>>
>> Blink component 
>> Blink>Layout>Scrollbars 
>> 
>>
>> TAG review 
>> None
>>
>> TAG review status 
>> Not applicable
>>
>> Any reason you think this is N/A, or have you just not requested TAG 
>> review?
>>
>>
>> Risks 
>>
>> Interoperability and Compatibility 
>>
>> None
>>
>>
>> *Gecko*: No signal
>>
>> *WebKit*: No signal
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> Could we request signals please?
>>
>>
>> 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)? 
>> Yes
>>
>> Is this feature fully tested by web-platform-tests 
>> 
>> ? 
>> No
>>
>> Flag name on chrome://flags 
>> None
>>
>> Finch feature name 
>> UsedColorSchemeRootScrollbars
>>
>> Requires code in //chrome? 
>> False
>>
>> Tracking bug 
>> https://issues.chromium.org/issues/40259909
>>
>> Measurement 
>> Added a use counter UsedColorSchemeRootScrollbarsDark. The counter tracks 
>> the number of users who have dark mode root scrollbars due to the

[blink-dev] Re: Intent to Experiment: Cookie Deprecation Labeling

['Russ Hamilton' via blink-dev]

FYI, based on feedback from testers 
(https://github.com/WICG/turtledove/issues/946) we are going to send the 
Cookie-Deprecation label headers during the trusted bidding and trusted 
scoring signals fetches for Protected Audience auctions beginning in M122. 
Note that if the user is not part of the Facilitated testing groups or has 
disabled third party cookies then this feature will not be added to the 
header.

On Wednesday, October 25, 2023 at 5:05:53 PM UTC-4 John Delaney wrote:

> *Contact emails*
> john...@chromium.org, wande...@chromium.org, lin...@chromium.org
>
> *Explainer*
>
> https://github.com/privacysandbox/tpcd-labeling/blob/main/cookie_deprecation_labeling_explainer.md
> https://developer.chrome.com/en/docs/privacy-sandbox/chrome-testing
>
> *Specification*
> None
>
> *Summary*
> To prepare for the third-party cookie deprecation, it is important to 
> understand the full impact of Chrome’s planned transition from third-party 
> cookies to the Privacy Sandbox Ads APIs.
>
> This experiment exposes a temporary set of APIs which provide access to 
> browser-determined treatment and control groups to support opt-in server 
> side testing of the third-party cookie deprecation.
>
> *Blink component*
> A-N/A
>
> *TAG review*
> Not requesting TAG review as this API is a temporary Chrome-specific 
> experiment.
>
> *Risks*
>
> *Interoperability and Compatibility*
> This feature is only shipping in Chrome to support the third-party cookie 
> deprecation, and will not be interoperable with other vendors.
>
> *WebView application risks*
> Not available on WebView
>
>
> *Goals for experimentation*
> The goal of this experiment is to allow adtechs to evaluate the impact of 
> third party cookie phase out through opt-in server side testing. We expect 
> partners to run experiments downstream from the browser provided treatment 
> and control groups.
>
> *Experiment Behavior and Risks*
> This experiment will expose temporary APIs which allow access to browser 
> provided experiment labels. 
>
> To ensure all parties can easily get access to labels, we intend to expose 
> the APIs without a traditional origin trial. 
>
> To limit burn-in risk, the new APIs will only be available to at most ~10% 
> of users. These APIs should have very little utility to developers outside 
> of this specific temporary experiment, it seems unlikely that user-visible 
> breakage would occur as a result of the eventual removal.
>
> *Timeline*
> We intend to remove the labeling APIs when Mode B of the experiment ends, 
> which we expect to be by the end of Q2 2024 at the earliest.
>
> This experiment temporarily adds a new surface to the web that could be 
> used for active fingerprinting. This is mitigated by the fact that: 
>
>- only a subset are assigned labels, reducing the usefulness of the 
>label for fingerprinting
>- labels are not sent for users who block third-party cookies, to 
>ensure consistency with those users’ current settings
>- the labeling APIs will be removed by the time third-party cookies 
>are phased out
>- label assignment is independent of users' browsing activity
>
>
> *Ongoing technical constraints*
> None
>
> *Debuggability*
> None
>
> *Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, Chrome OS, Android, and Android WebView)?*
> No, not supported on WebView.
>
> *Is this feature fully tested by web-platform-tests?*
> No
>
> *Flag name on chrome://flags*
> #tpc-phase-out-facilitated-testing
>
> *Requires code in //chrome?*
> False
>
> *Estimated milestones*
>   Experiment desktop first 119
>   Experiment Android first 119
>
> *Intent to Prototype*
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/8mlWTOcEzcA/m/NZJSW0weAQAJ
>
> *Link to entry on the Chrome Platform Status*
> https://chromestatus.com/feature/5189079788683264
>

-- 
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/b14382a4-c6c1-43c6-b172-0385a27fd14an%40chromium.org.

Re: [blink-dev] Re: Intent to Deprecate and Remove Web SQL

['Panos Astithas' via blink-dev]

The difference between the last trial milestone and the end date is due to
the fact that origin trial tokens contain the expiration date by design.
Given that the token needs to expire after the ending milestone has passed
and given the often lengthy browser update cycle for some users, we ended
up with a compromise that expects most clients will have been updated when
the second to next milestone after the ending one has been released (4+4
weeks later). It is really aiming at avoiding the origin trial feature
being prematurely unavailable to users.

Granted this is not very obvious, but it has worked reasonably well in
practice.

Thanks,
Panos

On Sun, Mar 3, 2024 at 11:35 AM Hans Meyer  wrote:

> Fair enough Anton. Admittedly a bit of wishful thinking on my part.
>
> Although FWIW, the origin trial status in dev tools only mentions the
> expiration date, not version. By no means an excuse, but I'm curious, why
> express the trial expiration in terms of a date at all, much less a date
> that is 1.5 months after from when it effectively ends for most users?
>
> Again, no excuses. I agree the versioning was clearly communicated. Just
> wanted to give some feedback to consider to possibly minimize confusion in
> the future.
>
> Thanks for your response,
> Hans
>
>
>
> On Sunday, March 3, 2024 at 10:50:43 AM UTC-7 Anton Bershanskyi wrote:
>
>> Hi Hans,
>>
>> Could you please clarify which web page suggests that the WebSQL
>> availability would extend to Chrome 124 inclusive? All news/articles I
>> could find online suggest that the last version supporting WebSQL would be
>> 123:
>>
>>- Feature: Deprecate and Remove WebSQL
>>
>>- Web SQL deprecation timeline updated
>> 
>> (the
>>date for Chromium 123 is odd in this one)
>>- Deprecating and removing Web SQL
>>
>>
>> Also, the DevTools UI already removed WebSQL viewer from "Application"
>> tab.
>> 
>> The change will arrive in Chrome Canary next week. WebSQL flag is also
>> considered to be expired
>>  (no longer available
>> and will be removed from source code soon).
>>
>> Sincerely,
>> Anton.
>> On Sunday, March 3, 2024 at 5:21:18 PM UTC+2 Hans Meyer wrote:
>>
>>> Hi Ayu,
>>>
>>> Can you clarify... are you saying the deprecation trial does NOT extend
>>> to Chrome 124? I would not have expected that given that the trial's
>>> expiration date has been communicated consistently as *May 28, 2024*.
>>>
>>> Thanks,
>>> Hans
>>>
>>>
>>> On Friday, February 23, 2024 at 11:15:46 AM UTC-7 Ayu Ishii wrote:
>>>
 Hi Antonio,

 That is correct, 123 will be the last supported version via flag or
 policy.
 124 will be the first version WebSQL will no longer be available even
 with a flag or policy.

 Best,
 Ayu

 On Friday, February 23, 2024 at 8:02:48 AM UTC-8 Antonio MORENO wrote:

> Hi all,
>
> Related to this topic, a bit of a simple question: In the initial
> announcement, it seemed to indicate that Chrome 123 would be the first
> version without any kind of support for WebSQL. However, at least in the
> current version of the beta (123.0.6312.4) support is still there, and can
> be enabled with the corresponding flag. Can you confirm if this will be 
> the
> case with the stable version of 123, and the feature will be removed only
> in version 124?
>
> Thanks, and regards,
>
> Antonio.
>
> On Tuesday, February 13, 2024 at 11:24:34 AM UTC+1 Etienne Noël wrote:
>
>> Hi,
>>
>> We have been communicating this deprecation for a while now so
>> unfortunately, we will not extend it further.
>>
>> It’s a significant source of security issues so we will keep the
>> original deprecation timeline.
>>
>> If that can be useful to your situation, SQLite is available in the
>> browser:
>>
>> https://developer.chrome.com/blog/sqlite-wasm-in-the-browser-backed-by-the-origin-private-file-system
>>
>> It might make the migration easier for you if that’s a
>> suitable solution.
>>
>> Thank you,
>>
>> Etienne
>>
>>
>> Etienne Noël
>>
>> Engineering Manager
>>
>> Chrome Storage
>>
>>
>> On Mon, Feb 12, 2024 at 16:56 Bobby Langley 
>> wrote:
>>
>>> Just started using the origin trial in one of our apps that requires
>>> a slightly overly extertive lift to change from webSQL to IndexedDB. The
>>> expiry says May 28, 2024 -- what is the potential that date could be
>>> extended while we work to release our new version?
>>>
>>> On Friday, September 8, 2023 at 4:24:25 PM UTC-4 Panos Astithas
>>> wrot

Re: [blink-dev] Intent to Ship: Compute Pressure

[Reilly Grant]

On Tue, Mar 5, 2024 at 5:56 AM Mike Taylor  wrote:

>
> On 3/5/24 6:57 AM, Mandy, Arnaud wrote:
>
> Contact emails
>
> kenneth.r.christian...@intel.com, arnaud.ma...@intel.com,
> wei4.w...@intel.com, raphael.kubo.da.co...@intel.com
>
> Explainer
>
> https://github.com/w3c/compute-pressure/blob/main/README.md
>
> Specification
>
> https://www.w3.org/TR/compute-pressure
>
> Summary
>
> The Compute Pressure API offers high-level states that represent the
> pressure on the system. It allows the implementation to use underlying
> hardware/platform metrics to inform the API users of possible stress (high
> CPU load at the moment) on the system and consequently take the corrective
> actions needed.
>
> “Pressure” is a generic term by design – at the moment it is calculated
> based on CPU load, but future plans include using signals from temperature
> and battery status, for example.
>
> https://developer.chrome.com/docs/web-platform/compute-pressure/
>
> Blink component
>
> Blink>PerformanceAPIs>ComputePressure
> 
>
> Search tags
>
> compute pressure
> 
>
> TAG review
>
> spec review: https://github.com/w3ctag/design-reviews/issues/795
>
> wide review tracker: https://github.com/w3c/compute-pressure/issues/177
>
> TAG review status
>
> Issues addressed
>
> Chromium Trial Name
>
> ComputePressure
>
> Origin Trial documentation link
>
> https://developer.chrome.com/docs/web-platform/compute-pressure/
>
> Origin Trials history
>
> The first Origin Trial
> 
>  was
> run between M92-94.
>
> The Compute Pressure API was widely redesigned after this OT to resemble
> existing observer-based web APIs and also to provide better privacy and
> security guarantees after discussions with PING.
>
> The second Origin Trial
>  took
> place during M115-M120.
> During this origin trial we realized that the full capacity of the API
> couldn’t be tested due to a lack of support for third-party tokens. An Origin
> Trial extension
> 
>  was
> necessary until M123.
>
> Is there any developer feedback that can be shared from the origin trials?
I'm looking for signals that developers have been able to improve user
experiences by using the new signals.

>
> Risks Interoperability and Compatibility
>
> *Gecko*: No signal (
> https://github.com/mozilla/standards-positions/issues/521)
>
> Can you add a comment to this issue pointing to this I2S, and any relevant
> changes since the original issue was opened?
>
>
> *WebKit*: Negative (
> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031845.html) This
> issue has been taken into account:
> https://github.com/w3c/compute-pressure/issues/24
>
> https://github.com/w3c/compute-pressure/issues/24#issuecomment-1022516116
> suggests asking for re-review once issue 24 is settled (at least that's my
> interpretation). Do you know if that ever happened?
>
>
> *Web developers*: Positive (
> https://github.com/w3c/compute-pressure/issues/14)
>
> *Other signals*:
>
> Security
>
> https://github.com/w3c/compute-pressure/issues/79
>
> WebView application risks
>
> No
>
> Debuggability
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?
>
> No,
> Windows, Linux, ChromeOs, Mac.
>
> Support on Android (incl. Android WebView) has been deprioritized as
> there is no current way to access the telemetry needed after Android 11,
> and the current partners we are engaging with have no need as they are
> using native solutions on Android at this point.
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes
> https://wpt.fyi/results/compute-pressure?run_id=5116280230641664
>
> The wpt.fyi results are flaky due to WPT bug 44438
> 
>
> DevTrial instructions
>
> https://github.com/w3c/compute-pressure/blob/main/HOWTO.md
>
> Flag name on chrome://flags
>
> see https://github.com/w3c/compute-pressure/blob/main/HOWTO.md
>
> Finch feature name
>
> None
>
> Non-finch justification
>
> None
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://crbug.com/1067627
>
> Launch bug
>
> https://crbug.com/1173266
>
> Sample links
> https://w3c.github.io/compute-pressure/demo
>
> Estimated milestones
>
> OriginTrial desktop extension
>
> 123
>
> OriginTrial desktop last
>
> 118
>
> OriginTrial desktop first
>
> 115
>
> OriginTrial desktop last
>
> 94
>
> OriginTrial desktop first
>
> 92
>
> DevTrial on desktop
>
> 109
>
> Anticipated spec changes
>
> None
>
> Link to entry on the Chrome P

[blink-dev] Re: Intent to Prototype: Used color scheme root scrollbars

['Yaroslav Shalivskyy' via blink-dev]

William, thanks for the interest in the feature!

1. What platform are you using?
2. Did you try enabling dark mode in the OS settings?

I have recently merged the change to make the feature available as a part 
of Experimental Web Platform features flag 
(chrome://flags/#enable-experimental-web-platform-features). Feel free to 
check it out in Chrome Canary.

On Thursday, February 29, 2024 at 6:46:14 PM UTC-8 William Smith wrote:

> I tried that command line flag and it didn't work
>
> On Wednesday, February 21, 2024 at 4:20:38 PM UTC-5 Yaroslav Shalivskyy 
> wrote:
>
>> *"Therefore, it seems like this feature doesn't have to go through the 
>> Blink process."*
>>
>> Yoav, thank you for the feedback! Yeah, I am trying to clarify the 
>> process and get consensus for the next steps.
>>
>>
>> *"This is fantastic! Is there a flag for this?"*
>> Yes! William, you can enable the feature using the runtime flag: 
>> *UsedColorSchemeRootScrollbars.*The feature doesn't have an 
>> "experimental" status yet so it can only be enabled via the command line.
>>
>> On Monday, February 19, 2024 at 10:07:10 AM UTC-8 William Smith wrote:
>>
>>> This is fantastic! Is there a flag for this?
>>>
>>> On Thursday, February 15, 2024 at 7:01:45 PM UTC-5 Yaroslav Shalivskyy 
>>> wrote:
>>>
 Hello everyone!

 I think the feature can be considered a browser UI change, so I am 
 interested to gain consensus on how to approach the feature from 
 standardization point of view. I know +Robert Flack on a separate thread 
 suggested that root scrollbars can be considered to be outside the web 
 content in a way the other scrollbars are not. E.g. nothing usually draws 
 on top of root scrollbars or styles content around / behind them.

 Enabling the feature in Can/Dev/Beta/Stable as a part of 
 experimentation in Edge so far didn't have any negative reactions.

 I am looking forward to hearing your opinion on this!

 Thanks,
 Yaroslav

 On Thursday, February 15, 2024 at 3:10:56 PM UTC-8 Yaroslav Shalivskyy 
 wrote:

> Contact emails 
> gerc...@microsoft.com, yshal...@microsoft.com
>
> Explainer 
> None
>
> Specification 
> https://www.w3.org/TR/css-color-adjust-1
>
> Summary 
>
> Makes the browser use the user's preferred color scheme to render the 
> viewport scrollbars if the value of "page’s supported color schemes" is 
> 'normal' or not specified, and the computed value of the color-scheme for 
> the root element is 'normal'. Viewport scrollbars can be considered to be 
> outside the web content. Therefore, the user agents should honor the 
> user's 
> preferred color scheme when rendering viewport scrollbars if page authors 
> have not explicitly specified support for color schemes.
>
>
> Blink component 
> Blink>Layout>Scrollbars 
> 
>
> Motivation 
>
> Many web pages don't specify the support for light/dark color schemes 
> using CSS "color-scheme" property or meta tags. In such a case, the used 
> color scheme is light for scrollbars and other interactive UI elements 
> despite the user preference set on the browser/OS level. Although the 
> behavior is expected for elements which are part of the web content, 
> viewport non-overlay scrollbars always stay on the side of the page and 
> are 
> treated by users as a part of the browser UI. The current behavior 
> confuses 
> users who have selected dark mode and expect viewport scrollbars to 
> follow 
> their choice. Edge users repeatedly reported the viewport scrollbars 
> being 
> light when dark mode is enabled. These are a few public feedback items: 
> https://www.reddit.com/r/MicrosoftEdge/comments/xrf1wb/scrollbars_are_wh 
> https://www.reddit.com/r/chrome/comments/lz0778/any_way_to_remove_or_turn_dark_
>  
> https://www.reddit.com/r/ArcBrowser/comments/18ldsj2/why_in_dark_mo 
> Relevant Chromium and Mozilla issues: 
> https://issues.chromium.org/issues/40155812 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1859940 The feature 
> doesn't impact developer APIs and still allows to control the color 
> scheme 
> for scrollbars and other controls. The new behavior makes the browser use 
> the user’s preferred color-scheme to render viewport non-overlay 
> scrollbars 
> when page authors don’t specify the color scheme for the root element.
>
>
> Initial public proposal 
> [css-color-adjust-1] Root viewport non-overlay scrollbars should 
> follow the user's preferred color scheme by default · Issue #8603 · 
> w3c/csswg-drafts (github.com) 
> 
>
> TAG review 
> None
>
> TAG review status 
> Not applicabl

Re: [blink-dev] Intent to ship: MP4 container support for MediaRecorder

['Michaela Merz' via blink-dev]

Thank you for adding this. Finally we're going to be able to do 
cross-browser video-recordings and playing. Can't wait to see it in 
production.

M.


On Monday, March 4, 2024 at 3:50:13 PM UTC-7 sun...@microsoft.com wrote:

> Mike, I've added feature detection and developer engagement on 
> https://docs.google.com/document/d/1WV795DHY3Jf2p_htuAKZ9DXUefiGdQs29mCb8vRiHt8/edit?usp=sharing
> .
>
> On Monday, March 4, 2024 at 2:13:11 PM UTC-8 Sunggook Chue wrote:
>
>> Yoav,
>>
>> Philipp's answer is correct, please let me know if you need any more info 
>> to unblock.
>>
>> On Thursday, February 29, 2024 at 11:53:47 AM UTC-8 
>> philipp...@googlemail.com wrote:
>>
>>> Yoav,
>>>
>>> in WebRTC land "we have a sample for that" (thanks to the one and only 
>>> WebRTC devrel guy Sam Dutton, I think I stole this tagline from him)!
>>>   https://webrtc.github.io/samples/src/content/getusermedia/record/
>>> with recent changes to improve MP4 support.
>>>
>>> Discovery currently happens with isTypeSupported but it seems the WG 
>>> just decided to deprecate that:
>>>  
>>> https://github.com/w3c/mediacapture-record/issues/202#issuecomment-1956065141
>>> (not sure how I feel about that, I'd rather nuke MediaRecorder entirely 
>>> in favor of WebCodecs + IndexedDB)
>>>
>>> Am Do., 29. Feb. 2024 um 09:13 Uhr schrieb Yoav Weiss (@Shopify) <
>>> yoav...@chromium.org>:
>>>


 On Thu, Feb 29, 2024 at 1:46 AM 'Sunggook Chue' via blink-dev <
 blin...@chromium.org> wrote:

> Here is an explainer, summary only.
>
>
> https://docs.google.com/document/d/1WV795DHY3Jf2p_htuAKZ9DXUefiGdQs29mCb8vRiHt8/edit?usp=sharing


 Thanks! That's very useful! :)

 What's the feature detection story? How can developers know which 
 formats are supported?
  

>
>
> On Wednesday, February 28, 2024 at 7:53:29 AM UTC-8 
> yoav...@chromium.org wrote:
>
>> On Tue, Feb 27, 2024 at 1:45 AM Mike Taylor  
>> wrote:
>>
>>>
>>> On 2/22/24 9:21 PM, 'Sunggook Chue' via blink-dev wrote:
>>>
>>> Contact emails 
>>>
>>> sun...@microsoft.com 
>>>
>>> dalec...@chromium.com (reviewer and mentor).
>>>
>>> Explainer 
>>>
>>> https://www.w3.org/TR/mediastream-recording/
>>>
>>> That's not an explainer..
>> Could you maybe write a short (inline?) explainer that outlines what 
>> it is that we want to ship, what it would help developers achieve, how 
>> we 
>> envision them using this feature, etc.?
>>  
>>
>>>
>>> Specification 
>>>
>>> https://www.w3.org/TR/mediastream-recording/
>>>
>>> Summary 
>>>
>>> Adds support for muxing audio/video into MP4 containers with 
>>> MediaRecorder.
>>>
>>> Developers can record media format, container, with MP4 of H264 
>>> video and AAC audio codecs in the MediaRecorder API.
>>>
>>>
>>> Blink component 
>>>
>>> Blink::MediaRecording
>>>
>>> TAG review
>>> TAG review status
>>> Risks 
>>>
>>> No Additional risks on existing containers such as webm.
>>>
>>> Interoperability and Compatibility
>>>
>>> This is missing vendor and developer signals - can you add (or 
>>> request) them please?
>>>
>>> Ergonomics 
>>>
>>> N/A
>>>
>>>
>>> Activation 
>>>
>>> Unchallenging to use.
>>>
>>>
>>> Security 
>>>
>>> N/A
>>>
>>>
>>> WebView Application Risks 
>>>
>>> N/A
>>>
>>>
>>> Debuggability 
>>>
>>> Developers can see the API failure on DevTools.
>>>
>>> Is this feature fully tested by web-platform-tests 
>>> 
>>> ? 
>>>
>>> Yes
>>>
>>> Flag name 
>>>
>>> MediaRecorderEnableMp4Muxer
>>>
>>> Tracking bug 
>>>
>>> https://issues.chromium.org/issues/40127044
>>>
>>> Launch bug 
>>>
>>> https://issues.chromium.org/issues/40127044
>>>
>>> Sample links 
>>>
>>> https://webrtc.github.io/samples/src/content/getusermedia/record/
>>>
>>> Estimated milestones 
>>>
>>> Dev Trial on Desktop: 120
>>>
>>>
>>> Link to entry on the Chrome Platform Status 
>>>
>>> https://chromestatus.com/feature/5163469011943424
>>>
>>> Links to previous Intent discussions
>>>
>>> This intent message was generated by Chrome Platform Status 
>>> .
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, 
>>> send an email to blink-dev+...@chromium.org.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1dd6d89b-34f4-4f18-b3e8-c1309d479

Re: [blink-dev] Intent to Ship: Compute Pressure

[Mike Taylor]

On 3/5/24 6:57 AM, Mandy, Arnaud wrote:



Contact emails

kenneth.r.christian...@intel.com, arnaud.ma...@intel.com, 
wei4.w...@intel.com, raphael.kubo.da.co...@intel.com



Explainer

https://github.com/w3c/compute-pressure/blob/main/README.md


Specification

https://www.w3.org/TR/compute-pressure


Summary

The Compute Pressure API offers high-level states that represent the 
pressure on the system. It allows the implementation to use underlying 
hardware/platform metrics to inform the API users of possible stress 
(high CPU load at the moment) on the system and consequently take the 
corrective actions needed.


“Pressure” is a generic term by design – at the moment it is 
calculated based on CPU load, but future plans include using signals 
from temperature and battery status, for example.



https://developer.chrome.com/docs/web-platform/compute-pressure/


Blink component

Blink>PerformanceAPIs>ComputePressure 




Search tags

compute pressure 




TAG review

spec review: https://github.com/w3ctag/design-reviews/issues/795

wide review tracker: https://github.com/w3c/compute-pressure/issues/177


TAG review status

Issues addressed


Chromium Trial Name

ComputePressure


Origin Trial documentation link

https://developer.chrome.com/docs/web-platform/compute-pressure/


Origin Trials history

The first Origin Trial 
 was 
run between M92-94.


The Compute Pressure API was widely redesigned after this OT to 
resemble existing observer-based web APIs and also to provide better 
privacy and security guarantees after discussions with PING.



The second Origin Trial 
 took 
place during M115-M120.
During this origin trial we realized that the full capacity of the API 
couldn’t be tested due to a lack of support for third-party tokens. An 
Origin Trial extension 
 was 
necessary until M123.



Risks


Interoperability and Compatibility


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


Can you add a comment to this issue pointing to this I2S, and any 
relevant changes since the original issue was opened?


/WebKit/: Negative 
(https://lists.webkit.org/pipermail/webkit-dev/2021-May/031845.html) 
This issue has been taken into account: 
https://github.com/w3c/compute-pressure/issues/24


https://github.com/w3c/compute-pressure/issues/24#issuecomment-1022516116 
suggests asking for re-review once issue 24 is settled (at least that's 
my interpretation). Do you know if that ever happened?


/Web developers/: Positive 
(https://github.com/w3c/compute-pressure/issues/14)



/Other signals/:


Security

https://github.com/w3c/compute-pressure/issues/79


WebView application risks

No


Debuggability


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

No,
Windows, Linux, ChromeOs, Mac.

Support on Android (incl. Android WebView) has been deprioritized as 
there is no current way to access the telemetry needed after Android 
11, and the current partners we are engaging with have no need as they 
are using native solutions on Android at this point.



Is this feature fully tested by web-platform-tests

?

Yes
https://wpt.fyi/results/compute-pressure?run_id=5116280230641664

The wpt.fyi results are flaky due to WPT bug 44438 




DevTrial instructions

https://github.com/w3c/compute-pressure/blob/main/HOWTO.md


Flag name on chrome://flags

see https://github.com/w3c/compute-pressure/blob/main/HOWTO.md


Finch feature name

None


Non-finch justification

None


Requires code in //chrome?

False


Tracking bug

https://crbug.com/1067627


Launch bug

https://crbug.com/1173266


Sample links

https://w3c.github.io/compute-pressure/demo


Estimated milestones

OriginTrial desktop extension



123

OriginTrial desktop last



118

OriginTrial desktop first



115

OriginTrial desktop last



94

OriginTrial desktop first



92

DevTrial on desktop



109


Anticipated spec changes

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5597608644968448


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/g/blink-d

[blink-dev] Web-Facing Change PSA: Update LongTask code to use Long animation frames as a backend

[Noam Rosenthal]

Contact emailsnrosent...@chromium.org

Specificationhttps://w3c.github.io/longtasks

Summary

Using the LoAF implementation for reporting longtasks is an implementation
detail, but it would have the following web-observable impact: - we would
stop reporting longtasks for hidden tabs - a few longtask bugs would
disappear, resulting in more reported longtasks Note that this would not
affect the Lighthouse TBT score, that anyway relies on trace events.


Blink componentBlink>PerformanceAPIs


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

This doesn't change the spec, and mostly improves maturity and
maintainability. The main compat risk is with the behavior change that
longtasks in hidden tabs are not reported, however that's anyway a brittle
concept as background documents often undergo all kinds of throttling,
making their reported longtasks not actionable.


*Gecko*: N/A

*WebKit*: N/A

*Web developers*: No signals

*Other signals*:

WebView application risks

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

None


Debuggability

None


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

Is this feature fully tested by web-platform-tests

?Yes

Existing tests:
https://wpt.fyi/results/longtask-timing?label=experimental&label=master&aligned
This would fix some of them.


Flag name on chrome://flagsLongTaskFromLongAnimationFrame

Finch feature nameLongTaskFromLongAnimationFrame

Requires code in //chrome?False

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

Estimated milestones
Shipping on desktop 124
Shipping on Android 124
Shipping on WebView 124

Anticipated spec changes

Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github 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/5146440839200768

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/CAJn%3DMYYtPfYwA6mCFECnRS2f--kzmfUs6%3DZwP-tEkwou53sOLw%40mail.gmail.com.

[blink-dev] Intent to Ship: Compute Pressure

[Mandy, Arnaud]

Contact emails

kenneth.r.christian...@intel.com, 
arnaud.ma...@intel.com, 
wei4.w...@intel.com, 
raphael.kubo.da.co...@intel.com

Explainer

https://github.com/w3c/compute-pressure/blob/main/README.md

Specification

https://www.w3.org/TR/compute-pressure

Summary

The Compute Pressure API offers high-level states that represent the pressure 
on the system. It allows the implementation to use underlying hardware/platform 
metrics to inform the API users of possible stress (high CPU load at the 
moment) on the system and consequently take the corrective actions needed.


“Pressure” is a generic term by design – at the moment it is calculated based 
on CPU load, but future plans include using signals from temperature and 
battery status, for example.


https://developer.chrome.com/docs/web-platform/compute-pressure/

Blink component

Blink>PerformanceAPIs>ComputePressure

Search tags

compute pressure

TAG review

spec review: https://github.com/w3ctag/design-reviews/issues/795

wide review tracker: https://github.com/w3c/compute-pressure/issues/177

TAG review status

Issues addressed

Chromium Trial Name

ComputePressure

Origin Trial documentation link

https://developer.chrome.com/docs/web-platform/compute-pressure/


Origin Trials history

The first Origin 
Trial
 was run between M92-94.


The Compute Pressure API was widely redesigned after this OT to resemble 
existing observer-based web APIs and also to provide better privacy and 
security guarantees after discussions with PING.


The second Origin 
Trial took 
place during M115-M120.
During this origin trial we realized that the full capacity of the API couldn’t 
be tested due to a lack of support for third-party tokens. An Origin Trial 
extension
 was necessary until M123.

Risks
Interoperability and Compatibility


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


WebKit: Negative 
(https://lists.webkit.org/pipermail/webkit-dev/2021-May/031845.html) This issue 
has been taken into account: https://github.com/w3c/compute-pressure/issues/24


Web developers: Positive (https://github.com/w3c/compute-pressure/issues/14)


Other signals:

Security

https://github.com/w3c/compute-pressure/issues/79

WebView application risks

No

Debuggability

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

No,
Windows, Linux, ChromeOs, Mac.


Support on Android (incl. Android WebView) has been deprioritized as there is 
no current way to access the telemetry needed after Android 11, and the current 
partners we are engaging with have no need as they are using native solutions 
on Android at this point.

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

Yes
https://wpt.fyi/results/compute-pressure?run_id=5116280230641664

The wpt.fyi results are flaky due to WPT bug 
44438

DevTrial instructions

https://github.com/w3c/compute-pressure/blob/main/HOWTO.md

Flag name on chrome://flags

see https://github.com/w3c/compute-pressure/blob/main/HOWTO.md

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1067627

Launch bug

https://crbug.com/1173266

Sample links
https://w3c.github.io/compute-pressure/demo

Estimated milestones

OriginTrial desktop extension

123

OriginTrial desktop last

118

OriginTrial desktop first

115

OriginTrial desktop last

94

OriginTrial desktop first

92

DevTrial on desktop

109

Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5597608644968448

Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/LTIRZ24C5Os/m/BPSeJ8y0BwAJ

 Ready for Trial: 
https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/-1ciwdn23J4

Intent to Experiment: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/QfJ4pngu3gc

Intent to Experiment: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/HzVV-sM97T0

Intent to Extend Experiment: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/s83S7wXxa6E/m/AjvsIJxmAQAJ



This intent message was generated by Chrome Platform 
Status.

-- 
You received this message because you are subscribed to the Google Groups 

Re: [blink-dev] Re: Intent to Ship: WebSocketStream

['Thomas Steiner' via blink-dev]

As an additional developer signal showing that developers want this,
there's a polyfill: https://github.com/CarterLi/websocketstream-polyfill.

On Tue, Mar 5, 2024 at 10:10 AM Domenic Denicola 
wrote:

> LGTM2.
>
> I appreciate Adam's careful attention to all portions of the process here,
> and also Alex's probing as to whether we're meeting the developer interest
> portion. Although this would be more of a slam-dunk if we were able to get
> that partner to comment publicly on their experience, I'm willing to take
> Adam's word on it about the private feedback.
>
> Combined with the general positive sentiment, e.g. from Deno (which is a
> server-side runtime, but I think we have a good amount of experience
> showing that people like writing the same code across server and browser),
> and in response to the 2020 article
> ,
> and the repeated "when is this coming" comments in the tracking bug
> ... I think we have enough
> evidence that this will move the web forward in a positive way.
>
> With my API owner hat off, I'm also just happy about this API existing, as
> I think it's generally good for the platform when we go back and take
> older, but still popular technologies, and retrofit them with modern
> capabilities and APIs like backpressure-supporting streams. It makes the
> web feel more cohesive and well-designed.
>
> On Tuesday, March 5, 2024 at 8:46:59 AM UTC+9 Adam Rice wrote:
>
>> Thanks Alex,
>>
>> We have a partner who need backpressure to avoid jank in their app. I've
>> been waiting for them to comment, but it's taking a while.
>>
>> Adam
>>
>> On Thu, 22 Feb 2024 at 01:53, Alex Russell 
>> wrote:
>>
>>> Hey Adam,
>>>
>>> Sorry for the slow follow up. Were there folks beyond the Deno ecosystem
>>> that expressed interest and/or satisfaction with the design? We're need to
>>> make a case in API OWNERS that there's enough developer interest to
>>> surmount the lack of other vendor interest. Are you able to share more?
>>>
>>> Thanks,
>>>
>>> Alex
>>>
>>> On Friday, February 16, 2024 at 12:10:50 AM UTC-8 Adam Rice wrote:
>>>
 Any reason the PR for the spec hasn't landed yet?


 We don't have interest from a second implementer yet. As far as I know,
 Deno doesn't count for this purpose.

 On Fri, 16 Feb 2024 at 03:50, Chris Harrelson 
 wrote:

> Hi,
>
> Any reason the PR for the spec hasn't landed yet?
>
> On Thu, Feb 15, 2024 at 7:54 AM Mike Taylor 
> wrote:
>
>> Thank you - LGTM1
>> On 2/15/24 7:16 AM, Adam Rice wrote:
>>
>> Thanks Mike,
>>
>> I have requested the approvals. Sorry for the delay, I didn't
>> understand the interface.
>>
>> Adam
>>
>> On Thu, 15 Feb 2024 at 01:39, Mike Taylor 
>> wrote:
>>
>>> Hi Adam,
>>>
>>> Would you mind requesting approvals in the chromestatus entry for
>>> the various review gates?
>>> On 2/8/24 1:30 AM, Adam Rice wrote:
>>>
>>> Unfortunately, no partners were ready when we did the OT, so there
>>> was no feedback at all. However, we have subsequently received private
>>> feedback that the API works well.
>>>
>>> On Thu, 8 Feb 2024 at 04:23, Alex Russell 
>>> wrote:
>>>
 Hey Adam,

 Glad to see this moving forward! Has there been a summary somewhere
 of the OT feedback? Also, we noted that the other reviews were marked 
 as
 unstarted in chromestatus; we will likely hold off voting until those 
 are
 in flight.

 Thanks!

 On Tuesday, February 6, 2024 at 1:43:46 PM UTC-8 Adam Rice wrote:

> Contact emails ri...@chromium.org
>
> Explainer
> https://github.com/ricea/websocketstream-explainer/blob/master/README.md
>
> https://docs.google.com/document/d/1XuxEshh5VYBYm1qRVKordTamCOsR-uGQBCYFcHXP4L0/edit
>
> Specification https://github.com/whatwg/websockets/pull/48
>
> Design docs
> https://web.dev/websocketstream/
>
> Summary
>
> The WebSocket API provides a JavaScript interface to the RFC6455
> WebSocket protocol. While it has served well, it is awkward from an
> ergonomics perspective and is missing the important feature of
> backpressure. The intent of the WebSocketStream API is to resolve 
> these
> deficiencies by integrating WHATWG Streams with the WebSocket API.
>
>
> Blink component Blink>Network>WebSockets
> 
>
> Search tags WebSocket
> , Streams
> 

Re: [blink-dev] Re: Intent to Ship: WebSocketStream

[Domenic Denicola]

LGTM2.

I appreciate Adam's careful attention to all portions of the process here, 
and also Alex's probing as to whether we're meeting the developer interest 
portion. Although this would be more of a slam-dunk if we were able to get 
that partner to comment publicly on their experience, I'm willing to take 
Adam's word on it about the private feedback.

Combined with the general positive sentiment, e.g. from Deno (which is a 
server-side runtime, but I think we have a good amount of experience 
showing that people like writing the same code across server and browser), 
and in response to the 2020 article 
,
 
and the repeated "when is this coming" comments in the tracking bug 
... I think we have enough 
evidence that this will move the web forward in a positive way.

With my API owner hat off, I'm also just happy about this API existing, as 
I think it's generally good for the platform when we go back and take 
older, but still popular technologies, and retrofit them with modern 
capabilities and APIs like backpressure-supporting streams. It makes the 
web feel more cohesive and well-designed.

On Tuesday, March 5, 2024 at 8:46:59 AM UTC+9 Adam Rice wrote:

> Thanks Alex,
>
> We have a partner who need backpressure to avoid jank in their app. I've 
> been waiting for them to comment, but it's taking a while.
>
> Adam
>
> On Thu, 22 Feb 2024 at 01:53, Alex Russell  
> wrote:
>
>> Hey Adam,
>>
>> Sorry for the slow follow up. Were there folks beyond the Deno ecosystem 
>> that expressed interest and/or satisfaction with the design? We're need to 
>> make a case in API OWNERS that there's enough developer interest to 
>> surmount the lack of other vendor interest. Are you able to share more?
>>
>> Thanks,
>>
>> Alex
>>
>> On Friday, February 16, 2024 at 12:10:50 AM UTC-8 Adam Rice wrote:
>>
>>> Any reason the PR for the spec hasn't landed yet?
>>>
>>>
>>> We don't have interest from a second implementer yet. As far as I know, 
>>> Deno doesn't count for this purpose.
>>>
>>> On Fri, 16 Feb 2024 at 03:50, Chris Harrelson  
>>> wrote:
>>>
 Hi,

 Any reason the PR for the spec hasn't landed yet?

 On Thu, Feb 15, 2024 at 7:54 AM Mike Taylor  
 wrote:

> Thank you - LGTM1
> On 2/15/24 7:16 AM, Adam Rice wrote:
>
> Thanks Mike, 
>
> I have requested the approvals. Sorry for the delay, I didn't 
> understand the interface.
>
> Adam
>
> On Thu, 15 Feb 2024 at 01:39, Mike Taylor  
> wrote:
>
>> Hi Adam,
>>
>> Would you mind requesting approvals in the chromestatus entry for the 
>> various review gates?
>> On 2/8/24 1:30 AM, Adam Rice wrote:
>>
>> Unfortunately, no partners were ready when we did the OT, so there 
>> was no feedback at all. However, we have subsequently received private 
>> feedback that the API works well.
>>
>> On Thu, 8 Feb 2024 at 04:23, Alex Russell  
>> wrote:
>>
>>> Hey Adam, 
>>>
>>> Glad to see this moving forward! Has there been a summary somewhere 
>>> of the OT feedback? Also, we noted that the other reviews were marked 
>>> as 
>>> unstarted in chromestatus; we will likely hold off voting until those 
>>> are 
>>> in flight.
>>>
>>> Thanks!
>>>
>>> On Tuesday, February 6, 2024 at 1:43:46 PM UTC-8 Adam Rice wrote:
>>>
 Contact emails ri...@chromium.org

 Explainer 
 https://github.com/ricea/websocketstream-explainer/blob/master/README.md

 https://docs.google.com/document/d/1XuxEshh5VYBYm1qRVKordTamCOsR-uGQBCYFcHXP4L0/edit

 Specification https://github.com/whatwg/websockets/pull/48

 Design docs 
 https://web.dev/websocketstream/

 Summary 

 The WebSocket API provides a JavaScript interface to the RFC6455 
 WebSocket protocol. While it has served well, it is awkward from an 
 ergonomics perspective and is missing the important feature of 
 backpressure. The intent of the WebSocketStream API is to resolve 
 these 
 deficiencies by integrating WHATWG Streams with the WebSocket API.


 Blink component Blink>Network>WebSockets 
 

 Search tags WebSocket 
 , Streams 
 , ReadableStream 
 , 
 WritableStream 
 

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

 TAG review status Pend