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

[TAMURA, Kent]

LGTM1.
Firefox and Safari statuses are strong signals, and the compatibility risk
looks very low.


On Thu, May 23, 2024 at 11:07 AM Shuangshuang Zhou <
shuangshuang.z...@intel.com> wrote:

> Hi Dan, for your concern that Firefox is still failing the WPTs at
> https://wpt.fyi/results/selection/onselectionchange-on-distinct-text-controls.html,
> that might be another issue. Let me make more explanation.
>
> Actually, the final goal of w3c modifys the spec of selectionchange event
> is to avoid firing duplicated selectionchange event which are not executed
> yet on the same element(as Rniwa commented in his comment
> ).
> Then in WebKit/WebCore, Rniwa submitted 2 CLs to achieve this ieda. The
> first CL in WebKit is 276238@main ,
> and in this CL they just modified the logic to fire selectionchange event
> on input/textarea for the first step. Then the second CL in WebKit is
> 276388@main , which finally
> avoided to fire duplicated selectionchange events according to the latest
> spec on firing selectionchange event
> .
>
> So for this feature in Blink here , we also want to take 2 steps like
> WebKit does that in the first CL we change to fire on input/textarea and
> then sovle the duplicated events in the second CL. And those tests are
> already modified to what both CLs are merged. So in the above test of
> onselectionchange-on-distinct-text-controls.html, chrome and firefox should
> be failed because only Safari has landed 2 CLs to avoid duplicated
> selectionchange events. Or in other words, firefox might already dispatch
> selectionchange event on elements but doesn't have the logic to avoid to
> fire scheduled-but-not-executed events.
>
> For WebKit, currently the two CLs are both landed in Safari Technology
> Preview 192(link
> ),
> but it might need some time to ship in Safari because Safari is updated
> within OS updates.
> For the status in FireFox, I'll double-check and confirm with Tkent(one
> reviewer of my first CL).
>
> Thanks,
> Shuangshuang
>
> On Thursday, May 23, 2024 at 9:29:59 AM UTC+8 mike...@chromium.org wrote:
>
>> Yes, agree. Can we please request a position from Mozilla at
>> https://github.com/mozilla/standards-positions/issues/new?
>> On 5/22/24 6:43 PM, 'Daniel Clark' via blink-dev wrote:
>>
>> Yeah, that’s what I was trying to get at – the Intent implies that Gecko
>> has also shipped the breaking change but it seems that might not be the
>> case.
>>
>>
>>
>> If not, we should send a Request for Position to figure out whether there
>> would be cross-browser alignment on shipping this.
>>
>>
>>
>> -- Dan
>>
>>
>>
>> *From:* Olli Pettay 
>> *Sent:* Wednesday, May 22, 2024 9:53 AM
>> *To:* blink-dev 
>> *Cc:* Daniel Clark ; Shuangshuang Zhou
>> 
>> *Subject:* Re: [blink-dev] Intent to Ship: Dispatch selectionchange
>> event per element
>>
>>
>>
>> You don't often get email from ope...@mozilla.com. Learn why this is
>> important 
>>
>> I think it is because of this rather surprising non-backwards compatible
>> recent change.
>>
>> On Wednesday, May 22, 2024 at 7:28:45 PM UTC+3 Daniel Clark wrote:
>>
>> The Gecko status is marked as Shipped/Shipping and the Interop/Compat
>> section mentions Firefox having shipped this, but Firefox is still failing
>> the WPTs at
>> https://wpt.fyi/results/selection/onselectionchange-on-distinct-text-controls.html
>> .
>>
>> Can you help me understand the discrepancy there?
>>
>>
>>
>> Thanks,
>>
>> Dan
>>
>>
>>
>> *From:* blin...@chromium.org  *On Behalf Of 
>> *Shuangshuang
>> Zhou
>> *Sent:* Tuesday, May 21, 2024 10:24 PM
>> *To:* blink-dev 
>> *Subject:* [blink-dev] Intent to Ship: Dispatch selectionchange event
>> per element
>>
>>
>>
>> You don't often get email from shuangsh...@intel.com. Learn why this is
>> important 
>>
>> *Contact emails*shuangsh...@intel.com
>>
>> *Explainer*None
>>
>> *Specification*https://w3c.github.io/selection-api/#selectionchange-event
>>
>> *Summary*
>>
>> Dispatches selectionchange event per element when this
>> element(input/textarea) provides a text selection or its selection changes.
>> This is to match the latest specification of selectionchange event. This
>> also matches Safari behavior.
>>
>>
>>
>> *Blink component*Blink>Editing>Selection
>> 
>>
>> *TAG review*None
>>
>> *TAG review status*Issues addressed
>>
>> *Risks*
>>
>>
>>
>> *Interoperability and Compatibility*
>>
>> Interoperability risk is low because Firefox and Safari have shipped this
>> according to the specification. Compatibility risk is low 

Re: [blink-dev] Intent to Ship: Unrestricted WebUSB (available only to Isolated Web Apps)

['Ajay Rahatekar' via blink-dev]

Ty, Mike. Reviews have been requested. 

On Wednesday, May 22, 2024 at 6:31:11 PM UTC-7 mike...@chromium.org wrote:

> Could you please request the various Privacy, Security, Enterprise, etc. 
> review gates in your chromestatus entry?
> On 5/22/24 1:08 PM, 'Ajay Rahatekar' via blink-dev wrote:
>
> Contact emails 
>
> mattre...@chromium.org
>
> Specification 
>
> https://wicg.github.io/webusb/#permissions-policy
>
> Summary 
>
> Enables trusted applications to bypass security restrictions in the WebUSB 
> API.
>
> The WebUSB specification defines a blocklist of vulnerable devices and a 
> table of protected interfaces classes that are blocked from access through 
> WebUSB. With this feature, Isolated Web Apps (
> https://github.com/WICG/isolated-web-apps) with permission to access the 
> "usb-unrestricted" Permission Policy feature will be allowed to access 
> blocklisted devices and protected interface classes.
>
>
> Blink component 
>
> Blink>USB 
> 
>
> Search tags 
>
> usb , webusb 
> , unrestricted 
> 
>
> TAG review 
>
> None
>
> TAG review status 
>
> Not applicable
>
> Risks 
>
> Interoperability and Compatibility 
>
> WebUSB is only implemented in Chromium-based browsers.
>
>
> Gecko: No signal
>
> WebKit: No signal
>
> Web developers: No signals
>
> Other signals:
>
> WebView application risks 
>
> Does this intent deprecate or change behavior of existing APIs, such that 
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Debuggability 
>
> None
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, ChromeOS, Android, and Android WebView)? 
>
> No
>
> This feature is not available on Android because Isolated Web Apps are not 
> supported in Chrome for Android.
>
>
> Is this feature fully tested by web-platform-tests 
> 
> ? 
>
> No, this feature is only available in Isolated Web Apps which are not yet 
> supported for web platform tests.
>
> Flag name on chrome://flags 
>
> chrome://flags/#enable-unrestricted-usb
>
> Finch feature name 
>
> UnrestrictedUsb
>
> Requires code in //chrome? 
>
> False
>
> Tracking bug 
>
> https://crbug.com/40783010
>
> Launch bug 
>
> https://launch.corp.google.com/launch/4281834
>
> Estimated milestones 
>
> Shipping on desktop
>
> 127
>
> Anticipated spec changes 
>
> Open questions about a feature may be a source of future web compat or 
> interop issues. Please list open issues (e.g. links to known github issues 
> in the project for the feature specification) whose resolution may 
> introduce web compat/interop risk (e.g., changing to naming or structure of 
> the API in a non-backward-compatible way).
>
> None
>
> Link to entry on the Chrome Platform Status 
>
> https://chromestatus.com/feature/5106506475503616?gate=6251287998103552
>
> Links to previous Intent discussions 
>
> Intent to prototype: 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHB%2BDAgOvR6ggk64OaEGkfJE%2BOsMh0jKjORBZ_LyN2Pdad%3Dg3w%40mail.gmail.com
>
> This intent message was generated by Chrome Platform Status 
> .
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to blink-dev+...@chromium.org.
> To view this discussion on the web visit 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHB%2BDAigp8dfbrCYbzs7A9W03%2BpCzZmu58p90tptrTtXh7bRrg%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/ba08a338-a3f4-488f-877a-1d8211f362d6n%40chromium.org.

[blink-dev] Intent to Ship: SkipAd media session action

['Jiaming Cheng' via blink-dev]

Updated the subject of this thread.

Key links:
ChromeStatus:
https://chromestatus.com/feature/4749278882824192?gate=4775000754618368
TAG: https://github.com/w3ctag/design-reviews/issues/957
Mozilla: https://github.com/mozilla/standards-positions/issues/1026
Webkit: https://github.com/WebKit/standards-positions/issues/350

On Thu, May 23, 2024 at 1:13 PM Chris Harrelson 
wrote:

>
>
> On Thu, May 23, 2024 at 1:10 PM Jiaming Cheng  wrote:
>
>> Hi Chris,
>>
>> We are looking to ship this feature to Stable. We have reused an existing
>> chromestatus (
>> https://chromestatus.com/feature/4749278882824192?gate=4775000754618368)
>> and updated almost every section, including filling all the "Prepare to
>> Ship" section. This email was automatically generated by the "API Owners
>> Review" step in that section after each individual section was approved. I
>> have quoted the previous email thread in this email for additional context.
>>
>
> Ok. Please then start a new thread (or reply with a change of subject) to
> "Intent to ship: Skip Ad in Picture-in-Picture window"
>
>
>>
>> If you have any further questions or concerns, please let us know.
>>
>> Thanks,
>> Jiaming
>>
>> On Thu, May 23, 2024 at 12:29 PM Chris Harrelson 
>> wrote:
>>
>>> Are you looking to ship this feature or just experiment? If you're
>>> looking to ship please send a new email with a corrected subject and
>>> contents, and request API owners review on chromestatus.com.
>>>
>>> On Wed, May 22, 2024 at 7:43 AM Chris Harrelson 
>>> wrote:
>>>
 I went ahead and marked the review as started on chromestatus.com.

 On Wed, May 22, 2024 at 7:36 AM Daniel Bratell 
 wrote:

> Unfortunately it doesn't show up in the API Owner UI/ToDo list and I
> can't directly see how to make it appear. jrobbins, is there anything
> strange with this one? It is very old so it might be different from
> anything done the last couple of years.
>
> /Daniel
> On 2024-05-17 22:39, 'Jiaming Cheng' via blink-dev wrote:
>
> Hi team,
>
> This feature was initially proposed and implemented 4 years ago but
> remained disabled due to a lack of practical use cases. Given our
> team's (chromeOS UI team) plan to use this SkipAd action in our upcoming
> project, we are now resending this intent email for LGTMs. Please let me
> know if you have any questions :]
>
> TAG: https://github.com/w3ctag/design-reviews/issues/957
> Mozilla: https://github.com/mozilla/standards-positions/issues/1026
> Webkit: https://github.com/WebKit/standards-positions/issues/350
>
> Below are the auto generated intent content:
> Contact emailsfbeauf...@chromium.org, mlamo...@chromium.org,
> jiami...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://wicg.github.io/picture-in-picture/#media-session
>
> Design docs
>
> https://developers.google.com/web/updates/2019/02/chrome-73-media-updates#skipad
> https://github.com/WICG/mediasession/pull/203
>
> Summary
>
> Support the SkipAd media session action. This skipad action allows
> Chrome to show a button in the system media controls or in the PiP window.
>
>
> Blink componentBlink>Media>PictureInPicture
> 
>
> TAG review:
> https://github.com/w3ctag/design-reviews/issues/957
>
> TAG review statusPending
>
> Chromium Trial NameSkipAd
>
> Link to origin trial feedback summary
> https://github.com/WICG/picture-in-picture/issues
>
> Origin Trial documentation link
> https://wicg.github.io/mediasession/#dom-mediasessionaction-skipad
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: https://github.com/mozilla/standards-positions/issues/1026
>
> *WebKit*: Positive (
> https://github.com/WICG/mediasession/pull/203#issuecomment-432529816)
> And a new one created:
> https://github.com/WebKit/standards-positions/issues/350
>
> *Web developers*: Positive
>
> *Other signals*:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such
> that it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Debuggability
>
> None
>
>
> Will this feature be supported on all six Blink platforms (Windows,
> Mac, Linux, ChromeOS, Android, and Android WebView)?No
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> Flag name on chrome://flagsNone
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bug
> 

Re: [blink-dev] Intent to Ship: Third-party Cookie Grace Period Opt-Out

[Yoav Weiss (@Shopify)]

On Thu, May 16, 2024 at 4:15 PM Anton Maliev  wrote:

> > Will developers have a way of knowing if the current site (where they
> may see breakage metrics) is opted-out of the grace period?
>
> Google is planning to build a site dashboard where developers can check on
> the status of their grace period and opt-out values. In the interim, Chrome
> DevTools shows an Issue for third-party cookies which are allowed due to
> the grace period - this can be used to validate whether the grace period is
> active for that particular client.
>
>
While that's potentially useful, that's not what I had in mind.
If a site opt-outs of the grace period, that may impact 3Ps that the site
embeds.
Those 3Ps (if they are not ready for it) are likely to notice some drop in
their functionality or conversion, but they'd need a way of attributing
that to the lack of 3P cookies.

At the same time, while writing this, I was reminded of
navigator.cookieEnabled
.
Do I understand correctly that it would indicate the lack of 3P cookie
support in these cases?



> > Do you have a rough estimate on the length of the grace period? (I'm
> guessing this will not be relevant after it)
>
> That's correct, a site will no longer need an opt-out file after it is
> removed from the grace period. Each grace period entry has its own
> expiration date, depending on when the site applied for the deprecation
> trial. We will need to assess the demand for new sites onboarding to the
> trial before we can give an estimate on how long we will continue to
> support grace periods overall.
>
> On Thursday, May 16, 2024 at 3:56:15 AM UTC-4 Yoav Weiss wrote:
>
>> This is an odd one, but I agree that it's a web exposed feature and hence
>> should go through the blink process. Thanks for sending this!
>>
>>
>> On Tue, May 14, 2024 at 11:15 PM Anton Maliev 
>> wrote:
>>
>>> Contact emails
>>>
>>> amal...@chromium.org
>>>
>>> njeu...@chromium.org
>>>
>>> wanderv...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/explainers-by-googlers/3pcd-grace-period-opt-out
>>>
>>> Specification
>>>
>>> Well-known resource specification:
>>> https://github.com/explainers-by-googlers/3pcd-grace-period-opt-out/blob/main/well-known-specification.md
>>>
>>> Summary
>>>
>>> This proposal details a new mechanism for site developers to conduct a
>>> self-service staged opt-out of their third-party cookie phaseout grace
>>> period. This is intended primarily for Chrome’s active trials for
>>> third-party cookie deprecation - one for top-level sites
>>> 
>>> and one for embedded sites
>>> .
>>> When a site is approved for one of these trials, they are added to a
>>> short-term grace period which mitigates breakage until the token is
>>> launched.  Sites may also use this opt-out to test long term solutions.
>>>
>>> Each site on the trial will specify their desired opt-out percentage in
>>> a new resource in their .well-known directory
>>> , specified here
>>> .
>>> Google will implement server infrastructure to fetch and update these
>>> values on a schedule, and assign clients randomly to cohorts matching this
>>> percentage. These cohorts persist for a client up until clearing site
>>> storage or reinstalling the browser.
>>>
>>
>>
>> Will developers have a way of knowing if the current site (where they may
>> see breakage metrics) is opted-out of the grace period?
>>
>>
>>
>>>
>>> Blink component
>>>
>>> Privacy 
>>>
>>> TAG review
>>>
>>> N/A
>>>
>>> TAG review status
>>>
>>> N/A
>>>
>>> Risks
>>>
>>> There aren’t inherent security implications for fetching external
>>> resources using server-side infrastructure, but there is a risk of fetching
>>> bad data, which our implementation addresses.
>>>
>>> There are also privacy implications for randomly assigning clients to
>>> cohorts, which we mitigate by clearing cohorts on site data deletion. There
>>> is also a risk that the fetching system fails or that a site loses access
>>> to its .well-known resource, both cases which we have planned mitigations
>>> for.
>>>
>>> Interoperability and Compatibility
>>>
>>> The third-party cookie deprecation trials are a Chrome feature, so these
>>> new well-known resources will only be fetched by the Chrome browser. The
>>> new resource will be distinct and will not interfere with any existing
>>> resources used by other browsers or features.
>>>
>>
>> Beyond that, I think that the fact that this is a short-lived capability
>> also significantly reduces risk.
>> 

Re: [blink-dev] Intent to Implement and Experiment: Skip Ad in Picture-in-Picture window

[Chris Harrelson]

On Thu, May 23, 2024 at 1:10 PM Jiaming Cheng  wrote:

> Hi Chris,
>
> We are looking to ship this feature to Stable. We have reused an existing
> chromestatus (
> https://chromestatus.com/feature/4749278882824192?gate=4775000754618368)
> and updated almost every section, including filling all the "Prepare to
> Ship" section. This email was automatically generated by the "API Owners
> Review" step in that section after each individual section was approved. I
> have quoted the previous email thread in this email for additional context.
>

Ok. Please then start a new thread (or reply with a change of subject) to
"Intent to ship: Skip Ad in Picture-in-Picture window"


>
> If you have any further questions or concerns, please let us know.
>
> Thanks,
> Jiaming
>
> On Thu, May 23, 2024 at 12:29 PM Chris Harrelson 
> wrote:
>
>> Are you looking to ship this feature or just experiment? If you're
>> looking to ship please send a new email with a corrected subject and
>> contents, and request API owners review on chromestatus.com.
>>
>> On Wed, May 22, 2024 at 7:43 AM Chris Harrelson 
>> wrote:
>>
>>> I went ahead and marked the review as started on chromestatus.com.
>>>
>>> On Wed, May 22, 2024 at 7:36 AM Daniel Bratell 
>>> wrote:
>>>
 Unfortunately it doesn't show up in the API Owner UI/ToDo list and I
 can't directly see how to make it appear. jrobbins, is there anything
 strange with this one? It is very old so it might be different from
 anything done the last couple of years.

 /Daniel
 On 2024-05-17 22:39, 'Jiaming Cheng' via blink-dev wrote:

 Hi team,

 This feature was initially proposed and implemented 4 years ago but
 remained disabled due to a lack of practical use cases. Given our
 team's (chromeOS UI team) plan to use this SkipAd action in our upcoming
 project, we are now resending this intent email for LGTMs. Please let me
 know if you have any questions :]

 TAG: https://github.com/w3ctag/design-reviews/issues/957
 Mozilla: https://github.com/mozilla/standards-positions/issues/1026
 Webkit: https://github.com/WebKit/standards-positions/issues/350

 Below are the auto generated intent content:
 Contact emailsfbeauf...@chromium.org, mlamo...@chromium.org,
 jiami...@chromium.org

 ExplainerNone

 Specificationhttps://wicg.github.io/picture-in-picture/#media-session

 Design docs

 https://developers.google.com/web/updates/2019/02/chrome-73-media-updates#skipad
 https://github.com/WICG/mediasession/pull/203

 Summary

 Support the SkipAd media session action. This skipad action allows
 Chrome to show a button in the system media controls or in the PiP window.


 Blink componentBlink>Media>PictureInPicture
 

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

 TAG review statusPending

 Chromium Trial NameSkipAd

 Link to origin trial feedback summary
 https://github.com/WICG/picture-in-picture/issues

 Origin Trial documentation link
 https://wicg.github.io/mediasession/#dom-mediasessionaction-skipad

 Risks


 Interoperability and Compatibility

 None


 *Gecko*: https://github.com/mozilla/standards-positions/issues/1026

 *WebKit*: Positive (
 https://github.com/WICG/mediasession/pull/203#issuecomment-432529816)
 And a new one created:
 https://github.com/WebKit/standards-positions/issues/350

 *Web developers*: Positive

 *Other signals*:

 WebView application risks

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

 None


 Debuggability

 None


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

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

 Flag name on chrome://flagsNone

 Finch feature nameNone

 Non-finch justificationNone

 Requires code in //chrome?False

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

 Sample links
 https://googlechrome.github.io/samples/picture-in-picture/skip-ad.html

 Estimated milestones
 Shipping on desktop
 127
 Origin trial desktop first
 73
 Origin trial desktop last
 74

 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 

Re: [blink-dev] Intent to Implement and Experiment: Skip Ad in Picture-in-Picture window

['Jiaming Cheng' via blink-dev]

Hi Chris,

We are looking to ship this feature to Stable. We have reused an existing
chromestatus (
https://chromestatus.com/feature/4749278882824192?gate=4775000754618368)
and updated almost every section, including filling all the "Prepare to
Ship" section. This email was automatically generated by the "API Owners
Review" step in that section after each individual section was approved. I
have quoted the previous email thread in this email for additional context.

If you have any further questions or concerns, please let us know.

Thanks,
Jiaming

On Thu, May 23, 2024 at 12:29 PM Chris Harrelson 
wrote:

> Are you looking to ship this feature or just experiment? If you're looking
> to ship please send a new email with a corrected subject and contents, and
> request API owners review on chromestatus.com.
>
> On Wed, May 22, 2024 at 7:43 AM Chris Harrelson 
> wrote:
>
>> I went ahead and marked the review as started on chromestatus.com.
>>
>> On Wed, May 22, 2024 at 7:36 AM Daniel Bratell 
>> wrote:
>>
>>> Unfortunately it doesn't show up in the API Owner UI/ToDo list and I
>>> can't directly see how to make it appear. jrobbins, is there anything
>>> strange with this one? It is very old so it might be different from
>>> anything done the last couple of years.
>>>
>>> /Daniel
>>> On 2024-05-17 22:39, 'Jiaming Cheng' via blink-dev wrote:
>>>
>>> Hi team,
>>>
>>> This feature was initially proposed and implemented 4 years ago but
>>> remained disabled due to a lack of practical use cases. Given our
>>> team's (chromeOS UI team) plan to use this SkipAd action in our upcoming
>>> project, we are now resending this intent email for LGTMs. Please let me
>>> know if you have any questions :]
>>>
>>> TAG: https://github.com/w3ctag/design-reviews/issues/957
>>> Mozilla: https://github.com/mozilla/standards-positions/issues/1026
>>> Webkit: https://github.com/WebKit/standards-positions/issues/350
>>>
>>> Below are the auto generated intent content:
>>> Contact emailsfbeauf...@chromium.org, mlamo...@chromium.org,
>>> jiami...@chromium.org
>>>
>>> ExplainerNone
>>>
>>> Specificationhttps://wicg.github.io/picture-in-picture/#media-session
>>>
>>> Design docs
>>>
>>> https://developers.google.com/web/updates/2019/02/chrome-73-media-updates#skipad
>>> https://github.com/WICG/mediasession/pull/203
>>>
>>> Summary
>>>
>>> Support the SkipAd media session action. This skipad action allows
>>> Chrome to show a button in the system media controls or in the PiP window.
>>>
>>>
>>> Blink componentBlink>Media>PictureInPicture
>>> 
>>>
>>> TAG review:
>>> https://github.com/w3ctag/design-reviews/issues/957
>>>
>>> TAG review statusPending
>>>
>>> Chromium Trial NameSkipAd
>>>
>>> Link to origin trial feedback summary
>>> https://github.com/WICG/picture-in-picture/issues
>>>
>>> Origin Trial documentation link
>>> https://wicg.github.io/mediasession/#dom-mediasessionaction-skipad
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> None
>>>
>>>
>>> *Gecko*: https://github.com/mozilla/standards-positions/issues/1026
>>>
>>> *WebKit*: Positive (
>>> https://github.com/WICG/mediasession/pull/203#issuecomment-432529816)
>>> And a new one created:
>>> https://github.com/WebKit/standards-positions/issues/350
>>>
>>> *Web developers*: Positive
>>>
>>> *Other signals*:
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> None
>>>
>>>
>>> Debuggability
>>>
>>> None
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, ChromeOS, Android, and Android WebView)?No
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?No
>>>
>>> Flag name on chrome://flagsNone
>>>
>>> Finch feature nameNone
>>>
>>> Non-finch justificationNone
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=910436
>>>
>>> Sample links
>>> https://googlechrome.github.io/samples/picture-in-picture/skip-ad.html
>>>
>>> Estimated milestones
>>> Shipping on desktop
>>> 127
>>> Origin trial desktop first
>>> 73
>>> Origin trial desktop last
>>> 74
>>>
>>> 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/4749278882824192?gate=4775000754618368
>>>
>>> Links to previous Intent discussionsIntent to 

Re: [blink-dev] Intent to Ship: Third-party Cookie Grace Period Opt-Out

[Chris Harrelson]

LGTM1

On Thu, May 23, 2024 at 11:53 AM 'Jonathan Njeunje' via blink-dev <
blink-dev@chromium.org> wrote:

> In anticipation of approval here, we have a small tool to help people
> validate their well-known files accessible at
> https://3pcd-mitigations-wrv.glitch.me.
>
> On Thursday, May 16, 2024 at 1:19:23 PM UTC-4 Anton Maliev wrote:
>
>> > Each grace period entry has its own expiration date, depending on when
>> the site applied for the deprecation trial.
>>
>> To clarify, the currently published expiration date is June 30, but we
>> are assessing how grace periods will be used after that date. This feature,
>> though, is intended to help sites migrate off the grace period in a safe
>> way.
>>
>> On Thursday, May 16, 2024 at 10:15:20 AM UTC-4 Anton Maliev wrote:
>>
>>> > Will developers have a way of knowing if the current site (where they
>>> may see breakage metrics) is opted-out of the grace period?
>>>
>>> Google is planning to build a site dashboard where developers can check
>>> on the status of their grace period and opt-out values. In the interim,
>>> Chrome DevTools shows an Issue for third-party cookies which are allowed
>>> due to the grace period - this can be used to validate whether the grace
>>> period is active for that particular client.
>>>
>>> > Do you have a rough estimate on the length of the grace period? (I'm
>>> guessing this will not be relevant after it)
>>>
>>> That's correct, a site will no longer need an opt-out file after it is
>>> removed from the grace period. Each grace period entry has its own
>>> expiration date, depending on when the site applied for the deprecation
>>> trial. We will need to assess the demand for new sites onboarding to the
>>> trial before we can give an estimate on how long we will continue to
>>> support grace periods overall.
>>>
>>> On Thursday, May 16, 2024 at 3:56:15 AM UTC-4 Yoav Weiss wrote:
>>>
 This is an odd one, but I agree that it's a web exposed feature and
 hence should go through the blink process. Thanks for sending this!


 On Tue, May 14, 2024 at 11:15 PM Anton Maliev 
 wrote:

> Contact emails
>
> ama...@chromium.org
>
> nje...@chromium.org
>
> wande...@chromium.org
>
> Explainer
>
> https://github.com/explainers-by-googlers/3pcd-grace-period-opt-out
>
> Specification
>
> Well-known resource specification:
> https://github.com/explainers-by-googlers/3pcd-grace-period-opt-out/blob/main/well-known-specification.md
>
> Summary
>
> This proposal details a new mechanism for site developers to conduct a
> self-service staged opt-out of their third-party cookie phaseout grace
> period. This is intended primarily for Chrome’s active trials for
> third-party cookie deprecation - one for top-level sites
> 
> and one for embedded sites
> .
> When a site is approved for one of these trials, they are added to a
> short-term grace period which mitigates breakage until the token is
> launched.  Sites may also use this opt-out to test long term solutions.
>
> Each site on the trial will specify their desired opt-out percentage
> in a new resource in their .well-known directory
> , specified here
> .
> Google will implement server infrastructure to fetch and update these
> values on a schedule, and assign clients randomly to cohorts matching this
> percentage. These cohorts persist for a client up until clearing site
> storage or reinstalling the browser.
>


 Will developers have a way of knowing if the current site (where they
 may see breakage metrics) is opted-out of the grace period?



>
> Blink component
>
> Privacy 
>
> TAG review
>
> N/A
>
> TAG review status
>
> N/A
>
> Risks
>
> There aren’t inherent security implications for fetching external
> resources using server-side infrastructure, but there is a risk of 
> fetching
> bad data, which our implementation addresses.
>
> There are also privacy implications for randomly assigning clients to
> cohorts, which we mitigate by clearing cohorts on site data deletion. 
> There
> is also a risk that the fetching system fails or that a site loses access
> to its .well-known resource, both cases which we have planned mitigations
> for.
>
> Interoperability and Compatibility
>
> The third-party cookie deprecation trials are a Chrome feature, so
> these 

Re: [blink-dev] Intent to Implement and Experiment: Skip Ad in Picture-in-Picture window

[Chris Harrelson]

Are you looking to ship this feature or just experiment? If you're looking
to ship please send a new email with a corrected subject and contents, and
request API owners review on chromestatus.com.

On Wed, May 22, 2024 at 7:43 AM Chris Harrelson 
wrote:

> I went ahead and marked the review as started on chromestatus.com.
>
> On Wed, May 22, 2024 at 7:36 AM Daniel Bratell  wrote:
>
>> Unfortunately it doesn't show up in the API Owner UI/ToDo list and I
>> can't directly see how to make it appear. jrobbins, is there anything
>> strange with this one? It is very old so it might be different from
>> anything done the last couple of years.
>>
>> /Daniel
>> On 2024-05-17 22:39, 'Jiaming Cheng' via blink-dev wrote:
>>
>> Hi team,
>>
>> This feature was initially proposed and implemented 4 years ago but
>> remained disabled due to a lack of practical use cases. Given our team's
>> (chromeOS UI team) plan to use this SkipAd action in our upcoming project,
>> we are now resending this intent email for LGTMs. Please let me know if you
>> have any questions :]
>>
>> TAG: https://github.com/w3ctag/design-reviews/issues/957
>> Mozilla: https://github.com/mozilla/standards-positions/issues/1026
>> Webkit: https://github.com/WebKit/standards-positions/issues/350
>>
>> Below are the auto generated intent content:
>> Contact emailsfbeauf...@chromium.org, mlamo...@chromium.org,
>> jiami...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://wicg.github.io/picture-in-picture/#media-session
>>
>> Design docs
>>
>> https://developers.google.com/web/updates/2019/02/chrome-73-media-updates#skipad
>> https://github.com/WICG/mediasession/pull/203
>>
>> Summary
>>
>> Support the SkipAd media session action. This skipad action allows Chrome
>> to show a button in the system media controls or in the PiP window.
>>
>>
>> Blink componentBlink>Media>PictureInPicture
>> 
>>
>> TAG review:
>> https://github.com/w3ctag/design-reviews/issues/957
>>
>> TAG review statusPending
>>
>> Chromium Trial NameSkipAd
>>
>> Link to origin trial feedback summary
>> https://github.com/WICG/picture-in-picture/issues
>>
>> Origin Trial documentation link
>> https://wicg.github.io/mediasession/#dom-mediasessionaction-skipad
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> None
>>
>>
>> *Gecko*: https://github.com/mozilla/standards-positions/issues/1026
>>
>> *WebKit*: Positive (
>> https://github.com/WICG/mediasession/pull/203#issuecomment-432529816)
>> And a new one created:
>> https://github.com/WebKit/standards-positions/issues/350
>>
>> *Web developers*: Positive
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None
>>
>>
>> Debuggability
>>
>> None
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, ChromeOS, Android, and Android WebView)?No
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?No
>>
>> Flag name on chrome://flagsNone
>>
>> Finch feature nameNone
>>
>> Non-finch justificationNone
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=910436
>>
>> Sample links
>> https://googlechrome.github.io/samples/picture-in-picture/skip-ad.html
>>
>> Estimated milestones
>> Shipping on desktop
>> 127
>> Origin trial desktop first
>> 73
>> Origin trial desktop last
>> 74
>>
>> 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/4749278882824192?gate=4775000754618368
>>
>> Links to previous Intent discussionsIntent to Experiment:
>> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/l6sW0G4jzhE
>> On Sunday, February 10, 2019 at 2:08:11 AM UTC-8 Yoav Weiss wrote:
>>
>>> Still LGTM
>>>
>>> On Thu, Feb 7, 2019 at 9:51 PM François Beaufort 
>>> wrote:
>>>
 After more thoughts, we'd like to extend the original trial to
 expire when M75 Stable is cut, instead of M74 Stable cut.
 Note that the origin trial didn't start yet.

 On Thursday, February 7, 2019 at 2:24:52 PM UTC+1, Yoav Weiss wrote:
>
> LGTM to experiment
>
> On Mon, Feb 4, 2019 at 8:40 PM François Beaufort <
> beaufort...@gmail.com> wrote:
>
>> Contact emails
>>
>> fbea...@chromium.org, mlam...@chromium.org
>>
>> Explainer
>>
>> 

Re: [blink-dev] Intent to Ship: Third-party Cookie Grace Period Opt-Out

['Jonathan Njeunje' via blink-dev]

In anticipation of approval here, we have a small tool to help people 
validate their well-known files accessible at 
https://3pcd-mitigations-wrv.glitch.me.

On Thursday, May 16, 2024 at 1:19:23 PM UTC-4 Anton Maliev wrote:

> > Each grace period entry has its own expiration date, depending on when 
> the site applied for the deprecation trial.
>
> To clarify, the currently published expiration date is June 30, but we are 
> assessing how grace periods will be used after that date. This feature, 
> though, is intended to help sites migrate off the grace period in a safe 
> way.
>
> On Thursday, May 16, 2024 at 10:15:20 AM UTC-4 Anton Maliev wrote:
>
>> > Will developers have a way of knowing if the current site (where they 
>> may see breakage metrics) is opted-out of the grace period?
>>
>> Google is planning to build a site dashboard where developers can check 
>> on the status of their grace period and opt-out values. In the interim, 
>> Chrome DevTools shows an Issue for third-party cookies which are allowed 
>> due to the grace period - this can be used to validate whether the grace 
>> period is active for that particular client.
>>
>> > Do you have a rough estimate on the length of the grace period? (I'm 
>> guessing this will not be relevant after it) 
>>
>> That's correct, a site will no longer need an opt-out file after it is 
>> removed from the grace period. Each grace period entry has its own 
>> expiration date, depending on when the site applied for the deprecation 
>> trial. We will need to assess the demand for new sites onboarding to the 
>> trial before we can give an estimate on how long we will continue to 
>> support grace periods overall.
>>
>> On Thursday, May 16, 2024 at 3:56:15 AM UTC-4 Yoav Weiss wrote:
>>
>>> This is an odd one, but I agree that it's a web exposed feature and 
>>> hence should go through the blink process. Thanks for sending this!
>>>
>>>
>>> On Tue, May 14, 2024 at 11:15 PM Anton Maliev  
>>> wrote:
>>>
 Contact emails

 ama...@chromium.org

 nje...@chromium.org

 wande...@chromium.org

 Explainer

 https://github.com/explainers-by-googlers/3pcd-grace-period-opt-out

 Specification

 Well-known resource specification: 
 https://github.com/explainers-by-googlers/3pcd-grace-period-opt-out/blob/main/well-known-specification.md

 Summary

 This proposal details a new mechanism for site developers to conduct a 
 self-service staged opt-out of their third-party cookie phaseout grace 
 period. This is intended primarily for Chrome’s active trials for 
 third-party cookie deprecation - one for top-level sites 
 
  
 and one for embedded sites 
 .
  
 When a site is approved for one of these trials, they are added to a 
 short-term grace period which mitigates breakage until the token is 
 launched.  Sites may also use this opt-out to test long term solutions.

 Each site on the trial will specify their desired opt-out percentage in 
 a new resource in their .well-known directory 
 , specified here 
 .
  
 Google will implement server infrastructure to fetch and update these 
 values on a schedule, and assign clients randomly to cohorts matching this 
 percentage. These cohorts persist for a client up until clearing site 
 storage or reinstalling the browser.

>>>
>>>
>>> Will developers have a way of knowing if the current site (where they 
>>> may see breakage metrics) is opted-out of the grace period?
>>>
>>>  
>>>

 Blink component

 Privacy 

 TAG review

 N/A

 TAG review status

 N/A

 Risks

 There aren’t inherent security implications for fetching external 
 resources using server-side infrastructure, but there is a risk of 
 fetching 
 bad data, which our implementation addresses.

 There are also privacy implications for randomly assigning clients to 
 cohorts, which we mitigate by clearing cohorts on site data deletion. 
 There 
 is also a risk that the fetching system fails or that a site loses access 
 to its .well-known resource, both cases which we have planned mitigations 
 for.

 Interoperability and Compatibility

 The third-party cookie deprecation trials are a Chrome feature, so 
 these new well-known resources will only be fetched by the Chrome browser. 
 The new resource will be distinct and will not interfere with any existing 
 resources 

Re: [blink-dev] Intent to Ship: CSS font-size-adjust with the two-value syntax

[Vladimir Levin]

On Wed, May 22, 2024 at 4:00 PM ChangSeok Oh  wrote:

> Hi Philip,
>
> I noticed that font-size-adjust-012.html, font-size-adjust-013.html, and
> parts of font-size-adjust-computed.html (e.g., ch-width and ic-width) show
> minor deviations from expected results. The exact issue with the WPT Linux
> machine is unclear since these tests can be affected by various font
> rendering configuration and environment (e.g., hinting, sub-pixel
> rendering, fonts installed, font rendering libraries, etc.). My Linux
> machine and the Linux try bots pass these tests. I think syncing the WPT
> Linux machine's font setup with our Linux trybot's setup could help.
>

One thing you can try is running this test from wpt.live on your local
build. In the past, I've used that to reproduce failures that would
otherwise pass on the bots. I think this is worthwhile to pursue but I
agree that it shouldn't block the intent.

LGTM3, thanks!


>
> The only actual failure I know of is the ic-height test of
> font-size-adjust-computed.html. This is due to unclear fallback behavior in
> the font spec when the necessary font metrics are missing, which is still
> under discussion by CSSWG, as I noted. Depending on the resolution, some
> test results can change later. I will follow up on this standardization
> effort.
>
> Best,
>
> --
> ChangSeok
>
> > On May 21, 2024, at 5:43 AM, Philip Jägenstedt 
> wrote:
> >
> > Hi ChangSeok,
> >
> > Thank you for working on this, it's great to see both more powerful
> typography control, and progress on Interop 2024.
> >
> > Can you say something about the remaining failures in WPT?
> font-size-adjust-012.html font-size-adjust-013.html both look like minor
> differences, but it seems like it only happens on Linux (Chrome) and not
> Windows (Edge)?
> >
> > There are also 3 failing subtests in font-size-adjust-computed.html,
> does that depend on resolving one of the spec issues? Or can we match what
> Firefox and Safari do and pass the tests without waiting for spec changes?
> >
> > Best regards,
> > Philip
> >
> > On Thu, May 16, 2024 at 5:01 PM Vladimir Levin 
> wrote:
> >
> >
> > On Thu, May 16, 2024 at 10:02 AM ChangSeok Oh 
> wrote:
> > Contact emails
> > changseok...@bytedance.com, changs...@chromium.org
> >
> > Explainer
> > None
> >
> > Specification
> > https://www.w3.org/TR/css-fonts-5/#font-size-adjust-prop
> >
> > Summary
> > The font-size-adjust CSS property enhances readability consistency by
> adjusting font size based on lowercase letter height rather than uppercase.
> Additionally, the newly introduced two-value syntax for font-size-adjust in
> the font module level 5 enables web designers to specify a font metric for
> size adjustment. This feature is one of focus areas for Interop 2024.
> >
> > Blink component
> > Blink>CSS, Blink>Fonts
> >
> > TAG review
> > None
> >
> > TAG review status
> > Not applicable
> >
> > Risks
> > Interoperability and Compatibility
> > Gecko and WebKit have shipped this feature, and there is no major
> interoperability risk. However, certain aspects are still being discussed
> regarding interoperability concerns. [1, 2].
> > [1] https://github.com/w3c/csswg-drafts/issues/6384 [2]
> https://github.com/w3c/csswg-drafts/issues/10292
> >
> > Gecko: Shipped/Shipping (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1711479)
> >
> > WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=254191
> )
> >
> > 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
> > N/A
> >
> > Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?
> > Yes. Windows experiences a minor sub-pixel mismatching issue in one wpt
> test, but it doesn't affect usability.
> >
> > Is this feature fully tested by web-platform-tests?
> > Yes
> >
> https://wpt.fyi/results/css/css-fonts?label=master=experimental=interop=label%3Ainterop-2024-font-size-adjust
> >
> > Flag name on chrome://flags
> > enable-experimental-web-platform-features
> >
> > Finch feature name
> > CSSFontSizeAdjust
> >
> > Requires code in //chrome?
> > False
> >
> > Tracking bug
> > - https://issues.chromium.org/issues/40081245
> > - https://issues.chromium.org/issues/40186237
> >
> > Measurement
> > - https://chromestatus.com/metrics/css/timeline/popularity/465
> > - https://caniuse.com/font-size-adjust
> >
> > Availability expectation
> > Both the Gecko and WebKit communities have implemented this feature, and
> corresponding tests are already included in the Web Platform Tests (WPT).
> >
> > Adoption expectation
> > Firefox and WebKit variant browsers have embraced this feature.
> >
> > Adoption plan
> > Blink is shipping this feature.
> >
> > Non-OSS dependencies
> > Does the feature depend on any code or APIs outside the Chromium open
> 

Re: [blink-dev] Support for SharedArrayBuffer API and WASM Sqlite in WebView

['Etienne Noël' via blink-dev]

WebSQL in Webview is still available but deprecated. It's recommended to
not use it as it will be removed entirely in ~ 18 months.

On Thu, May 23, 2024 at 10:09 AM 'Thomas Steiner' via blink-dev <
blink-dev@chromium.org> wrote:

> That's correct, WebView doesn't support this as per
> https://issues.chromium.org/issues/40914606#comment5. @Ayu Ishii
> , what's the status of WebSQL in WebView, is it still
> available (I think it is)?
>
> On Thu, May 23, 2024, 18:29 'Antonio MORENO' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Hi,
>>
>> We maintain a web application that previously used WebSQL, and that has
>> been migrated to the WASM implementation of Sqlite. This works well in the
>> newer versions of Chrome, but it seems it doesn't work in an Android
>> application some of our customers use, that is implemented using WebView.
>>
>> The reason seems to be that the SharedArrayBuffers API, which the WASM
>> Sqlite library requires, is not supported in WebView:
>>
>> https://caniuse.com/sharedarraybuffer
>>
>> Can you confirm this is the case? Will this API be supported in WebView
>> at some point? Or otherwise, what would be the recommended approach in case
>> a customer needs to use a WebView-based Android application to access our
>> web application?
>>
>> Thanks in advance, and kind regards,
>>
>> Antonio Moreno.
>>
>> --
>> 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/597d01f5-2dac-4b02-bb63-f3415493496an%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/CALgRrLmcR43B4KkqLz4XwC6vKXpyH4UBHQH8zrjCPjT1YstvTw%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/CAKezNQEH1YJgz%2BWxniqUgAEZh3kEnQL5YXN5LPwJqQe0jPDZJA%40mail.gmail.com.

Re: [blink-dev] Support for SharedArrayBuffer API and WASM Sqlite in WebView

['Thomas Steiner' via blink-dev]

That's correct, WebView doesn't support this as per
https://issues.chromium.org/issues/40914606#comment5. @Ayu Ishii
, what's the status of WebSQL in WebView, is it still
available (I think it is)?

On Thu, May 23, 2024, 18:29 'Antonio MORENO' via blink-dev <
blink-dev@chromium.org> wrote:

> Hi,
>
> We maintain a web application that previously used WebSQL, and that has
> been migrated to the WASM implementation of Sqlite. This works well in the
> newer versions of Chrome, but it seems it doesn't work in an Android
> application some of our customers use, that is implemented using WebView.
>
> The reason seems to be that the SharedArrayBuffers API, which the WASM
> Sqlite library requires, is not supported in WebView:
>
> https://caniuse.com/sharedarraybuffer
>
> Can you confirm this is the case? Will this API be supported in WebView at
> some point? Or otherwise, what would be the recommended approach in case a
> customer needs to use a WebView-based Android application to access our web
> application?
>
> Thanks in advance, and kind regards,
>
> Antonio Moreno.
>
> --
> 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/597d01f5-2dac-4b02-bb63-f3415493496an%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/CALgRrLmcR43B4KkqLz4XwC6vKXpyH4UBHQH8zrjCPjT1YstvTw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CSS font-size-adjust with the two-value syntax

[Mike Taylor]

LGTM2

On 5/23/24 12:06 PM, Philip Jägenstedt wrote:

Thank you for looking into the test failures, ChangSeok!

LGTM1 to align with Firefox and Safari on the remaining failures 
(except the reftests with minor pixel differences) and shipping!


On Wed, May 22, 2024 at 10:05 PM ChangSeok Oh  
wrote:


Hi Dominik,

Thanks for your add-up! And Yes, we can align with other browsers
for the time being.

--
ChangSeok

> On May 21, 2024, at 6:13 AM, Dominik Röttsches
 wrote:
>
> Big thanks ChangSeok for implementing this and pushing for this
feature.
>
> I can say a few things about the open issues
>  - https://github.com/w3c/csswg-drafts/issues/6384
>
> font-size-adjust relies on a font metric reference point, for
example, the x-height, cap-height, etc. in order to scale font
sizes to match on a scaled metric.
> Strictly speaking in the OpenType font spec, some metrics that
are spec'ed for font-size-adjust are optional in the font file.
They might not exist in the font file.
> The discussion in this issue revolves around what to do when the
metric does not exist: There are mainly two alternatives:
> a) don't adjust anything, b) adjust to a heuristic that tries to
approximate the missing value.
>
> From an interop point of view: a) is interoperable, b) is not
interoperable without spec changes in the CSS values spec to
tighten the heuristics.
> For Interop 2024, I think we can and should only test and
consider the happy path, in which the font has the metrics.
>
> The missing metrics situation can be considered a somewhat rare
edge case.
>
> - https://github.com/w3c/csswg-drafts/issues/10292
>
> This discussion is about the computed style of font-size-adjust
and whether that should "leak" actual values that come from the
font files. If I am not mistaken, FF and Safari are currently
aligned on doing that and making the computed style show values
from the font files, in order to inherit a meaningful numerical
value in the cascade. There are arguments for why this is the
right approach from a functionality point of view. Whether it's
the right approach from a CSS inheritance / logical point of view
is perhaps the question. I am not sure about WPT test coverage at
the moment (it's likely small), but for the time being I believe
we can align with Safari and FF. ChangSeok, do you agree?
>
> Dominik
>
>
> On Tue, May 21, 2024 at 3:43 PM Philip Jägenstedt
 wrote:
> Hi ChangSeok,
>
> Thank you for working on this, it's great to see both more
powerful typography control, and progress on Interop 2024.
>
> Can you say something about the remaining failures in WPT?
font-size-adjust-012.html font-size-adjust-013.html both look like
minor differences, but it seems like it only happens on Linux
(Chrome) and not Windows (Edge)?
>
> There are also 3 failing subtests in
font-size-adjust-computed.html, does that depend on resolving one
of the spec issues? Or can we match what Firefox and Safari do and
pass the tests without waiting for spec changes?
>
> Best regards,
> Philip
>
> On Thu, May 16, 2024 at 5:01 PM Vladimir Levin
 wrote:
>
>
> On Thu, May 16, 2024 at 10:02 AM ChangSeok Oh
 wrote:
> Contact emails
> changseok...@bytedance.com, changs...@chromium.org
>
> Explainer
> None
>
> Specification
> https://www.w3.org/TR/css-fonts-5/#font-size-adjust-prop
>
> Summary
> The font-size-adjust CSS property enhances readability
consistency by adjusting font size based on lowercase letter
height rather than uppercase. Additionally, the newly introduced
two-value syntax for font-size-adjust in the font module level 5
enables web designers to specify a font metric for size
adjustment. This feature is one of focus areas for Interop 2024.
>
> Blink component
> Blink>CSS, Blink>Fonts
>
> TAG review
> None
>
> TAG review status
> Not applicable
>
> Risks
> Interoperability and Compatibility
> Gecko and WebKit have shipped this feature, and there is no
major interoperability risk. However, certain aspects are still
being discussed regarding interoperability concerns. [1, 2].
> [1] https://github.com/w3c/csswg-drafts/issues/6384 [2]
https://github.com/w3c/csswg-drafts/issues/10292
>
> Gecko: Shipped/Shipping
(https://bugzilla.mozilla.org/show_bug.cgi?id=1711479)
>
> WebKit: Shipped/Shipping
(https://bugs.webkit.org/show_bug.cgi?id=254191)
>
> 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

[blink-dev] Support for SharedArrayBuffer API and WASM Sqlite in WebView

['Antonio MORENO' via blink-dev]

Hi,

We maintain a web application that previously used WebSQL, and that has 
been migrated to the WASM implementation of Sqlite. This works well in the 
newer versions of Chrome, but it seems it doesn't work in an Android 
application some of our customers use, that is implemented using WebView.

The reason seems to be that the SharedArrayBuffers API, which the WASM 
Sqlite library requires, is not supported in WebView:

https://caniuse.com/sharedarraybuffer

Can you confirm this is the case? Will this API be supported in WebView at 
some point? Or otherwise, what would be the recommended approach in case a 
customer needs to use a WebView-based Android application to access our web 
application?

Thanks in advance, and kind regards,

Antonio Moreno.

-- 
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/597d01f5-2dac-4b02-bb63-f3415493496an%40chromium.org.

Re: [blink-dev] Intent to Ship: CSS font-size-adjust with the two-value syntax

[Philip Jägenstedt]

Thank you for looking into the test failures, ChangSeok!

LGTM1 to align with Firefox and Safari on the remaining failures (except
the reftests with minor pixel differences) and shipping!

On Wed, May 22, 2024 at 10:05 PM ChangSeok Oh 
wrote:

> Hi Dominik,
>
> Thanks for your add-up! And Yes, we can align with other browsers for the
> time being.
>
> --
> ChangSeok
>
> > On May 21, 2024, at 6:13 AM, Dominik Röttsches  wrote:
> >
> > Big thanks ChangSeok for implementing this and pushing for this feature.
> >
> > I can say a few things about the open issues
> >  - https://github.com/w3c/csswg-drafts/issues/6384
> >
> > font-size-adjust relies on a font metric reference point, for example,
> the x-height, cap-height, etc. in order to scale font sizes to match on a
> scaled metric.
> > Strictly speaking in the OpenType font spec, some metrics that are
> spec'ed for font-size-adjust are optional in the font file. They might not
> exist in the font file.
> > The discussion in this issue revolves around what to do when the metric
> does not exist: There are mainly two alternatives:
> > a) don't adjust anything, b) adjust to a heuristic that tries to
> approximate the missing value.
> >
> > From an interop point of view: a) is interoperable, b) is not
> interoperable without spec changes in the CSS values spec to tighten the
> heuristics.
> > For Interop 2024, I think we can and should only test and consider the
> happy path, in which the font has the metrics.
> >
> > The missing metrics situation can be considered a somewhat rare edge
> case.
> >
> > - https://github.com/w3c/csswg-drafts/issues/10292
> >
> > This discussion is about the computed style of font-size-adjust and
> whether that should "leak" actual values that come from the font files. If
> I am not mistaken, FF and Safari are currently aligned on doing that and
> making the computed style show values from the font files, in order to
> inherit a meaningful numerical value in the cascade. There are arguments
> for why this is the right approach from a functionality point of view.
> Whether it's the right approach from a CSS inheritance / logical point of
> view is perhaps the question. I am not sure about WPT test coverage at the
> moment (it's likely small), but for the time being I believe we can align
> with Safari and FF. ChangSeok, do you agree?
> >
> > Dominik
> >
> >
> > On Tue, May 21, 2024 at 3:43 PM Philip Jägenstedt 
> wrote:
> > Hi ChangSeok,
> >
> > Thank you for working on this, it's great to see both more powerful
> typography control, and progress on Interop 2024.
> >
> > Can you say something about the remaining failures in WPT?
> font-size-adjust-012.html font-size-adjust-013.html both look like minor
> differences, but it seems like it only happens on Linux (Chrome) and not
> Windows (Edge)?
> >
> > There are also 3 failing subtests in font-size-adjust-computed.html,
> does that depend on resolving one of the spec issues? Or can we match what
> Firefox and Safari do and pass the tests without waiting for spec changes?
> >
> > Best regards,
> > Philip
> >
> > On Thu, May 16, 2024 at 5:01 PM Vladimir Levin 
> wrote:
> >
> >
> > On Thu, May 16, 2024 at 10:02 AM ChangSeok Oh 
> wrote:
> > Contact emails
> > changseok...@bytedance.com, changs...@chromium.org
> >
> > Explainer
> > None
> >
> > Specification
> > https://www.w3.org/TR/css-fonts-5/#font-size-adjust-prop
> >
> > Summary
> > The font-size-adjust CSS property enhances readability consistency by
> adjusting font size based on lowercase letter height rather than uppercase.
> Additionally, the newly introduced two-value syntax for font-size-adjust in
> the font module level 5 enables web designers to specify a font metric for
> size adjustment. This feature is one of focus areas for Interop 2024.
> >
> > Blink component
> > Blink>CSS, Blink>Fonts
> >
> > TAG review
> > None
> >
> > TAG review status
> > Not applicable
> >
> > Risks
> > Interoperability and Compatibility
> > Gecko and WebKit have shipped this feature, and there is no major
> interoperability risk. However, certain aspects are still being discussed
> regarding interoperability concerns. [1, 2].
> > [1] https://github.com/w3c/csswg-drafts/issues/6384 [2]
> https://github.com/w3c/csswg-drafts/issues/10292
> >
> > Gecko: Shipped/Shipping (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1711479)
> >
> > WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=254191
> )
> >
> > 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
> > N/A
> >
> > Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?
> > Yes. Windows experiences a minor sub-pixel mismatching issue in one wpt
> test, but it doesn't affect usability.
> >
> > Is this 

Re: [blink-dev] Intent to Ship: CSS font-size-adjust with the two-value syntax

[Philip Jägenstedt]

On Wed, May 22, 2024 at 10:00 PM ChangSeok Oh 
wrote:

> Hi Philip,
>
> I noticed that font-size-adjust-012.html, font-size-adjust-013.html, and
> parts of font-size-adjust-computed.html (e.g., ch-width and ic-width) show
> minor deviations from expected results. The exact issue with the WPT Linux
> machine is unclear since these tests can be affected by various font
> rendering configuration and environment (e.g., hinting, sub-pixel
> rendering, fonts installed, font rendering libraries, etc.). My Linux
> machine and the Linux try bots pass these tests. I think syncing the WPT
> Linux machine's font setup with our Linux trybot's setup could help.
>

I see. If it's passing in Chromium's setup then we can be pretty confident
it's just a configuration issue. That will affect the Interop 2024 scores,
but that shouldn't block this intent.

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

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

[Robert Flack]

There were some fresh concerns raised about the shape of the spec PR
 which are being hashed out
on that review thread. I will give it approval once we reach a consensus
there.

On Wed, May 22, 2024 at 4:30 PM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

> OK, thanks for outlining the spec mechanics :)
>
> Regardless of whether the PR actually lands in the spec, for the purpose
> of risk-assessment, it's even more interesting to know if the PR is *ready*
> to land in the spec.
> Can y'all clarify its review status? If it's ready to land, can a spec
> editor approve it, even if it doesn't land until later?
>
> On Fri, May 17, 2024 at 10:18 AM Patrick H. Lauke 
> wrote:
>
>>
>>
>> On 16/05/2024 21:05, Robert Flack wrote:
>> > I believe the reason for waiting is that the intention is to switch to
>> a
>> > different publishing model after level 3 is published? @Patrick H.
>> Lauke
>> >  to confirm.
>>
>> Apologies for the convoluted model here ... I have to admit that I'm
>> actually not sure what the expected way of working around this is, as
>> Pointer Events has been such a "slow and steady" process so far, with a
>> very linear way of working - it's only now that we're just hoping to get
>> PE3 to REC and then had this extra functionality come in that we've hit
>> this snag. I will check with Philippe at W3C to work out what the best
>> way forward here is (have the "frozen" version that makes its way
>> through the steps to REC, while being able to already have a
>> "future/next" branch).
>>
>> P
>> --
>> Patrick H. Lauke
>>
>> * https://www.splintered.co.uk/
>> * https://github.com/patrickhlauke
>> * https://flickr.com/photos/redux/
>> * https://mastodon.social/@patrick_h_lauke
>>
>>

-- 
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/CAJh39TP0qXXDdR89-f-jOgLJ_pWTkfmK_Jb%2BEDGNf6%2BVpbSBwg%40mail.gmail.com.

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

[Kenneth Rohde Christiansen]

To be honest we haven't looked deeply into Android support given we didn't
have any active partners for that, and it is not a core platform for our
team at Intel.

I did check out apps like AIDA64 and CPU-Z and they report 0% utilization
on my Pixel phone. Some apps like "CPU monitor" show utilization but it is
all over the place, moves from 100% to 16%, and back to 100% multiples
times per second. They might just be looking at the CPU core hertz and
considering max frequency to be 100%, which would not be too useful.

I am not an Android expert, so feel free to enlighten me :-)

Cheers,
Kenneth



On Wed, May 22, 2024 at 4:21 PM Daniel Herr 
wrote:

> Could someone elaborate on why this won't be implemented for Android? It
> seems like a very useful thing to have, especially considering that the
> biggest amount of users with low end hardware who would stand to benefit
> are on Android.
>
> "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."
>
> I see a variety of CPU monitoring apps in the Play Store. Could someone
> test if they work on Android >=12?
> Also, how can it be both that new Android versions don't allow access and
> partners are using native solutions? Why can't Chromium use whatever they
> are using?
>
> On Monday, May 20, 2024 at 7:00:18 AM UTC-4 Arnaud Mandy wrote:
>
>> Philip,
>>
>> Thanks for the follow up.
>> Yes, you are correct!
>>
>> I ll file a bug and propose a fix (disabling feature on Android).
>>
>> Arnaud.
>>
>> On Friday, May 17, 2024 at 6:00:20 PM UTC+3 Philip Jägenstedt wrote:
>>
>>> Hi Arnaud,
>>>
>>> I have a followup question about this. I assumed that the feature
>>> wouldn't be enabled on Android, but judging by Chromium source and wpt.fyi
>>> test results, at least the API surface is exposed:
>>>
>>> https://wpt.fyi/results/compute-pressure/idlharness.https.any.html?label=master=experimental=chrome=chrome_android
>>>
>>> What will be the behavior on Android, will the API appear to work but
>>> never invoke the observer callback? If so, would it make sense to disable
>>> the feature on Android instead?
>>>
>>> Best regards,
>>> Philip
>>>
>>> On Tue, Mar 19, 2024 at 9:52 PM Chris Harrelson 
>>> wrote:
>>>
 LGTM3

 On Mon, Mar 18, 2024 at 6:10 AM Arnaud Mandy 
 wrote:

> Shipping of Compute Pressure API has been changed from M124 to M125.
> Today is M124 branching and we are not fulfilling all the requirements
> for shipping given the ongoing discussions, the filed issue
> , and one missing
> LGTM.
> We are still actively working on the items just mentioned to see
> Compute Pressure API shipping in M125.
>
> Br,
> Arnaud
> On Tuesday, March 5, 2024 at 1:57:31 PM UTC+2 Arnaud Mandy wrote:
>
>> Contact emails
>>
>> kenneth.r.c...@intel.com, arnaud...@intel.com, wei4...@intel.com,
>> raphael.ku...@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