from:"Yoav Weiss"

LGTM3

One question raised 
elsewhere was around same-origin links, where links to origin B visited
from origin A should be then marked as visited when linked directly from B.
I see there's an open issue

on this. It'd be good if one of the experiment's goals would be to
determine if this is a blocker or not for initial shipping.

On Wed, Jul 3, 2024 at 10:12 PM Daniel Bratell  wrote:

> LGTM2 for a low percentage finch experiment in M128-M130 (inclusive)
>
> /Daniel
> On 2024-07-03 22:02, Chris Harrelson wrote:
>
> LGTM1
>
> (probably 3 needed because this is a non-standard experiment)
>
> On Wed, Jul 3, 2024 at 12:28 PM Kyra Seevers 
> wrote:
>
>> One point of clarification: we are intending to experiment for one
>> milestone (M128), but would like to request 3 milestones (M128 - M130) in
>> case of any delays.
>>
>> Thanks so much!
>>
>> On Wed, Jul 3, 2024 at 2:16 PM Kyra Seevers 
>> wrote:
>>
>>> Update: I wanted to update the thread that WebKit left positive
>>> indications of support for this proposal in the request for position
>>> recently: https://github.com/WebKit/standards-positions/issues/363.
>>>
>>> Daniel: Thanks for the question! We will be using a traditional Finch
>>> experiment rollout starting with Canary/Dev in M128. I will update this
>>> thread with any changes to the experiment that occur.
>>>
>>> As for why we chose our keying structure: top-level site allows us to
>>> prevent cross-site leaks and frame origin allows us to adhere to the
>>> same-origin policy and avoid cross-frame leaks. For example, if I have an
>>> iframe c.com embedded in both a.com and b.com, keying by top-level site
>>> removes the opportunity for cross-site tracking to occur between these two
>>> iframes. For a visual example of this, please see the explainer (especially
>>> Key Scenarios #2 and #3):
>>> https://github.com/kyraseevers/Partitioning-visited-links-history?tab=readme-ov-file#key-scenarios
>>> .
>>>
>>> Thanks all,
>>> Kyra
>>>
>>> On Wed, Jul 3, 2024 at 10:48 AM Daniel Bratell 
>>> wrote:
>>>
 What milestones do you plan to run the experiment in?

 (Also, why isn't it enough to key on frame origin? I'm sure there is a
 good reason but it's not obvious.)

 /Daniel
 On 2024-07-02 22:42, Kyra Seevers wrote:

 Intent to Experiment: Partitioning :visited links history Phase 2
 (User-facing partitioning for :visited links)
 Contact emails

 kyraseev...@chromium.org

 Explainer

 https://github.com/kyraseevers/Partitioning-visited-links-history

 Specification

 We plan to specify our solution before shipping. This work currently
 falls under the wording in CSS Selectors Level 4
 :  “UAs may treat all links
 as unvisited links or implement other measures to preserve the user’s
 privacy while rendering visited and unvisited links differently.”

 Summary

 To eliminate user browsing history leaks, anchor elements will be
 styled as :visited if and only if they have been clicked from this
 top-level site and frame origin before. On the browser-side, this means
 that the VisitedLinks hashtable will now be partitioned via
 "triple-keying", or by storing the following for each visited link: >>> URL, top-level site, frame origin>. By only styling links that have been
 clicked on this site and frame before, the many side-channel attacks that
 have been developed to obtain :visited links styling information are now
 obsolete, as they no longer provide sites with new information about users.

 Blink component

 Blink>History>VisitedLinks

 Search tags

 visited links ,
 :visited selector
 , partitioning
 history 

 TAG review

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

 TAG review status

 Issues addressed

 Risks
 Interoperability and Compatibility

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

 WebKit: Under Review (
 https://github.com/WebKit/standards-positions/issues/363)

 Web developers: No signals

 Other signals:

-

Positive initial signals from presentation at WebAppSec from both
Apple and Firefox

-

At the XS Leaks Summit, Firefox stated exploration of :visited
links partitioning in their privacy

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

LGTM2

Thanks for working through the PR!

On Wednesday, July 3, 2024 at 5:34:54 PM UTC+2 Daniel Bratell wrote:

> LGTM1
>
> /Daniel
> On 2024-06-26 20:16, 'Sahir Vellani' via blink-dev wrote:
>
> The PR is ready and has been *approved *by the PEWG.  
>
> The shape of the API has been reverted to an id (albeit with a slight name 
> change, persistentDeviceId) on the main PointerEvent interface. All links 
> along with request for positions have been updated. Linking the spec pr here 
> <https://github.com/w3c/pointerevents/pull/495>for convenience.
>
> On Thursday, May 23, 2024 at 7:00:38 AM UTC-7 fla...@chromium.org wrote:
>
>> There were some fresh concerns raised about the shape of the spec PR 
>> <https://github.com/w3c/pointerevents/pull/495> 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) <
>> yoav...@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 <
>>> re...@splintered.co.uk> 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 
>>>> > <mailto:re...@splintered.co.uk> 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/98e62b43-af6b-4db6-a6b7-b76bc0864eedn%40chromium.org
>  
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/98e62b43-af6b-4db6-a6b7-b76bc0864eedn%40chromium.org?utm_medium=email_source=footer>
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bce38b12-556a-4a52-8316-40520857003fn%40chromium.org.

[blink-dev] Re: Intent to Ship: CSS Anchor Positioning: Unwrapped inset-area()

LGTM1

On Wed, Jul 3, 2024 at 1:50 PM Anders Hartvoll Ruud 
wrote:

> On Wed, Jul 3, 2024 at 11:35 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>>
>>
>> On Wednesday, July 3, 2024 at 10:47:21 AM UTC+2 Anders Hartvoll Ruud
>> wrote:
>>
>> Contact emailsandr...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://drafts.csswg.org/css-anchor-position-1/#position-
>> try-fallbacks
>>
>> Summary
>>
>> Replaces the inset-area() function with inset-area values directly within
>> position-try-fallbacks. This means that you now just write e.g.
>> position-try-fallbacks:top instead of position-try-fallbacks:inset-
>> area(top).
>>
>>
>> Just to clarify - this removes the inset-area function?
>>
>
> Yes, correct.
>
>
>>
>>
>>
>> The CSSWG made this change shortly after CSS Anchor Positioning shipped
>> in Blink:
>>
>> https://github.com/w3c/csswg-drafts/issues/10320#issuecomment-2137882897
>>
>>
>> Blink componentBlink>CSS
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>> Searching for existing cases of "inset-area(" in HTTP Archive, I found
>> just a single match out of 638589186 rows:
>>
>> https://css3test.com/tests/css-anchor-position-1.js
>>
>>
>> Do you know if this was used in a production site?
>> From the name, one can assume it's a demo site..
>>
>
> It's just the input for the view to show the features supported by the
> browser e.g.: https://css3test.com/#css-anchor-position-1
>
> It doesn't count as "production use" IMO. Also, I sent a PR to update it:
> https://github.com/LeaVerou/css3test/pull/249
>

Agree!

>
>
>> Query used:
>>
>> #standardSQL
>>
>> SELECT response_bodies.url
>>
>> FROM `httparchive.response_bodies.2024_06_01_desktop` AS response_bodies
>>
>> WHERE REGEXP_CONTAINS(response_bodies.response_body, r'inset\-area\(')
>>
>> *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
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ?Yes
>>
>> Flag name on chrome://flagsNone
>>
>> Finch feature nameCSSInsetAreaValue
>>
>> Requires code in //chrome?False
>>
>> Estimated milestonesShipping on desktop128Shipping on Android128Shipping
>> on WebView128
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or
>> interop issues. Please list open issues (e.g. links to known github issues
>> in the project for the feature specification) whose resolution may
>> introduce web compat/interop risk (e.g., changing to naming or structure of
>> the API in a non-backward-compatible way).
>> None
>>
>> Link to entry on the Chrome Platform Statushttps://chromestatus.com/
>> feature/5116199771045888?gate=5071381116223488
>>
>> This intent message was generated by Chrome Platform Status
>> <https://chromestatus.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/CAOmohS%2Ba%2BW6mFB9LLuu5eh6HwLg%2BHu7HxzoH-p73%2B38MnGSiyg%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: CSS Anchor Positioning: Unwrapped inset-area()



On Wednesday, July 3, 2024 at 10:47:21 AM UTC+2 Anders Hartvoll Ruud wrote:

Contact emailsandr...@chromium.org

ExplainerNone

Specificationhttps://drafts.csswg.org/css-anchor-position-1/#position-
try-fallbacks

Summary

Replaces the inset-area() function with inset-area values directly within 
position-try-fallbacks. This means that you now just write e.g. 
position-try-fallbacks:top instead of position-try-fallbacks:inset-
area(top).


Just to clarify - this removes the inset-area function?
 


The CSSWG made this change shortly after CSS Anchor Positioning shipped in 
Blink:

https://github.com/w3c/csswg-drafts/issues/10320#issuecomment-2137882897


Blink componentBlink>CSS 


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility


Searching for existing cases of "inset-area(" in HTTP Archive, I found just 
a single match out of 638589186 rows:

https://css3test.com/tests/css-anchor-position-1.js


Do you know if this was used in a production site?
>From the name, one can assume it's a demo site..
 


Query used: 

#standardSQL

SELECT response_bodies.url

FROM `httparchive.response_bodies.2024_06_01_desktop` AS response_bodies

WHERE REGEXP_CONTAINS(response_bodies.response_body, r'inset\-area\(')

*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

Is this feature fully tested by web-platform-tests 

?Yes

Flag name on chrome://flagsNone

Finch feature nameCSSInsetAreaValue

Requires code in //chrome?False

Estimated milestonesShipping on desktop128Shipping on Android128Shipping on 
WebView128

Anticipated spec changes

Open questions about a feature may be a source of future web compat or 
interop issues. Please list open issues (e.g. links to known github issues 
in the project for the feature specification) whose resolution may 
introduce web compat/interop risk (e.g., changing to naming or structure of 
the API in a non-backward-compatible way).
None

Link to entry on the Chrome Platform Statushttps://chromestatus.com/
feature/5116199771045888?gate=5071381116223488

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/020c25ac-f034-42aa-b48e-e34a16c70643n%40chromium.org.

Re: [blink-dev] Web-Facing Change PSA: Support currentcolor in Relative Color Syntax

Thanks for pushing this! :)
Is there a reason this shouldn't be an intent? IIUC, we're exposing a new
value here

On Mon, Jun 24, 2024 at 8:20 PM 'Kevin Babbitt' via blink-dev <
blink-dev@chromium.org> wrote:

> *Contact emails*
>
> kbabb...@microsoft.com
>
> *Specification*
>
> https://www.w3.org/TR/css-color-5/#resolving-rcs
>
> *Design docs*
>
> https://docs.google.com/document/d/1568wVjrIRbrU9_O37gPu10cj0CDWRiAc6ZMk9t0JpXs/edit
>
> *Summary*
>
> Allow relative colors in CSS (using the 'from' keyword) to use
> 'currentcolor' as a base. This will make it easy for web developers to set
> complementary colors, based on an element's text color, for that element's
> borders, shadows, backgrounds, etc.
>
>
>
> *Blink component*
>
> Blink>CSS
> 
>
> *TAG review*
>
> https://github.com/w3ctag/design-reviews/issues/894
>
> *TAG review status*
>
> Satisfied. The link above is for Relative Color Syntax in general. Tests
> for currentcolor cases were added as part of the discussion before the TAG
> signed off on the review; I interpret that to mean that they're satisfied
> with this use case.
>
>
>
> *Risks*
>
>
>
> *Interoperability and Compatibility*
>
> Interoperability: Relative Color Syntax is a focus area for Interop 2024,
> and inclusion of currentcolor is well covered by existing WPTs, so the risk
> of other engines not converging on an interoperable implementation is low.
>
>
>
> Compatibility: The only risk here is that enabling currentcolor support
> will "light up" color declarations that are being rejected at present.
> Total usage of Relative Color Syntax on the Web (including currentcolor or
> otherwise) is ~0.09% of page loads as of May 1, 2024[1]. I haven't done an
> analysis of currentcolor in RCS, but given that no major engine supported
> it as of that date, I would expect it to be a tiny fraction of those. [1]
> https://chromestatus.com/metrics/feature/timeline/popularity/4632
>
>
>
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/841) Implementation
> bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1893966
>
> *WebKit*: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=245970)
> Changes landed May 13.
>
> *Web developers*: Positive (
> https://github.com/web-platform-tests/interop/issues/426) This feature is
> part of Interop 2024.
>
> *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*
>
> Covered by existing DevTools support for debugging CSS properties.
>
>
>
> *Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?*
>
> Yes
>
> *Is this feature fully tested by web-platform-tests
> ?*
>
> Yes
>
>
> https://wpt.fyi/results/css/css-color?label=master=experimental=interop=label%3Ainterop-2024-relative-color
>
>
>
> *Flag name on chrome://flags*
>
> None
>
> *Finch feature name*
>
> CSSRelativeColorSupportsCurrentcolor
>
> *Requires code in //chrome?*
>
> False
>
> *Tracking bug*
>
> https://issues.chromium.org/issues/325309578
>
>
> *Estimated milestones*
>
> Shipping on desktop
>
> 129
>
>
>
> Shipping on Android
>
> 129
>
>
>
> Shipping on WebView
>
> 129
>
>
>
>
> *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/5307971793059840?gate=6194544847880192
>
> 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/SJ0PR00MB1144DF620BEDF481846E0E14C0D42%40SJ0PR00MB1144.namprd00.prod.outlook.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

Re: [blink-dev] Re: Web-Facing Change PSA: Rename position-try-options to position-try-fallbacks

On Wed, Jul 3, 2024 at 11:17 AM Anders Hartvoll Ruud 
wrote:

> I'll answer since Mason is now OOO.
>
> On Tue, Jul 2, 2024 at 8:48 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>>
>>
>> On Tuesday, July 2, 2024 at 12:38:50 AM UTC+2 Mason Freed wrote:
>>
>> Contact emailsmas...@chromium.org, andr...@chromium.org
>>
>> Specificationhttps://github.com/w3c/csswg-drafts/issues/10395#
>> issuecomment-2192127524
>>
>> Summary
>>
>> The CSSWG resolved to rename this property, because "fallbacks" more
>> accurately describes what this property controls. The word "options" is a
>> bit deceiving, since the styles outside of `position-try` blocks will be
>> tested first, and if they result in a layout that fits within the
>> containing block, none of the "options" will get used. So "fallbacks" is a
>> better word to describe this behavior. https://github.com/w3c/csswg-
>> drafts/issues/10395#issuecomment-2192127524
>>
>>
>> Blink componentBlink>CSS
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>
>> Search tagsanchor positioning
>> <https://chromestatus.com/features#tags:anchor%20positioning>
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> This is a name change, which will result in the old name no longer
>> functioning. So there is a risk of breakage. However, the anchor
>> positioning feature was very recently shipped, and does not have
>> implementation in other browsers. So we feel the risk is quite small
>> currently, but will grow over time. Given that, we'd like to rename this
>> property ASAP to avoid the risk getting too large. The use counter is
>> currently quite low, around 0.01% in June: https://chromestatus.com/
>> metrics/css/timeline/popularity/784 An HTTP Archive search was
>> performed, which showed that almost all usage comes from one Shopify CSS
>> file (`spec-and-compare.css`), and we intend to reach out to Shopify (or
>> hope for a response from one very special Blink API owner) to make sure
>> this will not break Shopify.
>>
>>
>> "very special" :)
>>
>> It seems like the source of usage is this 3P app:
>> https://apps.shopify.com/spec-compare
>> I'll send you their contact email so that you can reach out to them
>> directly.
>>
>
> Note: They can preemptively handle this change today by using
> position-try:flip-inline instead.
>
>
>>
>> Can you share the HTTP Archive analysis? Manual inspection of the hosts
>> listed in the chromestatus counter didn't reveal much on my end.
>>
>
> Not sure about "analysis", but the raw dump is here:
> https://docs.google.com/document/d/1x3JKq_iGv24w-2y-rzQbS6MV78UcsTH1yWEJFeH-RdY/edit?usp=sharing
> (@chromium.org to access)
>
> It looks like the usage we see from HTA so far is flip-block/flip-inline,
> which e.g. means a tooltip won't move over to the other (better) side of a
> box when it's scrolled out of view.
>
> Beyond that, I think this would require an intent and maybe a short
>> deprecation period. Even if the only source is this single app, unless the
>> breakage is insignificant,
>>
> we'd need at least one release overlap between the new and the old values,
>> to avoid a breakage period while users are upgrading from Chromium N to N+1.
>>
>
> It's tricky, because waiting could actually cause *more* breakage, even
> with a deprecation period, and the numbers look quite good right now.
>

If the app in question could switch to `position-try:flip-inline` that
changes things, and would indeed not require a milestone overlap, assuming
they can make that change.


>
>>
>>
>>
>> *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)?Yes
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ?Yes
>>
&g

[blink-dev] Re: Web-Facing Change PSA: Rename position-try-options to position-try-fallbacks

2024-07-02 Thread Yoav Weiss (@Shopify)

On Tuesday, July 2, 2024 at 12:38:50 AM UTC+2 Mason Freed wrote:

Contact emailsmas...@chromium.org, andr...@chromium.org

Specificationhttps://github.com/w3c/csswg-drafts/issues/10395#
issuecomment-2192127524

Summary

The CSSWG resolved to rename this property, because "fallbacks" more
accurately describes what this property controls. The word "options" is a
bit deceiving, since the styles outside of `position-try` blocks will be
tested first, and if they result in a layout that fits within the
containing block, none of the "options" will get used. So "fallbacks" is a
better word to describe this behavior. https://github.com/w3c/csswg-
drafts/issues/10395#issuecomment-2192127524

Blink componentBlink>CSS

Search tagsanchor positioning

TAG reviewNone

TAG review statusNot applicable

Risks

Interoperability and Compatibility

This is a name change, which will result in the old name no longer
functioning. So there is a risk of breakage. However, the anchor
positioning feature was very recently shipped, and does not have
implementation in other browsers. So we feel the risk is quite small
currently, but will grow over time. Given that, we'd like to rename this
property ASAP to avoid the risk getting too large. The use counter is
currently quite low, around 0.01% in June: https://chromestatus.com/
metrics/css/timeline/popularity/784 An HTTP Archive search was performed,
which showed that almost all usage comes from one Shopify CSS file
(`spec-and-compare.css`), and we intend to reach out to Shopify (or hope
for a response from one very special Blink API owner) to make sure this
will not break Shopify.

"very special" :)

It seems like the source of usage is this 3P
app: https://apps.shopify.com/spec-compare
I'll send you their contact email so that you can reach out to them
directly.

Can you share the HTTP Archive analysis? Manual inspection of the hosts
listed in the chromestatus counter didn't reveal much on my end.

Beyond that, I think this would require an intent and maybe a short
deprecation period. Even if the only source is this single app, unless the
breakage is insignificant, we'd need at least one release overlap between
the new and the old values, to avoid a breakage period while users are
upgrading from Chromium N to N+1.

*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)?Yes

Is this feature fully tested by web-platform-tests

?Yes

https://wpt.fyi/results/css/css-anchor-position

Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Tracking bughttps://crbug.com/349600667

Estimated milestonesShipping on desktop128Shipping on Android128Shipping on
WebView128

Anticipated spec changes

Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).
None

Link to entry on the Chrome Platform Statushttps://chromestatus.com/
feature/5167414571696128?gate=5182169462079488

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/cf8a8c9d-9efa-4bff-9dd5-590809fe2877n%40chromium.org.

Re: [blink-dev] Intent to Prototype and Ship: Compute Pressure WebDriver endpoints

2024-06-19 Thread Yoav Weiss (@Shopify)

On Wed, Jun 19, 2024 at 9:55 AM Mandy, Arnaud 
wrote:

> Contact emails
> raphael.kubo.da.co...@intel.com, juha.j.vai...@intel.com,
> kenneth.r.christian...@intel.com, arnaud.ma...@intel.com
>
> Specification
> https://github.com/w3c/compute-pressure/pull/284
>



+Mathias Bynens  +Alex Rudenko
  - I'd love to hear your thoughts on this in
general and on the PR in particular.

Arnaud - was this discussed with the WebDriver WG? Even if other vendors
are opposed to the broader feature, it'd still be good to validate the
design.


>
> Summary
> This exposes WebDriver commands for creating, removing and updating
> pressure source samples for so-called "virtual pressure sources": pressure
> sources that do not depend on underlying hardware or operating system
> support and can be used for testing.
>
> Not only does this allow ChromeDriver users to test this API more easily,
> but it was also one of the suggestions brought up during the Intent to
> Ship thread for this API
> ,
> as the existing web tests in WPT depend on MojoJS and are not interoperable.
>
> Blink component
> Blink>PerformanceAPIs>ComputePressure
> 
>
> TAG review
> None
>
> TAG review status
> Not applicable
>
> Risks
>
>
> Interoperability and Compatibility
> This feature implements WebDriver extension commands in ChromeDriver that
> are used in web-platform-tests and can also be used by ChromeDriver users.
> This feature is therefore not web-exposed, but it does intend to help
> increase adoption of the spec by making it possible for any implementation
> to run the existing web tests without having to use JS mocks that are
> heavily Mojo-based although not dependent on Mojo.
>
> *Gecko*: No signal for this feature (Not in favor of Compute Pressure API)
>
> *WebKit*: No signal for this feature (Not in favor of Compute Pressure
> API)
>

I agree that there's no point in filing for a signal if they are opposed to
the feature itself.


>
> *Web developers*: No signals
>
> *Other signals*: Compute Pressure API Intent To Ship comment
> 
> .
>
>
> Security
> n/a, this is exposed through WebDriver. There have been changes to the
> Compute Pressure code in //content and //services.
>
> WebView application risks
> None, this API is not exposed on Android.
>
> Ongoing technical constraints
> WebDriver endpoints and virtual pressure sources work in Window and
> Dedicated Worker scopes, but not shared worker ones: we store virtual
> pressure source information in WebContentsUserData, which does not
> integrate well with shared workers. Shared worker support would need to
> work with origins instead, but doing so would not play well with any
> DevTools frontend work to support the Compute Pressure API. The same
> constraint is also present in the spec, and feedback is being gathered in 
> issue
> 285 .
>
> Debuggability
> This is a debugging feature. It exposes new ChromeDriver and CDP
> endpoints, but the DevTools frontend has not been touched.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?
> Windows, Mac, Linux, ChromeOS
>
> Is this feature fully tested by web-platform-tests
> 
> ?
> The feature is currently tested by WPT, but the tests depend on
> Mojo-specific JS mocks. Having these endpoints is the first step towards
> making the existing web tests interoperable.
>
> Requires code in //chrome?
> True: //chrome/test/chromedriver
>
> Tracking bug
> https://issues.chromium.org/u/1/issues/347031400
>
> Estimated milestones
> Shipping on desktop 130
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5130657352384512
>
> --
> 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/DS0PR11MB79029DDFA8D49E3C82BEAF4393CF2%40DS0PR11MB7902.namprd11.prod.outlook.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

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

2024-06-18 Thread Yoav Weiss (@Shopify)

LGTM to extend the deprecation trial M127-132, but it'd be good to have
meaningful progress by then to reduce the number of folks that use it..

On Fri, Jun 14, 2024 at 8:48 PM Emily Stark  wrote:

>
>
> On Fri, Jun 14, 2024 at 10:36 AM Emily Stark  wrote:
>
>> (Apologies for the slow response, we had some OOOs)
>>
>> On Mon, Jun 3, 2024 at 7:55 PM Mike Taylor 
>> wrote:
>>
>>> Hi Emily,
>>>
>>> A few questions inline:
>>> On 6/1/24 5:05 AM, Emily Stark wrote:
>>>
>>> Contact emails est...@google.com, jdebla...@google.com,
>>> dadr...@google.com, l...@chromium.org, tito...@chromium.org,
>>> cl...@chromium.org, mk...@chromium.org, v...@chromium.org
>>>
>>> Explainer
>>> https://github.com/WICG/private-network-access/blob/master/explainer.md
>>>
>>> Specification https://wicg.github.io/private-network-access
>>>
>>> Design docs
>>>
>>> https://docs.google.com/document/d/1x1a1fQLOrcWogK3tpFBgQZQ5ZjcONTvD0IqqXkgrg5I/edit#heading=h.7nki9mck5t64
>>>
>>> Summary
>>>
>>> Requires that private network requests for subresources from public
>>> websites may only be initiated from a secure context. Examples include
>>> internet to intranet requests and internet to loopback requests. This is a
>>> first step towards fully implementing Private Network Access:
>>> https://wicg.github.io/private-network-access/
>>>
>>>
>>> Blink component Blink>SecurityFeature>CORS>PrivateNetworkAccess
>>> 
>>>
>>> TAG review https://github.com/w3ctag/design-reviews/issues/572
>>>
>>> TAG review status Issues addressed
>>>
>>> Chromium Trial Name PrivateNetworkAccessNonSecureContextsAllowed
>>>
>>> Link to origin trial feedback summary
>>> https://docs.google.com/spreadsheets/d/1z5ZdCslNCnSVR7TNlUTHjSvunMFmT_9G9NOx8-O78-I/edit?usp=sharing=0-DITlG8tDuFDWHiBUHnlSoQ
>>>
>>> Origin Trial documentation link
>>> https://developer.chrome.com/blog/private-network-access-update/
>>>
>>> WebFeature UseCounter name
>>> kPrivateNetworkAccessNonSecureContextsAllowedDeprecationTrial
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> No interoperability risks. Compatibility risk is small but
>>> non-negligible. UseCounters show ~0.1% of page visit making use of this
>>> feature. Direct outreach to the largest users per UKM data revealed no
>>> objections to this launch. Rolling this deprecation out to beta per the
>>> previous I2S resulted in more feedback about the compatibility risk and the
>>> need for a time extension. See the following doc for an extensive
>>> discussion:
>>> https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit
>>>
>>> Can you speak to the number of sites in the largest users group? Is it
>>> dozens of sites? Hundreds? Presumably they're all enrolled in the DT?
>>>
>> I've requested access to the OT data so I can't say for sure yet, but in
>> the meantime, my impression is that we're roughly talking about hundreds of
>> sites. The breakage of ending the deprecation trial would be quite small in
>> terms of affected page loads, but there are legitimate use cases
>> 
>> for nonsecure subresource requests to the private network that we're trying
>> to accomodate because they don't have an alternative/workaround.
>>
>
> Update: it looks like there are ~1000 sites registered in the DT.
>
>
>> *Gecko*: Closed Without a Position (
>>> https://github.com/mozilla/standards-positions/issues/143) Tentatively
>>> positive, but no formal position yet.
>>>
>>> *WebKit*: Positive (
>>> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031837.html)
>>>
>>> *Web developers*: Mixed signals (
>>> https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit)
>>> In our recent survey, most of websites are able to migrate if our new
>>> permission prompt can be landed as a way for them to relax mixed content
>>> checks.
>>> https://docs.google.com/spreadsheets/d/1z5ZdCslNCnSVR7TNlUTHjSvunMFmT_9G9NOx8-O78-I/edit?resourcekey=0-DITlG8tDuFDWHiBUHnlSoQ#gid=309953809
>>>  
>>> Some websites, broadly falling in the category of controller webapps for
>>> IoT devices, find this change incompatible with their use cases. While many
>>> use cases can be solved with specific workarounds, some still require
>>> further engagement.
>>>
>>> *Other signals*:
>>>
>>> Activation
>>>
>>> Developers of non-secure sites that rely upon local servers will need to
>>> upgrade to HTTPS. This might cause some complications, as mixed-content
>>> checks will begin to apply. Chrome carves out HTTP access to loopback (as
>>> perhttps://w3c.github.io/webappsec-secure-contexts/#localhost),

Re: [blink-dev] Intent to Implement and Ship: aria-rowindextext and aria-colindextext

2024-06-18 Thread Yoav Weiss (@Shopify)

LGTM2

On Mon, Jun 17, 2024 at 10:05 PM Vladimir Levin  wrote:

> LGTM1, thanks
>
> On Wed, Jun 12, 2024 at 2:35 PM 'Daniel Clark' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> *Contact emails*
>>
>> dan...@microsoft.com
>>
>>
>>
>> *Explainer*
>>
>> No formal explainer but https://github.com/w3c/aria/issues/667 discusses
>> use cases and alternatives.
>>
>>
>>
>> *Specification*
>>
>> https://w3c.github.io/aria/#aria-colindextext,
>> https://w3c.github.io/aria/#aria-rowindextext
>>
>>
>>
>> *Summary*
>>
>> The `aria-rowindextext` and `aria-colindextext` properties can be used by
>> developers to express semantics about a table or grid to assistive tech.
>> These attributes are applied in addition to `aria-rowindex` or
>> `aria-colindex` in cases where the numeric indices of rows or columns are
>> not meaningful, for example a chessboard or a spreadsheet where the columns
>> are named by letters rather than numbers.
>>
>>
>>
>> These properties are reflected in JavaScript as:
>>
>>- `Element.ariaRowIndexText`
>>- `Element.ariaColIndexText`
>>- `ElementInternals.ariaRowIndexText`
>>- `ElementInternals.ariaColIndexText`
>>
>>
>>
>> These are part of the Interop2024 Accessibility focus area:
>> https://wpt.fyi/results/wai-aria/idlharness.window.html?label=master=experimental=interop=label%3Ainterop-2024-accessibility
>>
>>
>>
>> *Blink component*
>>
>> Blink>Accessibility
>>
>>
>>
>> *TAG review*
>>
>> These properties were included for WAI-ARIA 1.3 which was reviewed by the
>> TAG at https://github.com/w3ctag/design-reviews/issues/927
>>
>>
>>
>> *TAG review status*
>>
>> Resolution: Satisfied
>>
>>
>>
>> *Risks*
>>
>>
>>
>>
>>
>> *Interoperability and Compatibility*
>>
>> None
>>
>>
>>
>>
>>
>> Gecko: Shipped/Shipping
>>
>>
>>
>> WebKit: No signal (https://bugs.webkit.org/show_bug.cgi?id=257142)
>>
>>
>>
>> Web developers: No direct signals, but this is part of the Interop2024
>> Accessibility focus area:
>> https://wpt.fyi/results/?label=master=experimental=interop=label%3Ainterop-2024-accessibility
>>
>>
>>
>> Other signals:
>>
>>
>>
>> *Ergonomics*
>>
>> None.
>>
>>
>>
>>
>>
>>
>>
>> *Activation*
>>
>> It isn't possible to polyfill the functionality of delivering the
>> semantics to AT. However the properties can be set on browsers that don't
>> support them yet without causing errors, so gradual adoption should be
>> straightforward.
>>
>>
>>
>> The property reflection behavior could be polyfilled if necessary.
>>
>>
>>
>>
>>
>>
>>
>> *Security*
>>
>> We do not anticipate any security impact from this feature.
>>
>>
>>
>>
>>
>>
>>
>> *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*
>>
>> The property values can be observed in chrome://accessibility.
>>
>>
>>
>> *Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, ChromeOS, Android, and Android WebView)?*
>>
>> Yes
>>
>>
>>
>> *Is this feature fully tested by web-platform-tests?*
>>
>> Yes
>>
>>
>> https://wpt.fyi/results/wai-aria/idlharness.window.html?label=master=experimental=interop=label%3Ainterop-2024-accessibility
>>
>>
>> https://wpt.fyi/results/html/dom/aria-attribute-reflection.html?label=master=experimental=interop=label%3Ainterop-2024-accessibility
>>
>>
>> https://wpt.fyi/results/custom-elements/ElementInternals-accessibility.html?label=master=experimental=interop=%2Fcustom-elements%2F
>>
>>
>>
>>
>>
>>
>>
>> *Flag name on chrome://flags*
>>
>> None
>>
>>
>>
>> *Finch feature name*
>>
>> AriaRowColIndexText
>>
>>
>>
>> *Requires code in //chrome?*
>>
>> False
>>
>>
>>
>> *Estimated milestones*
>>
>> Shipping on desktop 128
>>
>>
>>
>> *Anticipated spec changes*
>>
>> None
>>
>>
>>
>> *Link to entry on the Chrome Platform Status*
>>
>> https://chromestatus.com/feature/5182419585204224
>>
>>
>>
>> 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/MW4PR00MB1453C3FD8F1F3CD3E8133243C5C02%40MW4PR00MB1453.namprd00.prod.outlook.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
>

Re: [blink-dev] Re: Intent to Ship: document.caretPositionFromPoint API

2024-06-17 Thread Yoav Weiss (@Shopify)

On Mon, Jun 17, 2024 at 6:16 PM 'Siye Liu' via blink-dev <
blink-dev@chromium.org> wrote:

> TAG suggested we put the shadow roots in a dictionary with a `shadowRoots`
> option (The API shape changed in spec
> 
> after the TAG review was filed). That's what Chromium implemented: 
> document.idl
> - Chromium Code Search
> .
> I think we are good here.
>

Awesome, thanks!


>
> --
> 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/cb567424-b450-4965-aca9-2910ff533199n%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/CAOmohSL8eTthTPkfsHDZSbXGaV%2B-mtV0k61heDmgSR6hz-%3DmRQ%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: document.caretPositionFromPoint API

2024-06-17 Thread Yoav Weiss (@Shopify)

Note that the TAG just came back with some feedback regarding the API
shape. Please address it before shipping.

On Thu, Jun 13, 2024 at 2:34 PM Daniel Bratell  wrote:

> LGTM3
>
> /Daniel
> On 2024-06-13 10:56, Yoav Weiss (@Shopify) wrote:
>
> LGTM2
>
> On Thu, Jun 13, 2024, 10:32 Chris Harrelson  wrote:
>
>> LGTM1
>>
>> On Wed, Jun 12, 2024 at 10:26 PM 'Siye Liu' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Yes, these tests will all pass if we enable the runtime flag
>>> `CaretPositionFromPoint`.
>>>
>>> The few Mozilla failures do represent their non-spec compliant behavior.
>>>
>>> Thanks,
>>> Siye
>>>
>>> On Wednesday, June 12, 2024 at 4:03:35 AM UTC-7 yoav...@chromium.org
>>> wrote:
>>>
>>>> On Thu, Jun 6, 2024 at 9:03 PM 'Siye Liu' via blink-dev <
>>>> blin...@chromium.org> wrote:
>>>>
>>>>> Reviews requested.
>>>>>
>>>>> Thanks,
>>>>> Siye
>>>>>
>>>>> On Thursday, June 6, 2024 at 9:47:37 AM UTC-7 Chris Harrelson wrote:
>>>>>
>>>>>> Hi, please fill out these reviews on your chromestatus entry:
>>>>>>
>>>>>> [image: image.png]
>>>>>>
>>>>>> On Wed, Jun 5, 2024 at 8:09 PM 'Siye Liu' via blink-dev <
>>>>>> blin...@chromium.org> wrote:
>>>>>>
>>>>>>> Yes, the API returns offset inside text input and textarea elements.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Siye
>>>>>>>
>>>>>>> On Wednesday, June 5, 2024 at 5:10:18 PM UTC-7 Brian Birtles wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Does this return the offset inside text input elements like Gecko's
>>>>>>>> implementation?
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Brian
>>>>>>>>
>>>>>>>> 2024年6月6日木曜日 3:20:24 UTC+9 si...@microsoft.com:
>>>>>>>>
>>>>>>>>> Contact emails
>>>>>>>>> si...@microsoft.com, sa...@microsoft.com
>>>>>>>>>
>>>>>>>>> Explainer
>>>>>>>>> None
>>>>>>>>>
>>>>>>>>> Specification
>>>>>>>>>
>>>>>>>>> https://drafts.csswg.org/cssom-view/#dom-document-caretpositionfrompoint
>>>>>>>>>
>>>>>>>>> Summary
>>>>>>>>> This new API allows users to get current caret position from a
>>>>>>>>> given screen point.
>>>>>>>>> The API returns a CaretPosition object which represents the caret
>>>>>>>>> position indicating current text insertion point including the 
>>>>>>>>> containing
>>>>>>>>> DOM node, caret's character offset, and the client rectangle of caret
>>>>>>>>> range. The API also supports get CaretPosition inside Shadow DOM. To 
>>>>>>>>> get
>>>>>>>>> CaretPosition inside Shadow DOM, caller needs to provide reference to 
>>>>>>>>> all
>>>>>>>>> the shadow roots that this API can pierce into.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Blink component
>>>>>>>>> Blink>CSS
>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>>>>>>>>
>>>>>>>>> TAG review
>>>>>>>>> document.caretPositionFromPoint API in shadow DOM scenario · Issue
>>>>>>>>> #949 · w3ctag/design-reviews (github.com)
>>>>>>>>> <https://github.com/w3ctag/design-reviews/issues/949>
>>>>>>>>>
>>>>>>>>> TAG review status
>>>>>>>>> Issues open
>>>>>>>>>
>>>>>>>>> Risks
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Interoperability and Compatibil

Re: [blink-dev] Re: Intent to Ship: document.caretPositionFromPoint API

2024-06-13 Thread Yoav Weiss (@Shopify)

LGTM2

On Thu, Jun 13, 2024, 10:32 Chris Harrelson  wrote:

> LGTM1
>
> On Wed, Jun 12, 2024 at 10:26 PM 'Siye Liu' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Yes, these tests will all pass if we enable the runtime flag
>> `CaretPositionFromPoint`.
>>
>> The few Mozilla failures do represent their non-spec compliant behavior.
>>
>> Thanks,
>> Siye
>>
>> On Wednesday, June 12, 2024 at 4:03:35 AM UTC-7 yoav...@chromium.org
>> wrote:
>>
>>> On Thu, Jun 6, 2024 at 9:03 PM 'Siye Liu' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
 Reviews requested.

 Thanks,
 Siye

 On Thursday, June 6, 2024 at 9:47:37 AM UTC-7 Chris Harrelson wrote:

> Hi, please fill out these reviews on your chromestatus entry:
>
> [image: image.png]
>
> On Wed, Jun 5, 2024 at 8:09 PM 'Siye Liu' via blink-dev <
> blin...@chromium.org> wrote:
>
>> Yes, the API returns offset inside text input and textarea elements.
>>
>> Thanks,
>> Siye
>>
>> On Wednesday, June 5, 2024 at 5:10:18 PM UTC-7 Brian Birtles wrote:
>>
>>> Hi,
>>>
>>> Does this return the offset inside text input elements like Gecko's
>>> implementation?
>>>
>>> Best regards,
>>>
>>> Brian
>>>
>>> 2024年6月6日木曜日 3:20:24 UTC+9 si...@microsoft.com:
>>>
 Contact emails
 si...@microsoft.com, sa...@microsoft.com

 Explainer
 None

 Specification

 https://drafts.csswg.org/cssom-view/#dom-document-caretpositionfrompoint

 Summary
 This new API allows users to get current caret position from a
 given screen point.

 The API returns a CaretPosition object which represents the caret
 position indicating current text insertion point including the 
 containing
 DOM node, caret's character offset, and the client rectangle of caret
 range. The API also supports get CaretPosition inside Shadow DOM. To 
 get
 CaretPosition inside Shadow DOM, caller needs to provide reference to 
 all
 the shadow roots that this API can pierce into.

 Blink component
 Blink>CSS

 TAG review
 document.caretPositionFromPoint API in shadow DOM scenario · Issue
 #949 · w3ctag/design-reviews (github.com)

 TAG review status
 Issues open

 Risks

 Interoperability and Compatibility
 Gecko already implemented the API without the argument that
 contains shadow roots that this API can pierce into. Webkit/Blink 
 didn't
 implement it. The Gecko implementation in shadow DOM scenario is not
 spec-compliant either (Spec changed recently to cover shadow DOM 
 scenario).
 Gecko 's position is positive on this API. We expect that Gecko's 
 behavior
 will be changed to be spec-compliant in the future. There is also a 
 future
 compat risk too if we decided to deprecate the non-standard API
 `document.caretRangeFromPoint`: https://crbug.com/690599

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

 *WebKit*: Support (
 https://github.com/WebKit/standards-positions/issues/301)

 *Web developers*: Positive (
 https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c34)
 Web developers are asking to have document.caretPositionFromPoint API
 implemented in Blink:
 https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c28
 https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c34

 *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

 https://github.com/web-platform-tests/wpt/blob/master/css/cssom/caretPositionFromPoint.html
 https://github.com/web-platform-tests/wpt/blob/master/shadow-dom/Document-caretPositionFromPoint.tentative.html

>>>
>>> Looking at
>>>

Re: [blink-dev] Intent to Ship: Support 'color-interpolation: linearrgb' on SVG gradients

LGTM2

On Wed, Jun 12, 2024 at 5:50 PM Chris Harrelson 
wrote:

> LGTM1
>
> On Tue, Jun 11, 2024 at 10:23 AM Fredrik Söderquist  wrote:
>
>> On Tue, Jun 11, 2024 at 6:08 AM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>>
>>>
>>> On Mon, Jun 10, 2024 at 11:25 AM Fredrik Söderquist 
>>> wrote:
>>>
>>>> Contact email...@opera.com
>>>>
>>>> ExplainerNone
>>>>
>>>> Specification
>>>> https://svgwg.org/svg2-draft/painting.html#ColorInterpolation
>>>>
>>>> Summary
>>>>
>>>> Allows SVG gradients to interpolate in a linear-light sRGB color space.
>>>> Currently all SVG gradients interpolate in a gamma-encoded sRGB color 
>>>> space.
>>>>
>>>>
>>>> Blink componentBlink>SVG
>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESVG>
>>>>
>>>> Search tagsSVG <https://chromestatus.com/features#tags:SVG>, CSS
>>>> <https://chromestatus.com/features#tags:CSS>, Color
>>>> <https://chromestatus.com/features#tags:Color>
>>>>
>>>> TAG reviewNone
>>>>
>>>> TAG review statusNot applicable
>>>>
>>>> Risks
>>>>
>>>>
>>>> Interoperability and Compatibility
>>>>
>>>> The risk along both axes is fairly low since the difference is in
>>>> rendering only (even if the rendering can differ quite significantly).
>>>>
>>>>
>>>> *Gecko*: Shipped/Shipping (
>>>> https://www.mozilla.org/en-US/firefox/123.0/releasenotes)
>>>>
>>>> *WebKit*: No signal
>>>>
>>>
>>> Can you file for a signal?
>>>
>>
>>  https://github.com/WebKit/standards-positions/issues/362
>>
>>
>>>
>>>> *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
>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>> ?Yes
>>>>
>>>>
>>>> https://wpt.fyi/results/svg/pservers/reftests/gradient-color-interpolation.svg
>>>>
>>>>
>>>> Flag name on chrome://flagsNone
>>>>
>>>> Finch feature nameSvgGradientColorInterpolationLinearRgbSupport
>>>>
>>>> Requires code in //chrome?False
>>>>
>>>> Tracking bughttps://issues.chromium.org/issues/324440102
>>>>
>>>> Estimated milestones
>>>> Shipping on desktop 127
>>>> Shipping on Android 127
>>>> Shipping on WebView 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/5131849549742080?gate=6228725141340160
>>>>
>>>> This intent message was generated by Chrome Platform Status
>>>> <https://chromestatus.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/CAHediLSkF96MOwMyoU7FbrF14-fy_3TfMD-JNdjn-DqO5o1X4w%40mail.gmail.com
>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHediLSkF96MOwMyoU7FbrF14-fy_3TfMD-JNdjn-DqO5o1X4w%40mail.gmail.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHediLQJvPU6Fiu6viXSb0yQL-Yg_Qyr9wLu6dgzL3vJbdL4tg%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHediLQJvPU6Fiu6viXSb0yQL-Yg_Qyr9wLu6dgzL3vJbdL4tg%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

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

Re: [blink-dev] Intent to Ship: WebAuthn hints

On Mon, Jun 3, 2024 at 10:59 PM Adam Langley  wrote:

> Contact emails...@chromium.org
>
> Specificationhttps://w3c.github.io/webauthn/#enum-hints
>
> Summary
>
> The new `hints` parameter[1] in WebAuthn requests allows sites to provide
> guidance to browsers to guide their UI. The canonical use case are
> enterprises which know that their internal sites use only security keys and
> want to be able to communicate that so that browsers focus the UI on that
> case. But hints also resolve a tension where the current
> `authenticatorAttachment` parameter is strict: setting it to `platform`
> excludes all cross-platform options and vice versa. This has proven less
> than ideal in some cases. [1] https://w3c.github.io/webauthn/#enum-hints
>
>
> Blink componentBlink>WebAuthentication
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>

>
> Risks
>
>
> Interoperability and Compatibility
>
> None: new option which only tweaks UI.
>
> *Gecko*: No signal
>
> *WebKit*: No objections when asked in person.
>

Can you ask for positions? https://bit.ly/blink-signals


>
> *Web developers*: Positive. Several sites have requested this
> functionality, which motivated the spec change. They continue to want it
> and have done so for quite a while now.
>
> 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?
>
> No.
>
>
> Debuggability
>
> Not really. This causes the browser UI to switch emphasis, but doesn't
> other change any site-observable behaviour.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?
>
> On Android & Android WebView, support would require changes to other
> components: the android.credentials code in the framework and, for older
> Android versions, Play Services. That might come in the future, but it's
> not part of the Blink and Chrome work. (The Blink change is, of course,
> required for anything else in the system to be able to handle this
> parameter.)
>
>
> Some versions of Windows handle WebAuthn UI themselves and, while Chrome
> can change it's UI, this parameter won't immediately change the Windows UI.
> However, Microsoft is positive about this change and Chromium will be
> updated to pass this parameter on as soon as the Windows API is able to
> receive it.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> Hints only affect the browser UI and unknown parameters are ignored in
> WebAuthn already.
>
>
> Flag name on chrome://flagsNone
>
>
> Finch feature nameWebAuthenticationHints
>
> Requires code in //chrome?True: Chrome-specific WebAuthn UI is handled in
> //chrome and needs to respond to these hints. Other embedders would have to
> do the same to benefit from this change.
>
> Estimated milestones
> Shipping on desktop 128
>
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project for the feature specification) whose resolution may
> introduce web compat/interop risk (e.g., changing to naming or structure of
> the API in a non-backward-compatible way).
> None
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5145737733341184?gate=5155815622443008
>
> --
> 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/CAL9PXLzcnJ9xLwJZzQJBL0UJdnDGb7tB5Uu7cYqB%2Bdcdb%2BCfTQ%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/CAOmohSL%3D0-Yp1NE447K6Tm4jaQYCadxSqvsc%2Bfw%3DZDERd91Fyw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Attribution Reporting Feature: Aggregate Debug Reporting

LGTM1

On Wed, Jun 12, 2024 at 5:21 PM Nan Lin  wrote:

> Hi Yoav,
>
> The list of debugging signals is part of the spec:
>
> https://wicg.github.io/attribution-reporting-api/#source-debug-data-type
> https://wicg.github.io/attribution-reporting-api/#trigger-debug-data-type
>

Awesome, thanks!


>
>
> Thanks,
> Nan
>
> On Wednesday, June 12, 2024 at 4:27:41 AM UTC-4 Yoav Weiss wrote:
>
>> On Tue, Jun 11, 2024 at 7:43 PM Akash Nadan 
>> wrote:
>>
>>> Hi Yoav,
>>>
>>> The debug signals that will be reported on are documented here:
>>> https://github.com/WICG/attribution-reporting-api/blob/main/verbose_debugging_reports.md
>>>
>>
>> Thanks! Should that be part of the spec?
>>
>>
>>>
>>> These are the same debug signals that current debug reports support. We
>>> plan to support the same set of debug signals in this new feature as well.
>>>
>>
>>> These debug signals are not developer defined, however a developer can
>>> specify which of the signals they want to track and can group certain
>>> signals together (more details here
>>> <https://github.com/WICG/attribution-reporting-api/blob/main/aggregate_debug_reporting.md#opting-in-aggregate-debug-reporting>
>>> ).
>>>
>>> Thanks,
>>> Akash
>>> On Monday, June 10, 2024 at 10:02:08 PM UTC-7 Yoav Weiss (@Shopify)
>>> wrote:
>>>
>>>> On Fri, Jun 7, 2024 at 8:12 PM 'Akash Nadan' via blink-dev <
>>>> blin...@chromium.org> wrote:
>>>>
>>>>> Contact emails
>>>>>
>>>>> akash...@google.com, lin...@chromium.org, john...@chromium.org
>>>>>
>>>>> Explainer
>>>>>
>>>>> Attribution Reporting with event-level reports
>>>>> <https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md>
>>>>>
>>>>> Attribution Reporting API with Aggregatable Reports
>>>>> <https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATE.md>
>>>>>
>>>>> Aggregation Service for the Attribution Reporting API
>>>>> <https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATION_SERVICE_TEE.md>
>>>>>
>>>>> Specification
>>>>>
>>>>> https://wicg.github.io/attribution-reporting-api/
>>>>>
>>>>> Blink component
>>>>>
>>>>> Internals > AttributionReporting
>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EAttributionReporting>
>>>>>
>>>>> TAG review
>>>>>
>>>>> Still under review
>>>>> <https://github.com/w3ctag/design-reviews/issues/724> under the
>>>>> original I2S for the Attribution Reporting API
>>>>>
>>>>> TAG review status
>>>>>
>>>>> Pending
>>>>>
>>>>> Summary
>>>>>
>>>>> We are landing the following changes to the Attribution Reporting API
>>>>> focused on:
>>>>>
>>>>>-
>>>>>
>>>>>improving debugging capabilities
>>>>>
>>>>>
>>>>> This change is based on ad-tech feedback and the need to support
>>>>> debugging capabilities after third-party cookie deprecation.
>>>>>
>>>>> Currently the API supports debug reports that are tied to third-party
>>>>> cookies. In order for an API caller to receive a debug report of any kind
>>>>> they need to make sure a specific third-party cookie (i.e. ar_debug) is
>>>>> properly set. The API will check to make sure this cookie is set before
>>>>> providing any kind of debug report. Once third-party cookies are 
>>>>> deprecated
>>>>> these debug reports will no longer be available.
>>>>>
>>>>> This change is so the API can continue to provide debugging
>>>>> information after third-party cookie deprecation when the current debug
>>>>> reports that are tied to third-party cookies are no longer available. This
>>>>> is a new report type that is not tied to third-party cookies and provides
>>>>> similar debug information. This feature allows API callers to request and
>>>>> receive debug signals in aggregate form. This feature is very similar to
>>>>&

Re: [blink-dev] Intent to Experiment: WebGPU Subgroups experimentation

Please kick-off the chrome status reviews on Privacy, Security and
Debuggability before turning on the experiment.

On Wed, Jun 12, 2024 at 4:13 PM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

> LGTM to experiment M128-131 inclusive
>
> On Wed, Jun 12, 2024 at 4:11 PM Alan Baker  wrote:
>
>> I've updated the feature. We'd like to start in milestone 128 for 4
>> milestones.
>>
>> On Wed, Jun 12, 2024 at 6:06 AM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>> What milestones do you want the experiment to run?
>>>
>>> On Tue, Jun 11, 2024 at 9:02 PM 'Alan Baker' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
>>>> Contact emailsalanba...@google.com
>>>>
>>>> Explainer
>>>> https://github.com/gpuweb/gpuweb/blob/main/proposals/subgroups.md
>>>>
>>>> SpecificationNone
>>>>
>>>> Summary
>>>>
>>>> Adds subgroup functionality to WebGPU. Subgroup operations perform SIMT
>>>> operations to provide efficient communication and data sharing among groups
>>>> of invocations. These operations can be used to accelerate applications by
>>>> reducing memory overheads incurred by inter-invocation communication.
>>>>
>>>>
>>>> Blink componentBlink>WebGPU
>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebGPU>
>>>>
>>>> TAG reviewNone
>>>>
>>>> TAG review statusPending
>>>>
>>>> Risks
>>>>
>>>>
>>>> Interoperability and Compatibility
>>>>
>>>> None
>>>>
>>>>
>>>> *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
>>>>
>>>>
>>>> Goals for experimentation
>>>>
>>>> We wish to more broadly test portability, performance, and reach beyond
>>>> our accessible test devices. We have partners that could leverage these
>>>> features in existing products to provide feedback. For example, Mediapipe
>>>> would be able to leverage this feature easily.
>>>>
>>>> We also wish to gather feedback to help shape the API and answer the
>>>> following questions:
>>>> * Which parts are essential?
>>>> * What additions would make a meaningful impact?
>>>> * Can we mitigate non-portable behaviours for common usages?
>>>>
>>>> Ongoing technical constraints
>>>>
>>>> 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
>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>> ?No
>>>>
>>>> Flag name on chrome://flagsNone
>>>>
>>>> Finch feature nameNone
>>>>
>>>> Non-finch justificationNone
>>>>
>>>> Requires code in //chrome?False
>>>>
>>>> Estimated milestones
>>>>
>>>> No milestones specified
>>>>
>>>>
>>>> Link to entry on the Chrome Platform Status
>>>> https://chromestatus.com/feature/5126409856221184
>>>>
>>>> This intent message was generated by Chrome Platform Status
>>>> <https://chromestatus.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/CABg%2BrB7%2B-cAZNO-mckZ%2BaK8D0ZPZ4iJYi1kmU%2Bt60i%3DFzvL-gw%40mail.gmail.com
>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg%2BrB7%2B-cAZNO-mckZ%2BaK8D0ZPZ4iJYi1kmU%2Bt60i%3DFzvL-gw%40mail.gmail.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>

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

Re: [blink-dev] Intent to Experiment: WebGPU Subgroups experimentation

LGTM to experiment M128-131 inclusive

On Wed, Jun 12, 2024 at 4:11 PM Alan Baker  wrote:

> I've updated the feature. We'd like to start in milestone 128 for 4
> milestones.
>
> On Wed, Jun 12, 2024 at 6:06 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>> What milestones do you want the experiment to run?
>>
>> On Tue, Jun 11, 2024 at 9:02 PM 'Alan Baker' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emailsalanba...@google.com
>>>
>>> Explainer
>>> https://github.com/gpuweb/gpuweb/blob/main/proposals/subgroups.md
>>>
>>> SpecificationNone
>>>
>>> Summary
>>>
>>> Adds subgroup functionality to WebGPU. Subgroup operations perform SIMT
>>> operations to provide efficient communication and data sharing among groups
>>> of invocations. These operations can be used to accelerate applications by
>>> reducing memory overheads incurred by inter-invocation communication.
>>>
>>>
>>> Blink componentBlink>WebGPU
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebGPU>
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusPending
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> None
>>>
>>>
>>> *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
>>>
>>>
>>> Goals for experimentation
>>>
>>> We wish to more broadly test portability, performance, and reach beyond
>>> our accessible test devices. We have partners that could leverage these
>>> features in existing products to provide feedback. For example, Mediapipe
>>> would be able to leverage this feature easily.
>>>
>>> We also wish to gather feedback to help shape the API and answer the
>>> following questions:
>>> * Which parts are essential?
>>> * What additions would make a meaningful impact?
>>> * Can we mitigate non-portable behaviours for common usages?
>>>
>>> Ongoing technical constraints
>>>
>>> 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
>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>> ?No
>>>
>>> Flag name on chrome://flagsNone
>>>
>>> Finch feature nameNone
>>>
>>> Non-finch justificationNone
>>>
>>> Requires code in //chrome?False
>>>
>>> Estimated milestones
>>>
>>> No milestones specified
>>>
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5126409856221184
>>>
>>> This intent message was generated by Chrome Platform Status
>>> <https://chromestatus.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/CABg%2BrB7%2B-cAZNO-mckZ%2BaK8D0ZPZ4iJYi1kmU%2Bt60i%3DFzvL-gw%40mail.gmail.com
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg%2BrB7%2B-cAZNO-mckZ%2BaK8D0ZPZ4iJYi1kmU%2Bt60i%3DFzvL-gw%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>>

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

Re: [blink-dev] Intent to Ship: Snap Events

LGTM1

This seems like a useful addition, with lots of developer demand. While
more detailed explainers would have been helpful, I don't feel it's a
blocker atm, as the demos provided helped me understand what we're shipping
and how developers will use it.

On Tue, Jun 11, 2024 at 4:46 PM Adam Argyle  wrote:

> Slightly different strategy to share a public photo
> https://photos.app.goo.gl/5vHQ4cecJqHWN7DGA, try this one?  
>
> On Tue, Jun 11, 2024 at 12:36 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>>
>>
>> On Fri, Jun 7, 2024 at 5:47 PM 'Adam Argyle' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Indeed, developer sentiment is full of excitement! Who wouldn't want to
>>> throw out their hyper intersection observers with a perfectly timed
>>> callback? or even better, getting insights into the concept of "changing"
>>> which is currently opaque to authors.
>>>
>>> > Philip: For the scrollsnapchange event it's easy to imagine updating
>>> some state below a carousel to match the snapped element, such as item
>>> description or store inventory. For scrollsnapchanging I don't dare hazard
>>> a guess, can someone say what the canonical use case for this is?
>>> I think you'll find that snapchanging is very prominent in mobile
>>> gesture based UI and may be used even more than snapchange. Like one of
>>> those features you can't unsee once you see it working. Consider this
>>> video I took of a game on mobile
>>> <https://photos.google.com/photo/AF1QipO6HUraOd43T9e7lPU4yXHOFX92r15vCX39DRAQ>
>>> ,
>>>
>>
>> It's 404ing for me..
>>
>>
>>> snapchanging and snapchanged are distinctly used for 2 separate moments
>>> of UI feedback. I have many examples like this! The examples are what led
>>> to the APIs. Another really common example will be revealing the caption or
>>> action buttons in a carousel. Which it's probably worth noting we're
>>> working on a CSS way to know some of this information too, we're
>>> prototyping snapped as a "state query."
>>>
>>> Here's a few demo's showing some "picker" use cases, which I feel will
>>> be the majority cases, where folks are observing the snapped or soon to be
>>> snapped item and updating ancillary UI for the user. I have a backlog of
>>> many more to make  Think of these things like snap triggered animation,
>>> which can be a very healthily compliment to scroll driven animation (which
>>> currently doesn't have a "trigger" feature, only linked).
>>>
>>> I bucket the 2 events like:
>>> - the *scrollsnapchanging* event is eager to provide user feedback, can
>>> fire many more times than change
>>> - while *scrollsnapchange* is great for user feedback after they've
>>> lifted their finger or scroll has ended, timed better for confirmation or
>>> whatever. I show an example below that I use change instead of changing so
>>> the animation trigger isn't too busy.
>>>
>>> *Color picker*:
>>> https://codepen.io/argyleink/pen/zYXdgew
>>>
>>> *Date time picker (both eager and timed):*
>>> https://codepen.io/argyleink/pen/WNageoZ
>>>
>>> *Date time picker (eager):*
>>> https://codepen.io/argyleink/pen/oNOWwKq
>>>
>>> *Date time picker (timed for view transitions):*
>>> https://codepen.io/argyleink/pen/LYvzGRW
>>>
>>> > Regarding origin trials:
>>> I havent met a front-end dev who's been interested in an origin
>>> trial, but fullstack or backend devs needing a high impact business feature
>>> (like a fugu feature) do. We didn't do an origin trial for scrollend
>>> <https://developer.chrome.com/blog/scrollend-a-new-javascript-event>,
>>> and that felt like the right path forward. Feels like these 2 events are in
>>> a similar bucket as scrollend.
>>>
>>> Let me know how else I can help!
>>>
>>> On Wed, Jun 5, 2024 at 7:40 PM Alex Russell 
>>> wrote:
>>>
>>>> Thanks for the link, Phillip. Absolutely agree that this is an unmet
>>>> need and something we should have added long ago; I'd just like to see
>>>> evidence that we're matching that need with a sufficient solution and that
>>>> we've done our homework. There's almost nothing worse than getting to the
>>>> end of a launch and realizing that some important use-cases isn't covered,
>>>> and I don't have confidence

Re: [blink-dev] Intent to Ship: Protected Audience - Fix implementation and spec for renderSize

LGTM1

This sounds like a web-exposed bug fix, and I agree that the risk seems low.

On Tue, Jun 11, 2024 at 6:10 PM 'Xiaochen Zhou' via blink-dev <
blink-dev@chromium.org> wrote:

> I have started the requests, thank you. This item was originated from a
> previous launch:
> https://chromestatus.com/feature/5140606359175168?gate=5143092244250624.
> This feature was added to the Protected Audience explainer, but was never
> implemented or spec'd. This launch implemented this missing feature and
> added it to the spec. Please refer to the previous launch for reviews,
> thank you.
>
> On Tuesday, June 11, 2024 at 11:36:28 AM UTC-4 vmp...@chromium.org wrote:
>
>> Hi,
>>
>> Can you please start the various reviews in chromestatus?
>> [image: chipsna.png]
>>
>> Thanks,
>> Vlad
>>
>> On Fri, Jun 7, 2024 at 11:10 AM 'Xiaochen Zhou' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> xiaoc...@google.com, shiva...@google.com, jka...@google.com
>>>
>>> Explainer
>>>
>>> https://github.com/WICG/turtledove/pull/1145
>>>
>>> Specification
>>>
>>> https://github.com/WICG/turtledove/pull/1141
>>>
>>> Design docs
>>>
>>>
>>> https://docs.google.com/document/d/1JSUZzEnVGn6Rz6ncLbyhThModoxTGnBn-jS5xJf4Aq0/edit?usp=sharing
>>>
>>> Summary
>>>
>>> We will complete the renderSize implementation to match what the
>>> Protected Audience explainer claims
>>> .
>>> The explainer states that if the Protected Audience generateBid function
>>> returns a render URL with size specified, then the browserSignals argument
>>> to the scoreAd function will have a renderSize field reflecting that size
>>> (so that all relevant information about the bid is available for scoring).
>>> However this was missed during implementation.
>>>
>>> Setting this field is unlikely to break existing usage as this field has
>>> been a part of the explainer for 7 months and has always been optional.
>>> renderSize is only passed into scoreAd(), as part of browserSignals, if
>>> generateBid() returned a width and height. If it is specified, script can
>>> check whether the fix is enabled by executing:
>>>
>>> 'renderSize' in browserSignals
>>>
>>> See Github issue  and
>>> explainer sections for renderSize
>>> 
>>> .
>>>
>>> Blink component
>>>
>>> Blink>InterestGroups
>>> 
>>>
>>> TAG review
>>>
>>> None
>>>
>>> TAG review status
>>>
>>> Not applicable
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> None
>>>
>>> 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
>>>
>>> Additional debugging capabilities are not necessary for these feature
>>> changes.
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, ChromeOS, Android, and Android WebView)?
>>>
>>> No
>>>
>>> Supported on all six Blink platforms except Android WebView.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> Yes, it is tested by
>>> third_party/blink/web_tests/external/wpt/fledge/tentative/score-ad-browser-signals.https.window.js.
>>>
>>> Flag name on chrome://flags
>>>
>>> None
>>>
>>> Finch feature name
>>>
>>> None
>>>
>>
Please add a runtime flag with a base feature for this, just in case this
turns out riskier than expected.


>
>>> Non-finch justification
>>>
>>> None
>>>
>>> Requires code in //chrome?
>>>
>>> False
>>>
>>> Tracking bug
>>>
>>> https://issues.chromium.org/u/1/issues/333628467
>>>
>>> Launch bug
>>>
>>> https://launch.corp.google.com/launch/4319084
>>>
>>> Estimated milestones
>>>
>>> No milestones specified
>>>
>>>
>>> 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/5181817440436224
>>>
>>> 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

Re: [blink-dev] Re: Intent to Ship: document.caretPositionFromPoint API

On Thu, Jun 6, 2024 at 9:03 PM 'Siye Liu' via blink-dev <
blink-dev@chromium.org> wrote:

> Reviews requested.
>
> Thanks,
> Siye
>
> On Thursday, June 6, 2024 at 9:47:37 AM UTC-7 Chris Harrelson wrote:
>
>> Hi, please fill out these reviews on your chromestatus entry:
>>
>> [image: image.png]
>>
>> On Wed, Jun 5, 2024 at 8:09 PM 'Siye Liu' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Yes, the API returns offset inside text input and textarea elements.
>>>
>>> Thanks,
>>> Siye
>>>
>>> On Wednesday, June 5, 2024 at 5:10:18 PM UTC-7 Brian Birtles wrote:
>>>
 Hi,

 Does this return the offset inside text input elements like Gecko's
 implementation?

 Best regards,

 Brian

 2024年6月6日木曜日 3:20:24 UTC+9 si...@microsoft.com:

> Contact emails
> si...@microsoft.com, sa...@microsoft.com
>
> Explainer
> None
>
> Specification
>
> https://drafts.csswg.org/cssom-view/#dom-document-caretpositionfrompoint
>
> Summary
> This new API allows users to get current caret position from a given
> screen point.
>
> The API returns a CaretPosition object which represents the caret
> position indicating current text insertion point including the containing
> DOM node, caret's character offset, and the client rectangle of caret
> range. The API also supports get CaretPosition inside Shadow DOM. To get
> CaretPosition inside Shadow DOM, caller needs to provide reference to all
> the shadow roots that this API can pierce into.
>
>
> Blink component
> Blink>CSS
> 
>
> TAG review
> document.caretPositionFromPoint API in shadow DOM scenario · Issue
> #949 · w3ctag/design-reviews (github.com)
> 
>
> TAG review status
> Issues open
>
> Risks
>
>
> Interoperability and Compatibility
> Gecko already implemented the API without the argument that contains
> shadow roots that this API can pierce into. Webkit/Blink didn't implement
> it. The Gecko implementation in shadow DOM scenario is not spec-compliant
> either (Spec changed recently to cover shadow DOM scenario). Gecko 's
> position is positive on this API. We expect that Gecko's behavior will be
> changed to be spec-compliant in the future. There is also a future compat
> risk too if we decided to deprecate the non-standard API
> `document.caretRangeFromPoint`: https://crbug.com/690599
>
>
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/1012)
>
> *WebKit*: Support (
> https://github.com/WebKit/standards-positions/issues/301)
>
> *Web developers*: Positive (
> https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c34) Web
> developers are asking to have document.caretPositionFromPoint API
> implemented in Blink:
> https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c28
> https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c34
>
> *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
>
>
> https://github.com/web-platform-tests/wpt/blob/master/css/cssom/caretPositionFromPoint.html
> https://github.com/web-platform-tests/wpt/blob/master/shadow-dom/Document-caretPositionFromPoint.tentative.html
>

Looking at
https://wpt.fyi/results/css/cssom/caretPositionFromPoint.html?label=experimental=master
and
https://wpt.fyi/results/shadow-dom/Document-caretPositionFromPoint.tentative.html?label=experimental=master,
I see that Chromium is failing all of them, due to the "test" status of the
relevant flag.

Are we passing the tests with the flag enabled? Do the few Mozilla failures
represent their deviation from the spec? Or something else?


>
> Flag name on chrome://flags
> None
>
> Finch feature name
> CaretPositionFromPoint
>
> Requires code in //chrome?
> False
>
> Tracking bug
> https://crbug.com/388976
>
> Estimated milestones
> Shipping on desktop
> 127
> DevTrial 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

Re: [blink-dev] Intent to Experiment: WebGPU Subgroups experimentation

What milestones do you want the experiment to run?

On Tue, Jun 11, 2024 at 9:02 PM 'Alan Baker' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emailsalanba...@google.com
>
> Explainerhttps://github.com/gpuweb/gpuweb/blob/main/proposals/subgroups.md
>
> SpecificationNone
>
> Summary
>
> Adds subgroup functionality to WebGPU. Subgroup operations perform SIMT
> operations to provide efficient communication and data sharing among groups
> of invocations. These operations can be used to accelerate applications by
> reducing memory overheads incurred by inter-invocation communication.
>
>
> Blink componentBlink>WebGPU
> 
>
> TAG reviewNone
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *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
>
>
> Goals for experimentation
>
> We wish to more broadly test portability, performance, and reach beyond
> our accessible test devices. We have partners that could leverage these
> features in existing products to provide feedback. For example, Mediapipe
> would be able to leverage this feature easily.
>
> We also wish to gather feedback to help shape the API and answer the
> following questions:
> * Which parts are essential?
> * What additions would make a meaningful impact?
> * Can we mitigate non-portable behaviours for common usages?
>
> Ongoing technical constraints
>
> 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
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5126409856221184
>
> 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/CABg%2BrB7%2B-cAZNO-mckZ%2BaK8D0ZPZ4iJYi1kmU%2Bt60i%3DFzvL-gw%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/CAOmohS%2B3TeUPu9xwnxkeXDc3h%2BvjNse0Vyb5MQT2oMBU-s9_bQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Attribution Reporting Feature: Aggregate Debug Reporting

On Tue, Jun 11, 2024 at 7:43 PM Akash Nadan  wrote:

> Hi Yoav,
>
> The debug signals that will be reported on are documented here:
> https://github.com/WICG/attribution-reporting-api/blob/main/verbose_debugging_reports.md
>

Thanks! Should that be part of the spec?


>
> These are the same debug signals that current debug reports support. We
> plan to support the same set of debug signals in this new feature as well.
>

> These debug signals are not developer defined, however a developer can
> specify which of the signals they want to track and can group certain
> signals together (more details here
> <https://github.com/WICG/attribution-reporting-api/blob/main/aggregate_debug_reporting.md#opting-in-aggregate-debug-reporting>
> ).
>
> Thanks,
> Akash
> On Monday, June 10, 2024 at 10:02:08 PM UTC-7 Yoav Weiss (@Shopify) wrote:
>
>> On Fri, Jun 7, 2024 at 8:12 PM 'Akash Nadan' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> akash...@google.com, lin...@chromium.org, john...@chromium.org
>>>
>>> Explainer
>>>
>>> Attribution Reporting with event-level reports
>>> <https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md>
>>>
>>> Attribution Reporting API with Aggregatable Reports
>>> <https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATE.md>
>>>
>>> Aggregation Service for the Attribution Reporting API
>>> <https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATION_SERVICE_TEE.md>
>>>
>>> Specification
>>>
>>> https://wicg.github.io/attribution-reporting-api/
>>>
>>> Blink component
>>>
>>> Internals > AttributionReporting
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EAttributionReporting>
>>>
>>> TAG review
>>>
>>> Still under review <https://github.com/w3ctag/design-reviews/issues/724>
>>> under the original I2S for the Attribution Reporting API
>>>
>>> TAG review status
>>>
>>> Pending
>>>
>>> Summary
>>>
>>> We are landing the following changes to the Attribution Reporting API
>>> focused on:
>>>
>>>-
>>>
>>>improving debugging capabilities
>>>
>>>
>>> This change is based on ad-tech feedback and the need to support
>>> debugging capabilities after third-party cookie deprecation.
>>>
>>> Currently the API supports debug reports that are tied to third-party
>>> cookies. In order for an API caller to receive a debug report of any kind
>>> they need to make sure a specific third-party cookie (i.e. ar_debug) is
>>> properly set. The API will check to make sure this cookie is set before
>>> providing any kind of debug report. Once third-party cookies are deprecated
>>> these debug reports will no longer be available.
>>>
>>> This change is so the API can continue to provide debugging information
>>> after third-party cookie deprecation when the current debug reports that
>>> are tied to third-party cookies are no longer available. This is a new
>>> report type that is not tied to third-party cookies and provides similar
>>> debug information. This feature allows API callers to request and receive
>>> debug signals in aggregate form. This feature is very similar to current
>>> Aggregate Reports supported by the API, except these new reports will be
>>> specifically for debug signals.
>>>
>>
>> Can you expand on what debug signals are being aggregated? Are they
>> developer-defined somehow?
>>
>>
>>>
>>> This new feature will allow API callers to continue receiving debugging
>>> information even after third-party cookie deprecation.
>>>
>>> Explainer/Spec changes
>>>
>>>1.
>>>
>>>Explainer:
>>>
>>> https://github.com/WICG/attribution-reporting-api/blob/main/aggregate_debug_reporting.md
>>>2.
>>>
>>>Spec:
>>>1.
>>>
>>>   https://github.com/WICG/attribution-reporting-api/pull/1310
>>>   2.
>>>
>>>   https://github.com/WICG/attribution-reporting-api/pull/1292
>>>
>>>
>>> Risks
>>> Interoperability and Compatibility
>>>
>>> This is an optional and fully backwards compatible change. This feature
>>> provides a new mechanism for receivin

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

2024-06-11 Thread Yoav Weiss (@Shopify)

;>> Below are the auto generated intent content:
>>>>>>>>>>> Contact emailsfbeauf...@chromium.org, mlamo...@chromium.org,
>>>>>>>>>>> jiami...@chromium.org
>>>>>>>>>>>
>>>>>>>>>>> ExplainerNone
>>>>>>>>>>>
>>>>>>>>>>> Specification
>>>>>>>>>>> https://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
>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EMedia%3EPictureInPicture>
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>&

Re: [blink-dev] Intent to Ship: Snap Events

2024-06-11 Thread Yoav Weiss (@Shopify)

On Fri, Jun 7, 2024 at 5:47 PM 'Adam Argyle' via blink-dev <
blink-dev@chromium.org> wrote:

> Indeed, developer sentiment is full of excitement! Who wouldn't want to
> throw out their hyper intersection observers with a perfectly timed
> callback? or even better, getting insights into the concept of "changing"
> which is currently opaque to authors.
>
> > Philip: For the scrollsnapchange event it's easy to imagine updating
> some state below a carousel to match the snapped element, such as item
> description or store inventory. For scrollsnapchanging I don't dare hazard
> a guess, can someone say what the canonical use case for this is?
> I think you'll find that snapchanging is very prominent in mobile gesture
> based UI and may be used even more than snapchange. Like one of those
> features you can't unsee once you see it working. Consider this video I
> took of a game on mobile
> 
> ,
>

It's 404ing for me..


> snapchanging and snapchanged are distinctly used for 2 separate moments of
> UI feedback. I have many examples like this! The examples are what led to
> the APIs. Another really common example will be revealing the caption or
> action buttons in a carousel. Which it's probably worth noting we're
> working on a CSS way to know some of this information too, we're
> prototyping snapped as a "state query."
>
> Here's a few demo's showing some "picker" use cases, which I feel will be
> the majority cases, where folks are observing the snapped or soon to be
> snapped item and updating ancillary UI for the user. I have a backlog of
> many more to make  Think of these things like snap triggered animation,
> which can be a very healthily compliment to scroll driven animation (which
> currently doesn't have a "trigger" feature, only linked).
>
> I bucket the 2 events like:
> - the *scrollsnapchanging* event is eager to provide user feedback, can
> fire many more times than change
> - while *scrollsnapchange* is great for user feedback after they've
> lifted their finger or scroll has ended, timed better for confirmation or
> whatever. I show an example below that I use change instead of changing so
> the animation trigger isn't too busy.
>
> *Color picker*:
> https://codepen.io/argyleink/pen/zYXdgew
>
> *Date time picker (both eager and timed):*
> https://codepen.io/argyleink/pen/WNageoZ
>
> *Date time picker (eager):*
> https://codepen.io/argyleink/pen/oNOWwKq
>
> *Date time picker (timed for view transitions):*
> https://codepen.io/argyleink/pen/LYvzGRW
>
> > Regarding origin trials:
> I havent met a front-end dev who's been interested in an origin trial, but
> fullstack or backend devs needing a high impact business feature (like a
> fugu feature) do. We didn't do an origin trial for scrollend
> , and
> that felt like the right path forward. Feels like these 2 events are in a
> similar bucket as scrollend.
>
> Let me know how else I can help!
>
> On Wed, Jun 5, 2024 at 7:40 PM Alex Russell 
> wrote:
>
>> Thanks for the link, Phillip. Absolutely agree that this is an unmet need
>> and something we should have added long ago; I'd just like to see evidence
>> that we're matching that need with a sufficient solution and that we've
>> done our homework. There's almost nothing worse than getting to the end of
>> a launch and realizing that some important use-cases isn't covered, and I
>> don't have confidence based on what we've produced that we would not end up
>> in this situation.
>>
>> An exhaustive explainer with considered alternatives and sample code
>> would unblock this from my end.
>>
>> Best,
>>
>> Alex
>>
>> On Wednesday, June 5, 2024 at 9:48:48 AM UTC-7 David Awogbemila wrote:
>>
>>>
>>> Hi Alex, thanks for yout input!
>>>
>>> (Like Tab said, we’re planning to have a review of the feature as a
>>> whole so I plan to share any feedback from that here, but since that 
>>> won’t
>>> happen for at least another week, I wanted to update this thread in the
>>> meantime.)
>>>
>>> I'm now hosting the explainer
>>> 
>>> and I've updated it to reflect the research and investigation which went
>>> into the API design (which I certainly should have done earlier). We've
>>> discussed all of the non-trivial decisions made for the API over many 
>>> CSSWG
>>> issues
>>> .
>>> The API choices reflect the minimum amount of information that meets the
>>> needs of use cases we have evidence
>>> 
>>> of interest in: the element that was selected as the snap target, and
>>> deferred adding other bits of information for which we

Re: [blink-dev] Intent to Ship: Attribution Reporting Feature: Aggregate Debug Reporting

2024-06-10 Thread Yoav Weiss (@Shopify)

On Fri, Jun 7, 2024 at 8:12 PM 'Akash Nadan' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> akashna...@google.com, lin...@chromium.org, johni...@chromium.org
>
> Explainer
>
> Attribution Reporting with event-level reports
> 
>
> Attribution Reporting API with Aggregatable Reports
> 
>
> Aggregation Service for the Attribution Reporting API
> 
>
> Specification
>
> https://wicg.github.io/attribution-reporting-api/
>
> Blink component
>
> Internals > AttributionReporting
> 
>
> TAG review
>
> Still under review 
> under the original I2S for the Attribution Reporting API
>
> TAG review status
>
> Pending
>
> Summary
>
> We are landing the following changes to the Attribution Reporting API
> focused on:
>
>-
>
>improving debugging capabilities
>
>
> This change is based on ad-tech feedback and the need to support debugging
> capabilities after third-party cookie deprecation.
>
> Currently the API supports debug reports that are tied to third-party
> cookies. In order for an API caller to receive a debug report of any kind
> they need to make sure a specific third-party cookie (i.e. ar_debug) is
> properly set. The API will check to make sure this cookie is set before
> providing any kind of debug report. Once third-party cookies are deprecated
> these debug reports will no longer be available.
>
> This change is so the API can continue to provide debugging information
> after third-party cookie deprecation when the current debug reports that
> are tied to third-party cookies are no longer available. This is a new
> report type that is not tied to third-party cookies and provides similar
> debug information. This feature allows API callers to request and receive
> debug signals in aggregate form. This feature is very similar to current
> Aggregate Reports supported by the API, except these new reports will be
> specifically for debug signals.
>

Can you expand on what debug signals are being aggregated? Are they
developer-defined somehow?


>
> This new feature will allow API callers to continue receiving debugging
> information even after third-party cookie deprecation.
>
> Explainer/Spec changes
>
>1.
>
>Explainer:
>
> https://github.com/WICG/attribution-reporting-api/blob/main/aggregate_debug_reporting.md
>2.
>
>Spec:
>1.
>
>   https://github.com/WICG/attribution-reporting-api/pull/1310
>   2.
>
>   https://github.com/WICG/attribution-reporting-api/pull/1292
>
>
> Risks
> Interoperability and Compatibility
>
> This is an optional and fully backwards compatible change. This feature
> provides a new mechanism for receiving debugging information and does not
> break any pre-existing API or web functionality.
>
> Gecko: No signal (Original request:
> https://github.com/mozilla/standards-positions/issues/791)
>
> WebKit: No signal (Original request:
> https://github.com/WebKit/standards-positions/issues/180)
>
> Web developers:
> https://github.com/WICG/attribution-reporting-api/issues/705
>
>
> 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?
>
> No
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> The attribution reporting feature will be supported on all platforms with
> the exception of Android WebView
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes
>
> Estimated milestones
>
> This feature is anticipated to ship as part of Chrome 127
> .
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5086433709916160
>
> Links to previous Intent discussions
>
> Previous I2S:
>
> Intent to Ship: Attribution Reporting API
> 
>
> Intent to Ship: Attribution Reporting features M117
> 
>
> Intent to Ship: Attribution Reporting features M118
> 
>
> Intent to Ship: Attribution Reporting features M119
> 
>
> Intent to Ship: Attribution Reporting features M120
> 
>
> Intent to Ship: Attribution Reporting features M121
>

Re: [blink-dev] Intent to Ship: Support 'color-interpolation: linearrgb' on SVG gradients

2024-06-10 Thread Yoav Weiss (@Shopify)

On Mon, Jun 10, 2024 at 11:25 AM Fredrik Söderquist  wrote:

> Contact email...@opera.com
>
> ExplainerNone
>
> Specificationhttps://svgwg.org/svg2-draft/painting.html#ColorInterpolation
>
> Summary
>
> Allows SVG gradients to interpolate in a linear-light sRGB color space.
> Currently all SVG gradients interpolate in a gamma-encoded sRGB color space.
>
>
> Blink componentBlink>SVG
> 
>
> Search tagsSVG , CSS
> , Color
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> The risk along both axes is fairly low since the difference is in
> rendering only (even if the rendering can differ quite significantly).
>
>
> *Gecko*: Shipped/Shipping (
> https://www.mozilla.org/en-US/firefox/123.0/releasenotes)
>
> *WebKit*: No signal
>

Can you file for a 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)?Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
>
> https://wpt.fyi/results/svg/pservers/reftests/gradient-color-interpolation.svg
>
>
> Flag name on chrome://flagsNone
>
> Finch feature nameSvgGradientColorInterpolationLinearRgbSupport
>
> Requires code in //chrome?False
>
> Tracking bughttps://issues.chromium.org/issues/324440102
>
> Estimated milestones
> Shipping on desktop 127
> Shipping on Android 127
> Shipping on WebView 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/5131849549742080?gate=6228725141340160
>
> 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/CAHediLSkF96MOwMyoU7FbrF14-fy_3TfMD-JNdjn-DqO5o1X4w%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/CAOmohS%2B9dhgDZ66WMN2EAQtcqtG0TQNPAaQzA5fnBnpYT2yZUQ%40mail.gmail.com.

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

2024-06-10 Thread Yoav Weiss (@Shopify)

LGTM2

On Mon, Jun 10, 2024 at 8:41 PM Mike Taylor  wrote:

> On 6/4/24 1:53 PM, Caleb Raitto wrote:
>
> Response inline
>
> On Monday, June 3, 2024 at 10:16:06 PM UTC-4 Mike Taylor wrote:
>
> On 5/31/24 11:40 PM, Paul Jensen wrote:
>
> Contact emails
>
> pauljen...@chromium.org
>
>
> Explainer
>
> https://github.com/WICG/turtledove/pull/1095
>
>
> Specification
>
> https://github.com/WICG/turtledove/pull/1124
>
>
> Summary
>
> The Protected Audience API allows bidders to store information, called an
> interest group, from a single site in the browser that can only be read
> later in the context of an auction.  Today, interest groups can be updated
> by fetching new values from a server.  For all interest groups, the
> frequency of these updates is rate limited to at most once a day to
> conserve network traffic and avoid overwhelming servers.  However, we've
> heard from developers that certain ad campaigns need much more timely
> updates.  During Protected Audience auctions, the browser fetches real-time
> signals from bidders' key-value servers.  This proposal allows the response
> to these fetches to indicate a subset of interest groups they’d like
> updated more frequently than once a day.
>
>
> Blink component
>
> Blink>InterestGroups
> 
>
>
> TAG review
>
> For Protected Audience: https://github.com/w3ctag/
> design-reviews/issues/723
>
>
> TAG review status
>
> Completed for Protected Audience, resolved unsatisfied.
>
>
> Risks Interoperability and Compatibility
>
> Feature represents optional new behavior that shouldn’t break existing
> usage.
>
>
> Gecko & WebKit: No signal on parent proposal, Protected Audience.  Asked
> in the Mozilla forum here
> , and in the
> Webkit forum here
> .
>
>
> Edge: Edge has announced plans to support the Ad Selection API
> 
> which shares much of its API surface with Protected Audience.
>
>
> Web developers:
>
> Feature requested by Microsoft in GitHub issue
> .
>
> I don't see any feedback from Microsoft on this design in the issue (just
> from Criteo, which seems inconclusive). Have they given feedback elsewhere?
>
>
> The response from Microsoft (ads) is here:
> https://github.com/WICG/turtledove/issues/729#issuecomment-1822190741 --
> it's the opening paragraph that starts with "I do think having a 'please
> refresh when this auction is over' lever is a clear improvement over the
> current situation from a functionality perspective".
>
> OK - thanks. I was hoping they might have responded elsewhere to your
> request for feedback from April
> 
> or May, but I don't see a reason to block on that.
>
> LGTM1
>
>
>
>
> Debuggability
>
> Protected Audience trusted bidding signals show up in the DevTools Network
> pane. Updates show up in the Application -> Storage -> Interest Groups
> DevTools pane.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?
>
> It will be supported on all platforms that support Protected Audience, so
> all but WebView.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes
> 
> .
>
>
> Flag name on chrome://flags
>
> None
>
>
> Finch feature name
>
> InterestGroupUpdateIfOlderThan
>
>
> Requires code in //chrome?
>
> False
>
>
> Estimated milestones
>
> Shipping on desktop and Android in M125.
>
>
> Anticipated spec changes
>
> None
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5162656775536640
>
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit https://groups.google.com/a/
> chromium.org/d/msgid/blink-dev/CABQTWr%3DWxOenJmSZ5oW%3DVDdJ9q1nwovSJdgPw_
> 91Fp3fkV01ew%40mail.gmail.com
> 
> .
>
> --
> 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

Re: [blink-dev] Intent to Deprecate and Remove: 0.0.0.0 for Private Network Access

2024-06-05 Thread Yoav Weiss (@Shopify)

LGTM2

On Wed, Jun 5, 2024 at 5:41 PM Daniel Bratell  wrote:

> LGTM1
>
> /Daniel
> On 2024-06-03 18:03, 'David Adrian' via blink-dev wrote:
>
> Contact emails l...@chromium.org
>
> Explainer None
>
> Specification https://wicg.github.io/private-network-access
>
> Summary
>
> We propose to block access to IP address 0.0.0.0 in advance of PNA
> completely rolling out. Chrome is deprecating direct access to private
> network endpoints from public websites as part of the Private Network
> Access (PNA) specification (
> https://developer.chrome.com/blog/private-network-access-preflight/).
> Services listening on the localhost (127.0.0.0/8) are considered private
> according to the specification (
> https://wicg.github.io/private-network-access/#ip-address-space-heading).
> Chrome's PNA protection (rolled out as part of
> https://chromestatus.com/feature/5436853517811712) can be bypassed using
> the IP address 0.0.0.0 to access services listening on the localhost on
> macOS and Linux. This can also be abused in DNS rebinding attacks targeting
> a web application listening on the localhost. Since 0.0.0.0 is not used in
> practice (and should not be used), but was overlooked during
> https://chromestatus.com/feature/5436853517811712, we're deprecating it
> separately from the rest of the private network requests deprecation. This
> will be a Finch (experimental) rollout, rather than a Developer Trial.
>
>
> Blink component Blink>SecurityFeature>CORS>PrivateNetworkAccess
> 
>
> Search tags security , 
> Private
> Network Access
> 
>
> TAG review None
>
> TAG review status Not applicable
>
> Chromium Trial Name PrivateNetworkAccessNullIpAddressAllowed
>
> Origin Trial documentation link https://crbug.com/1300021
>
> WebFeature UseCounter name kPrivateNetworkAccessNullIpAddress
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: Closed Without a Position (
> https://github.com/mozilla/standards-positions/issues/143)
>
> *WebKit*: Support (
> https://github.com/WebKit/standards-positions/issues/163)
>
> *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
>
>
> Goals for experimentation
>
> Ongoing technical constraints
>
> Eventually, all private network access will be limited according to the
> developing Private Network Access spec.
>
>
> 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 block-null-ip-address
>
> Finch feature name PrivateNetworkAccessNullIpAddress
>
> Requires code in //chrome? False
>
> Tracking bug https://crbug.com/1300021
>
> Estimated milestones
> Shipping on desktop 133
> Origin trial desktop first 127
> Origin trial desktop last 133
> DevTrial on desktop 127
> Shipping on Android 133
> OriginTrial Android last 133
> OriginTrial Android first 127
> DevTrial on Android 127
> Shipping on WebView 133
> OriginTrial webView last 133
> OriginTrial webView first 127
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5106143060033536
>
> 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/CAGkh42L-7xt9YY-jmq-G4-nuitqELpgqgnvECkbCoPpAWWMMjw%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/683cadae-9413-4125-9209-4ecfe1b812aa%40sarasas.se
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving

[blink-dev] Intent to Prototype: noopener-allow-popups COOP value

2024-06-05 Thread Yoav Weiss (@Shopify)

Contact emailsyoavwe...@chromium.org

Explainerhttps://gist.github.com/yoavweiss/c7b61e97e6f8d207be619f87ab96ead5

Specificationhttps://github.com/whatwg/html/pull/10394

Summary

Some origins can contain different applications with different levels of
security requirements. In those cases, it can be beneficial to prevent
scripts running in one application from being able to open and script pages
of another same-origin application. In such cases, it can be beneficial for
a document to ensure its opener cannot script it, even if the opener
document is a same-origin one. The `noopener-allow-popups`
Cross-Origin-Opener-Policy value will allow documents to define that.


Blink componentBlink


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

TAG review statusPending

Risks


Interoperability and Compatibility

Compatibility risk: As this feature adds a new COOP value, it doesn't run a
risk of colliding with existing values. Where we may see some risk is when
developers start using this value in ways that would surprise other teams
on their origins. (as they would no longer have scripting access to opened
documents) I don't expect that to happen often, and if it would it's
something that developers would find out at development time. So I don't
expect that to impact users. Interoperability risk: Too early to tell as
positions/PR was just filed.


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

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

*Web developers*: No signals

*Other signals*:

Security

None: https://gist.github.com/yoavweiss/3cb7283f56717f6dfe6da05009a27a65


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


Goals for experimentation



Ongoing technical constraints

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

?

It will be:
https://chromium-review.googlesource.com/c/chromium/src/+/5581251/8/third_party/blink/web_tests/external/wpt/html/cross-origin-opener-policy/coop-noopener-allow-popups.https.html


Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

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

Estimated milestones

No milestones specified


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

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/CAOmohSJj33d%3D0B0tNpD0qrYWzygx0i02bWdhbV3aSCgbjS3Ndw%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Importmap integrity

2024-06-04 Thread Yoav Weiss (@Shopify)

Thanks for the extra support :)

On Tue, Jun 4, 2024, 09:30 Daniel Bratell  wrote:

> Doh, make that a bonus LGTM4. Sorry for the confusion.
>
> /Daniel
> On 2024-06-04 09:29, Daniel Bratell wrote:
>
> LGTM3
>
> /Daniel
> On 2024-05-30 19:41, Vladimir Levin wrote:
>
> LGTM2
>
> On Wed, May 29, 2024 at 11:41 AM Mike Taylor 
> wrote:
>
>> LGTM1
>> On 5/24/24 3:13 PM, Yoav Weiss (@Shopify) wrote:
>>
>>
>>
>> On Fri, May 24, 2024 at 7:12 PM Panos Astithas 
>> wrote:
>>
>>>
>>>
>>> On Wed, May 22, 2024 at 2:16 AM Yoav Weiss (@Shopify) <
>>> yoavwe...@chromium.org> wrote:
>>>
>>>>
>>>>
>>>> On Wed, May 22, 2024 at 10:29 AM Yoav Weiss (@Shopify) <
>>>> yoavwe...@chromium.org> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tuesday, May 21, 2024 at 1:04:44 PM UTC+2 Yoav Weiss wrote:
>>>>>
>>>>> Contact emailsyoavwe...@chromium.org
>>>>>
>>>>> Explainerhttps://github.com/guybedford/import-maps-extensions#
>>>>> integrity
>>>>>
>>>>> Specificationhttps://github.com/whatwg/html/pull/10269
>>>>>
>>>>> The PR is ready to land, but we're holding off on that for 2 weeks at
>>>>> Mozilla's request. See below.
>>>>>
>>>>> Summary
>>>>>
>>>>> Imported ES modules can't currently have their integrity checked, and
>>>>> hence cannot run in environments that require Subresource Integrity or 
>>>>> with
>>>>> `require-sri-for` CSP directives. This feature adds an `integrity` section
>>>>> to import maps, enabling developers to map ES module URLs to their
>>>>> integrity metadata, and ensure they only load when they match their
>>>>> expected hashes.
>>>>>
>>>>>
>>>>> Blink componentBlink>Loader
>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELoader>
>>>>>
>>>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/944
>>>>>
>>>>> TAG review statusIssues addressed
>>>>>
>>>>> Risks
>>>>>
>>>>>
>>>>> Interoperability and Compatibility
>>>>>
>>>>> On the interoperability front, this got a positive position from
>>>>> WebKit, and I'm implementing the feature there
>>>>> <https://github.com/whatwg/html/pull/10269>. Mozilla didn't object to
>>>>> the feature, but asked
>>>>> <https://docs.google.com/document/d/1iaarr4Ho715CUULrvi_LD3TwshAcN2odDLBBEK0FjH0/edit#bookmark=id.li7pdpi5uloq>
>>>>>
>>>>>
>>>> I just realized that the meeting notes are not publicly viewable.
>>>> +Panos Astithas  - would you be able to open
>>>> them up to the public somehow? (e.g. as a Chromium.org doc)
>>>>
>>>
>>> They were published
>>> <https://github.com/whatwg/html/issues/10340#:~:text=Benjamin%3A%20I%27d%20like%20a%20further%20two%20weeks>
>>>  that
>>> same day, we try to post the minutes publicly in less than 24 hours.
>>>
>>
>> Oops!! My bad for using the wrong artifact!
>>
>>
>>>
>>>>
>>>>
>>>>> for a couple more weeks to evaluate it and provide a position, as they
>>>>> might be planning broader-scope work on the front of application 
>>>>> integrity,
>>>>> and want to make sure this doesn't collide with it.
>>>>>
>>>>>
>>>>> On the compatibility front, the feature is polyfilled
>>>>> <https://github.com/guybedford/es-module-shims/pull/424>, but it's turned
>>>>> off for browsers that support import maps
>>>>> <https://github.com/guybedford/es-module-shims#:~:text=The%20ES%20Module%20Shims%20polyfill%20will%20analyze%20the%20browser%20to%20see%20if%20it%20supports%20import%20maps.%20If%20it%20does%2C%20it%20doesn%27t%20do%20anything%20more>
>>>>> .
>>>>>
>>>>>
>>>>> Adding Guy Bedford, the polyfill author to this thread. Guy, can you
>>>>> confirm this is the case?
>>>>>
>>>>> *Gecko*: No signal
>>>>> <https://github.com/mozilla/standards-positions/issues/1010>
>>>>>
>>>>

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

2024-05-31 Thread Yoav Weiss (@Shopify)

LGTM2

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

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

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

 Best,
 Jiaming

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

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

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

 Best,

 Alex

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

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

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

2024-05-31 Thread Yoav Weiss (@Shopify)

LGTM2

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

> In that case, LGTM1.
>
> On Fri, May 31, 2024 at 2:31 PM François Beaufort 
> wrote:
>
>>
>>
>> On Fri, May 31, 2024 at 3:16 AM Domenic Denicola 
>> wrote:
>>
>>>
>>>
>>> On Thursday, May 30, 2024 at 1:34:03 PM UTC+9 fbea...@google.com wrote:
>>>
>>> Contact emailsfbeauf...@google.com
>>>
>>> ExplainerNone
>>>
>>> Specificationhttps://gpuweb.github.io/gpuweb/#dom-gpuadapter-info
>>>
>>> Summary
>>>
>>> Functionality added to the WebGPU spec after its first shipment in a
>>> browser. Adds a synchronous GPUAdapter info attribute to retrieve the same
>>> information about the physical adapter as with the asynchronous GPUAdapter
>>> requestAdapterInfo() method. A separate Intent will be sent to deprecate
>>> and remove the asynchronous GPUAdapter requestAdapterInfo() method.
>>>
>>>
>>> Blink componentBlink>WebGPU
>>> 
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> The GPUAdapter info attribute has not yet been implemented in any
>>> browser. It has been approved by the GPU for the Web Community Group, with
>>> representatives from Chrome, Firefox, and Safari. See minutes at
>>> https://github.com/gpuweb/gpuweb/wiki/GPU-Web-2024-05-
>>> 22#add-synchronous-gpuadapterinfo-4550
>>>
>>>
>>> *Gecko*: No signal (https://github.com/mozilla/
>>> standards-positions/issues/1033)
>>>
>>>
>>> *WebKit*: Closed Without a Position (https://github.com/WebKit/
>>> standards-positions/issues/294#issuecomment-1877411933)
>>>
>>> *Web developers*: Positive (https://github.com/gpuweb/gpuweb/issues/4536
>>> )
>>>
>>> *Other signals*:
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> None
>>>
>>>
>>> Debuggability
>>>
>>> None
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, ChromeOS, Android, and Android WebView)?No
>>>
>>> All platforms will eventually have support. Will immediately be
>>> available on Android, Android WebView, ChromeOS, Mac, and Windows, since
>>> those platforms already support WebGPU. Linux is planned to have WebGPU
>>> support in the future, so this feature will become available when WebGPU
>>> does.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?Yes
>>>
>>> See https://github.com/gpuweb/cts/pull/3679 WebGPU/WGSL have a
>>> conformance test suite (https://github.com/gpuweb/cts) that is
>>> regularly pulled into Chromium and part of the testing of Dawn/Tint in
>>> Chromium.
>>>
>>>
>>> Flag name on chrome://flagsNone
>>>
>>> Finch feature nameNone
>>>
>>>
>>> Per
>>> https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md#when-is-a-flag-required
>>> , a feature flag is required for any web platform addition.
>>>
>>
>> We'll have a blink runtime feature flag named
>> "WebGPUAdapterInfoAttribute" for this.
>> Thanks for catching Domenic!
>>
>>>
>>>
>>>
>>>
>>> Non-finch justificationNone
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://issues.chromium.org/issues/335383516
>>>
>>> Estimated milestonesShipping on desktop127Shipping on Android127Shipping
>>> on WebView127
>>>
>>> Anticipated spec changes
>>>
>>> Open questions about a feature may be a source of future web compat or
>>> interop issues. Please list open issues (e.g. links to known github issues
>>> in the project for the feature specification) whose resolution may
>>> introduce web compat/interop risk (e.g., changing to naming or structure of
>>> the API in a non-backward-compatible way).
>>> None
>>>
>>> Link to entry on the Chrome Platform Statushttps://chromestatus.com/
>>> feature/5087914701881344?gate=5141800569536512
>>>
>>> This intent message was generated by Chrome Platform Status
>>> .
>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8zntEfiC5SBHcPeOAKV2SOfUM%3DTn9P8Wrq4L3d%3D_pXyQ%40mail.gmail.com
> 
> .
>

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

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

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

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


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

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

TAG review (see exceptions)
>
https://github.com/w3ctag/design-reviews/issues/877

> bit.ly/blink-signals requests
>
Both Mozilla 
and WebKit  are
positive (with ongoing discussion about some details with Mozilla folks).

> Outreach for feedback from the spec community
>
Regular HTTPWG and WebPerfWG engagement.

> WPT tests
>
https://wpt.fyi/results/fetch/compression-dictionary?label=experimental=master


> thanks,
> Mike
> On 5/28/24 5:59 AM, Tsuyoshi Horo wrote:
>
> Contact emails
>
> h...@chromium.org, pmee...@chromium.org, yoavwe...@chromium.org,
> kenjibah...@chromium.org, denom...@chromium.org
>
>
> Explainer
>
> https://github.com/WICG/compression-dictionary-transport
>
>
> Specification
>
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/
>
>
> Design docs
>
>
> https://docs.google.com/document/d/1IcRHLv-e9boECgPA5J4t8NDv9FPHDGgn0C12kfBgANg/edit
>
> https://github.com/WICG/compression-dictionary-transport
>
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/
>
>
> Summary
>
> We are running the second round of the Origin Trial until Chrome 125. The
> design of the feature has also evolved during the origin trial and RFC
> process. We’d like to run a third round of the Origin Trial to get more
> feedback on the updated
> 
> design.
>
>
> Blink component
>
> Blink>Network
> 
>
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/877
> TAG review status
>
> Closed
> Risks Interoperability and Compatibility
>
> Interoperability and Compatibility risk are low. This feature introduces a
> new compression method for transporting resources over HTTP. Web sites can
> know the browser support for the new feature by checking
> `document.createElement('link').relList.supports('compression-dictionary')`.
> The feature is a negotiation between servers and clients that involves a
> server specifying that a resource should be used as a dictionary for future
> requests with a ‘Use-As-Dictionary’ response header. Clients that don’t
> support the feature will ignore the header and nothing further will happen.
>
> This feature is an opt-in feature. And the dictionary storage is isolated
> using the top level site and the frame origin as the key. That means, if
> there is no dictionary registered for the site, the behavior of Chrome will
> not change while browsing the site. Also this feature is only usable within
> a secure-context so this feature will not increase the risk of having
> network proxies meddle with the content’s encoding. For enterprises that
> have deployed HTTPS-intercepting proxies that do not properly handle
> unknown encodings there is an enterprise policy exposed to disable the
> feature. The feature is currently enabled only over connections using a
> well-known trust root for the secure connection which eliminates the risk
> of security devices and proxies breaking traffic. The roll-out plan for
> production has steps to remove the trust root restriction and enable
> support in enterprise environments where intercepting proxies are common.
>
>
> Gecko: Positive (https://github.com/mozilla/standards-positions/issues/771
> )
>
>
> WebKit: Positive (https://github.com/WebKit/standards-positions/issues/160
> )
>
>
> Web developers: Positive
>
>
> Other signals:
>
>
> Ergonomics
>
> To reduce memory usage in network services, dictionary metadata is stored
> in a database on disk. And to avoid performance degradation for normal
> requests that do not use a dictionary, the reading of this metadata is
> designed not to block network requests. In other words, if the reading of
> metadata from the database is not completed before the request header is
> ready to be sent to the server, the dictionary may not be used even if it
> is already registered in the database.
>
>
>
> Activation
>
> To adopt this feature, web developers need to make changes in their web
> servers or build processes for static resources. Currently there is no
> major server software which directly supports compression dictionaries.
> Some CDNs have shared interest in supporting shared dictionary compression
>

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

I'm sorry, but re-reading this, I realized that I don't fully understand
this change and the plan here.
Can you elaborate on:
* What is the behavior change that we want to drive here?
* Which part of that would be covered by the first CL? which by the second?
* Where do we predict compat risk here? How can we estimate it?

Thanks! :)


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

> Hi Yoav, thanks for the question! From chromium's side, currently I don't
> have any usecounters to trace how many sites would be impacted. I checked
> WebKit' status, seems they don't have any data. Maybe Olli could comment
> this from Gecko's side.
>
> Since the first CL doesn't change the original logic, we might collect
> some data in the second CL(avoid to dispatch events that are already
> scheduled but not executed).
>
> Thanks!
>
> On Monday, May 27, 2024 at 3:08:29 PM UTC+8 yoav...@chromium.org wrote:
>
>> Given Olli's comments on this change being backwards-incompatible, do we
>> have any data on how many sites would be impacted? Any usecounters to that
>> effect?
>>
>> On Mon, May 27, 2024 at 2:19 AM Shuangshuang Zhou 
>> wrote:
>>
>>> Thanks Olli for the implement in Gecko side, and also Dan's comment!
>>>
>>> Hi Mike, would you please take a look and give some suggestion? Also,
>>> seems we need 3 LGTMs, Kent or Mike, would you add another reviewer to to
>>> take a review?
>>>
>>> Thanks!
>>> On Saturday, May 25, 2024 at 1:05:59 AM UTC+8 Olli Pettay wrote:
>>>
 I am trying to land the change, so it should be in FF 128 Nightly soon,
 next week at latest. So hopefully we'll get feedback if it breaks 
 something.
 I don't think there is need for a standards-position for this
 particular small tweak.
 (But the process of making this kind of breaking spec change was rather
 unusual.)


 -Olli

 On Friday, May 24, 2024 at 7:55:44 PM UTC+3 Daniel Clark wrote:

> Thanks Shuangshuang for clarifying what’s going on with these two
> separate but related changes, and Olli for the update on
> https://bugzilla.mozilla.org/show_bug.cgi?id=1898343.
>
>
>
> Since Gecko already implements the behavior of firing selectionchange
> on input/textarea (confirmed here
> ), sounds good to me to go
> ahead with shipping this change in Chromium (I’m not an API owner though).
>
>
>
> Separately, for the behavior of not firing duplicate selectionchange,
> it might not hurt to go ahead and request an official Mozilla position on
> that since it sounds like there’s still a bit of uncertainty about landing
> that change given back compat concerns, unless Olli confirms here that the
> plan is to go ahead and ship it.
>
>
>
> -- Dan
>
>
>
> *From:* Olli Pettay 
> *Sent:* Friday, May 24, 2024 12:26 AM
> *To:* blink-dev 
> *Cc:* Shuangshuang Zhou ; tk...@chromium.org <
> tk...@chromium.org>; mike...@chromium.org ;
> Daniel Clark ; Olli Pettay 
> *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 
>
> FWIW, I'm implementing the change in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1898343
>
> Need to still fix some tests, which do reveal how the spec change
> indeed isn't fully backwards compatible.
>
> Hopefully it doesn't break any real web sites.
>
>
>
>
>
>
>
> -Olli
>
>
>
>
>
> On Friday, May 24, 2024 at 10:05:47 AM UTC+3 Shuangshuang Zhou wrote:
>
> Hi Dan, I think we could submit a standard-position issue to
> Mozilla for reducing duplicated events in our second CL(mentioned in my
> last comment) for this feature. Because in the second CL, we might change
> the current logic of dispatching selectionchange event. For this time, we
> might just do it in chromium. WDYT?
>
>
>
> Thanks!
>
> On Friday, May 24, 2024 at 9:20:33 AM UTC+8 tk...@chromium.org wrote:
>
> 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 <
> shuangsh...@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

Re: [blink-dev] RE: Intent to Ship: Protected Audience: reporting timeouts & multiple-bids

LGTM2

On Thursday, May 23, 2024 at 1:01:53 AM UTC+2 Chris Harrelson wrote:

LGTM1

On Tue, May 21, 2024 at 3:07 PM 'Erik Anderson' via blink-dev <
blink-dev@chromium.org> wrote:

Hi,

 

Thanks for reaching out.

 

We’ve reviewed the proposal and don’t have any significant concerns. We’ll 
continue providing feedback via GitHub where appropriate.

 

Thanks,

Erik

 

*From:* Paul Jensen  
*Sent:* Friday, May 17, 2024 5:42 AM
*To:* Yoav Weiss (@Shopify) 
*Cc:* blink-dev ; Erik Anderson <
erik.ander...@microsoft.com>
*Subject:* Re: Intent to Ship: Protected Audience: reporting timeouts & 
multiple-bids

 

Actually CC Erik this time.

 

On Fri, May 17, 2024 at 8:40 AM Paul Jensen  wrote:

 

 

On Wed, May 15, 2024 at 8:36 AM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

 

On Monday, May 6, 2024 at 10:03:16 PM UTC+2 Paul Jensen wrote:

Contact emails

pauljen...@chromium.org

 

Explainer

Protected Audience reporting timeouts: https://github.com/WICG/
turtledove/pull/1101

Protected Audience multiple-bids: https://github.com/WICG/
turtledove/pull/1048

Please fix the explainer 
<https://github.com/WICG/turtledove/pull/1048/files#r1615583702> to remove 
the "in Chrome" part from the feature detection reference. 

 

Specification

Protected Audience reporting timeouts: https://github.com/WICG/
turtledove/pull/1102

Protected Audience multiple-bids: https://github.com/WICG/
turtledove/pull/1138

 

Summary

Protected Audience (PA) reporting timeouts:

After a PA auction finishes selecting an ad and that ad is allowed to start 
rendering, the browser then runs a JavaScript function from the seller(s) 
and winning buyer to assemble reports that are sent back to their servers. 
These functions are currently given 50ms to run, after which they're 
aborted. We've heard feedback from users of the API that 50ms may not be 
sufficient to assemble the reports and may result in broken billing and 
other basic functionality, resulting in lower website revenue.  We’re 
proposing making the timeout configurable up to 5s. (This JavaScript 
generally runs in a separate process, i.e. off the main thread.)

 

I'm concerned about this timeout, tbh.

It feels very arbitrary and if set by the wrong party, it can create some 
adversarial effects.

Can you expand on why do we need a configurable timeout here, rather than 
just increasing it for everyone?

I think configurability is useful here for a few reasons:

   1. There are potentially three different variables that may determine 
   the optimal setting of this timeout:


   1. 
  1. Different devices may have different execution performance, so a 
  fixed timeout across all devices may be suboptimal.
   

   1. 
  2. Different publisher pages may have different execution 
  requirements.  Some may be sensitive to how much execution time is 
allowed 
  for these reporting scripts, so a fixed timeout across all publisher 
pages 
  may be suboptimal.
   

   1. 
  3. Different auction participants may have different execution 
  requirements.  Some may be sensitive to how much execution time is given 
  for them to complete execution of their reporting scripts.
   

   2. Making it configurable allows callers of the API to experiment and 
   tune to find the optimal timeout for particular situations.
   3. Changing the default timeout could potentially upset ongoing 
   experimentation.

 

If a configurable timeout is indeed needed, am I correct that the timeout 
would be set by the publisher, and its consequences would be felt by the 
seller?

It’s set by whoever is initiating the auction.  This could be anyone on the 
publisher page, including the publisher or a seller acting on their behalf. 

 

Also, can you expand on "This JavaScript generally runs in a separate 
process"? Where is it run?

On desktop, we use one process to run all bidding and scoring scripts for 
one origin, and that gets used for this reporting step also.  On Android, 
where system resources are more constrained, we use site-isolation’s 
heuristics to pick an appropriate process for each origin’s scripts. 

 

 

Protected Audience multiple-bids:

Presently buyers participating in PA ad selection auctions are only allowed 
to return one bid per interest group stored on a user's device. This has a 
couple downsides:

   1. When that one bid does not pass the k-anonymity threshold, the bid 
   generation logic must be invoked again which can be slow, potentially 
   doubling auction runtime.
   2. This preferences adtechs that store more interest groups on device as 
   a way to get more bids into the auction. Many interest groups on device is 
   something we publicly have stated is undesirable: 
   https://developers.google.com/privacy-sandbox/relevance/
   protected-audience-api/latency#fewer_interest_group_owners 
   
<https://developers.google.com/privacy-sandbox/relevance/protected-audien

Re: [blink-dev] Intent to Ship: The ServiceWorker static routing API not condition support

LGTM1

On Wednesday, May 29, 2024 at 2:39:02 AM UTC+2 Yoshisato Yanagisawa wrote:



2024年5月28日(火) 0:21 Vladimir Levin :



On Fri, May 24, 2024 at 3:43 AM Yoshisato Yanagisawa <
yyanagis...@chromium.org> wrote:

Contact emails

yyanagis...@chromium.org

Explainer

https://github.com/WICG/service-worker-static-routing-api

Specification

https://w3c.github.io/ServiceWorker/#dom-routercondition-not

Design docs

https://docs.google.com/document/d/1B2D8w_2M4j9CZC1VccBOAhfCdiRP3yPCSV5U
KKDhU70/edit#heading=h.ns1mpsv4yi7x

Summary

The ServiceWorker static routing API is an API used for routing the request 
to the network, the ServiceWorker fetch handler, or directly looking up 
from cache, and so on.  Each route consists of a condition and a source, 
and the condition is used for matching the request.

For Chromium implementations, the "or" condition is only the supported 
condition.  However, to write the condition more flexibly, supporting the 
"not" condition is expected, which matches the inverted condition inside.


Blink component

Blink>ServiceWorker 


TAG review

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

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

No compatibility concerns.

This change just starts supporting the not condition.  Since existing 
routes won't have the not condition, adding the not condition support won't 
affect any existing router rules.



Gecko: Positive (https://github.com/mozilla/standards-positions/pull/894)

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

Web developers: No signals

Other signals:

Ergonomics

The "not" condition calculates the conditions below and inverts the result, 
such calculation may also take a time.  Also, the element does not run 
concurrently.  However, the inversion is very quick, and rules should be 
sequentially evaluated, it should not be a large performance risk.


Activation

n/a


Security

This just adds the "not" condition.  I believe the security risk is low.


WebView application risks

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

n/a


Debuggability

n/a The debuggability should not be changed by adding the not condition.  
Note that the "not" condition also shows up in chrome://serviceworker-internals 
and devtools.


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

Yes

This is a part of the ServiceWorker static routing API.  There is no reason 
not enabling the feature in specific platforms.


Is this feature fully tested by web-platform-tests 

?

Yes

https://wpt.fyi/results/service-workers/service-worker/tentative/static-
router/static-router-main-resource.https.html?label=
experimental=master

* Main resource load should not match the condition with not

* Main resource load should match the condition without not

https://wpt.fyi/results/service-workers/service-worker/tentative/static-
router/static-router-subresource.https.html?label=experimental=master&
aligned

* Subresource load should not match with the not condition

* Subresource load should match with a file other than not


Two of the tests listed here are failing on wpt.fyi. Is that known?
 


Yes, it is intended.  Since I2S has not gotten lgtm yet, the not condition 
support is disabled via flag.
If you enable the flag, these tests pass.


For next time, a runtime enabled flag 

 
would have made it easier for developers to test this, and would have 
gotten the WPTs to pass, even if the flag is still "experimental" and not 
enabled by default.
 

 


Flag name on chrome://flags

None

Finch feature name

ServiceWorkerStaticRouterNotConditionEnabled

Requires code in //chrome?

False

Tracking bug

https://crbug.com/328565554

Availability expectation

The feature should be implemented if the ServiceWorker static routing API 
has been implemented by the other browsers.

Estimated milestones

Shipping on desktop

126

Shipping on Android

126


126 is already branched. Could you update the milestones for shipping?
 


sure.
 





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).

n/a This only adds the "not" condition. No backward compatibility issue 
should exist.

Link to entry on the Chrome Platform Status

Re: [blink-dev] Intent to Ship: Deprecation of non-standard declarative shadow DOM serialization

LGTM2

On Tue, May 28, 2024 at 11:10 PM Vladimir Levin  wrote:

>
>
> On Tue, May 28, 2024 at 12:30 PM Mason Freed  wrote:
>
>>
>>
>> On Mon, May 27, 2024 at 8:15 AM Vladimir Levin 
>> wrote:
>>
>>> Interoperability and Compatibility

 The use counter for getInnerHTML() (
 https://chromestatus.com/metrics/feature/timeline/popularity/3874)
 peaked at 0.05% of page loads using this function as of January 2024, and
 dropped precipitously toward 0.01% in May, 2024. This is presumably due to
 the shipment of its replacement, getHTML().

>>>
>>> It's great to see the numbers reduce significantly. If the numbers are
>>> being migrated to getHTML() though I would have expected
>>> https://chromestatus.com/metrics/feature/timeline/popularity/4781 to
>>> grow by ~0.04 percentage points, but that one is still significantly lower
>>> (although growing). Is it possible that June 1 numbers would show a better
>>> balance? Do you by any chance know when the next data point is expected to
>>> be visible on chromestatus?
>>>
>>> I'm also assume people are using a readily available replacement as
>>> opposed to just not using getInnerHTML, but it would be nice if number
>>> supported that
>>>
>>
>> Great questions. So AFAIK the use counter plot for the current month is a
>> continuous aggregation. I.e. the 0.0168% I see today (May 28) is as of the
>> 28th, and will change tomorrow (slightly). Given that we're almost to the
>> end of the month, I wouldn't expect a ton of shift. So I think you might be
>> right that this isn't actually a shift to getHTML, but just a shift away
>> from getInnerHTML. See more below.
>>
>> Your questions prompted me to take a closer look at the sample sites
>> still hitting the use counter. I took a close look at the first 10 entries
>> listed, and I think I found perhaps where the big drop came from. Of those
>> ten sites, seven do not use getInnerHTML or getHTML at all. Likely not
>> coincidentally, all seven are Shopify sites. My guess would be that Shopify
>> very recently removed its usage of getInnerHTML?
>>
>
FWIW, internal code search brought up nothing. It's possible that this is a
3P app

that changed their use. (or that I'm simply failing to find the relevant
change :D)


>> The real issue is that the remaining three sites *do* still use
>> getInnerHTML, and all three throw exceptions when the feature is disabled.
>> I can't perceive anything broken on the site, but the exception isn't a
>> good sign. A few interesting tidbits: one of the three does appear to
>> (properly) feature-detect getInnerHTML() yet an exception is still thrown
>> that might or might not be related. The other two do not feature detect,
>> and the exception is clear: "getInnerHTML is not a function". Very
>> interestingly, none of the three use getInnerHMTL for anything declarative
>> shadow dom related. They seem to just be using it as a way to get the
>> innerHTML value. All three seem to be hand-written JS, so it's possible the
>> sites were developed on Chrome in the last few years and the developer
>> didn't notice that they should have done foo=el.innerHTML instead of
>> foo=el.getInnerHTML().
>>
>> Given that the use counter is very low (0.01%), I'd still like to push
>> ahead with this deprecation. The above sites likely represent interop
>> problems, since they'll break on other browsers already today. But I'd like
>> to revise my plan: instead of going immediately to 100% removal, I'd like
>> to use a slow ramp down over time, to monitor for reported breakage.
>>
>> Thoughts?
>>
>
> The plan to ramp down usage is a good one, although as we previously
> discussed in a different thread, it may cause some debugging challenges for
> developers. It is worthwhile to also reach out to some of the developers
> whose sites you noticed would throw an exception -- just an FYI email that
> this feature is being removed. Given the fairly low usage, readily
> available fixes (via getHTML() or possibly innerHTML) and your commitment
> to monitor for breakages, this looks good to me.
>
> LGTM1
>
>
>>
>> Thanks,
>> Mason
>>
>>
>>
>>>
>>> While 0.01% still represents high usage for deprecation, the numbers
 were significantly worse for the deprecation of the old `shadowroot`
 attribute, and the removal of that feature generated zero bug reports. It
 is my strong belief that since this feature is only shipped in Chrome, the
 vast majority of usage is guarded by feature checks. So this deprecation
 should be safer than it would seem from the numbers. I'd like to remove
 this feature in M127 in code, with a killswitch (a re-enable switch really)
 in case of problems.


 *Gecko*: No signal

 *WebKit*: No signal

 *Web developers*: No signals

 *Other signals*:

 WebView application risks

 Does this intent deprecate or change behavior of existing

Re: [blink-dev] Intent to Deprecate and Remove: Deprecate old CSS custom state syntax

2024-05-28 Thread Yoav Weiss (@Shopify)

LGTM2

Please make sure that use of the old syntax triggers some kind of
developer-facing warning, so that it won't be too hard to catch the cause
for the behavior change in the few sites that will be affected.

On Tue, May 28, 2024 at 10:33 PM Joey Arhar  wrote:

> > How should I interpret the results from your investigation? That none of
> the 8 investigated sites would be negatively affected?
>
> There is only one site which is actually affected: https://resolv.com.br/
> The buttons in the carousel there won't light up anymore, but they will
> still work. I made sure of that based on the shape of the JS portion of the
> new syntax. You can test this out in firefox nightly or safari TP.
>
> On Wed, May 22, 2024 at 9:22 AM Daniel Bratell  wrote:
>
>> To be particular about the usage number, it's about a magnitude more than
>> our informal limit. That doesn't mean it can't be shipped, but it means
>> that we want to be fairly certain that >90% of the users are unaffected by
>> the change.
>>
>> How should I interpret the results from your investigation? That none of
>> the 8 investigated sites would be negatively affected?
>>
>> /Daniel
>>
>> On 2024-05-22 18:03, Vladimir Levin wrote:
>>
>>
>>
>> On Tue, May 21, 2024 at 2:20 PM Joey Arhar  wrote:
>>
>>> > Do you know what the breakage looks like
>>>
>>> I pushed to make sure that using the old syntax with
>>> CustomStateSet.add() wouldn't throw exceptions when in the new mode in
>>> order to reduce breakage. When websites use the old syntax after it's
>>> removed, they will just have styling differences because their selectors
>>> won't parse anymore.
>>>
>>> > or whether this usage is limited to a library/a small set of large
>>> websites or something else?
>>>
>>> Based on the analysis that I linked in the previous thread
>>> ,
>>> there are some websites which all look very similar which use it, but they
>>> are all hidden behind display:none elements that I had to manually reveal.
>>> There was only one website I found which was actually using it which has a
>>> carousel which has buttons that didn't work in safari and firefox because
>>> CustomStateSet didn't exist yet.
>>>
>>> I don't think there is a popular library which is using the deprecated
>>> syntax.
>>>
>>> > Ideally, this is feature detected with some fallback syntax
>>>
>>> Websites just have to replace ":--foo" with ":state(foo)", I don't think
>>> any feature detection is necessary. If they are interested in supporting
>>> older browsers, then I don't see why they would have any interest in
>>> looking at whether the deprecated syntax works or not because the other
>>> browsers didn't have it before and neither did we until a couple years ago.
>>>
>>
>> I meant I hope that existing use is either feature-detected or it's using
>> both properties. In either case, it's very easy to fix if problems arise
>> since alternate syntax is shipped already in multiple browsers.
>>
>> LGTM1
>>
>>
>>> On Tue, May 21, 2024 at 11:09 AM Vladimir Levin 
>>> wrote:
>>>
 Hey,

 0.04% seems like a fairly sizable number. Do you know what the breakage
 looks like or whether this usage is limited to a library/a small set of
 large websites or something else?

 Ideally, this is feature detected with some fallback syntax


 On Tue, May 21, 2024 at 1:39 PM Joey Arhar  wrote:

> Contact emails jar...@chromium.org
>
> Explainer None
>
> Specification https://github.com/whatwg/html/pull/8467
>
> Summary
>
> The CSS custom state pseudo-class is being renamed from :--foo to
> :state(foo). The new syntax, :state(foo), has been enabled by default, and
> now we have to deprecate and remove the :--foo syntax. Gecko and webkit
> never implemented the old syntax and they have both shipped the new 
> syntax.
> We are currently shipping both the new syntax and the old syntax at the
> same time. There have been console errors and DevTools deprecations for 
> the
> old syntax for many milestones already. Previous thread on this topic:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/JvpHoUfhJYE/m/uRtWiqoHAQAJ
> The UseCounter is currently at 0.04%
> https://chromestatus.com/metrics/feature/timeline/popularity/3796
>
>
> Blink component Blink>HTML>CustomElements
> 
>
> Motivation
>
> The syntax of this feature needs to change in order to get support
> from the other browsers and eventually have interoperable behavior.
>
>
> Initial public proposal None
>
> TAG review None
>
> TAG review status Not applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> Websites which are currently using the old syntax and don't migrate to

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

2024-05-27 Thread Yoav Weiss (@Shopify)

LGTM2

On Fri, May 24, 2024 at 5:53 PM Anton Maliev  wrote:

> I see the concern. The 3P can use document.hasStorageAccess()
> <https://developer.mozilla.org/en-US/docs/Web/API/Document/hasStorageAccess> 
> to
> check for cookie support, which accounts for the grace period and opt-out.
> (It would return true if there is an active grace period on the 1P or 3P
> that affects the current frame, or false if the current client is opted
> out.) Per the linked I2S, we recommend document.hasStorageAccess() instead
> of navigator.cookieEnabled moving forward for validation relating to
> Chrome's 3PCD rollout - the latter doesn't return the correct value for
> this case.


Thanks! That makes sense.


>
> This also depends if the 3P in question is also on the grace period. If it
> is not, we would expect them to notice any breakage on other 1Ps as well.
>
> On Thursday, May 23, 2024 at 4:17:14 PM UTC-4 Yoav Weiss wrote:
>
>> 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
>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/xU3gTW4aTfg/m/LaUu7IN2BAAJ?utm_medium=email_source=footer>.
>> 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
>>>>> <https://developers.google.com/privacy-sandbox/3pcd/temporary-exceptions/first-party-deprecation-trial>
>>>>> and one for embedded sites
>>>>> <https://developers.google.com/privacy-sandbox/3pcd/temporary-exceptions/third-party-deprecation-trial>.
>>>>> When a site is approved for one of these trials, they are added to a
>>>>> short-term grace period which mitigates breakage until

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

2024-05-27 Thread Yoav Weiss (@Shopify)

Given Olli's comments on this change being backwards-incompatible, do we
have any data on how many sites would be impacted? Any usecounters to that
effect?

On Mon, May 27, 2024 at 2:19 AM Shuangshuang Zhou <
shuangshuang.z...@intel.com> wrote:

> Thanks Olli for the implement in Gecko side, and also Dan's comment!
>
> Hi Mike, would you please take a look and give some suggestion? Also,
> seems we need 3 LGTMs, Kent or Mike, would you add another reviewer to to
> take a review?
>
> Thanks!
> On Saturday, May 25, 2024 at 1:05:59 AM UTC+8 Olli Pettay wrote:
>
>> I am trying to land the change, so it should be in FF 128 Nightly soon,
>> next week at latest. So hopefully we'll get feedback if it breaks something.
>> I don't think there is need for a standards-position for this particular
>> small tweak.
>> (But the process of making this kind of breaking spec change was rather
>> unusual.)
>>
>>
>> -Olli
>>
>> On Friday, May 24, 2024 at 7:55:44 PM UTC+3 Daniel Clark wrote:
>>
>>> Thanks Shuangshuang for clarifying what’s going on with these two
>>> separate but related changes, and Olli for the update on
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1898343.
>>>
>>>
>>>
>>> Since Gecko already implements the behavior of firing selectionchange on
>>> input/textarea (confirmed here ),
>>> sounds good to me to go ahead with shipping this change in Chromium (I’m
>>> not an API owner though).
>>>
>>>
>>>
>>> Separately, for the behavior of not firing duplicate selectionchange, it
>>> might not hurt to go ahead and request an official Mozilla position on that
>>> since it sounds like there’s still a bit of uncertainty about landing that
>>> change given back compat concerns, unless Olli confirms here that the plan
>>> is to go ahead and ship it.
>>>
>>>
>>>
>>> -- Dan
>>>
>>>
>>>
>>> *From:* Olli Pettay 
>>> *Sent:* Friday, May 24, 2024 12:26 AM
>>> *To:* blink-dev 
>>> *Cc:* Shuangshuang Zhou ; tk...@chromium.org <
>>> tk...@chromium.org>; mike...@chromium.org ;
>>> Daniel Clark ; Olli Pettay 
>>> *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 
>>>
>>> FWIW, I'm implementing the change in
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1898343
>>>
>>> Need to still fix some tests, which do reveal how the spec change indeed
>>> isn't fully backwards compatible.
>>>
>>> Hopefully it doesn't break any real web sites.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -Olli
>>>
>>>
>>>
>>>
>>>
>>> On Friday, May 24, 2024 at 10:05:47 AM UTC+3 Shuangshuang Zhou wrote:
>>>
>>> Hi Dan, I think we could submit a standard-position issue to
>>> Mozilla for reducing duplicated events in our second CL(mentioned in my
>>> last comment) for this feature. Because in the second CL, we might change
>>> the current logic of dispatching selectionchange event. For this time, we
>>> might just do it in chromium. WDYT?
>>>
>>>
>>>
>>> Thanks!
>>>
>>> On Friday, May 24, 2024 at 9:20:33 AM UTC+8 tk...@chromium.org wrote:
>>>
>>> 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 <
>>> shuangsh...@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

[blink-dev] Re: Intent to Ship: Importmap integrity

2024-05-24 Thread Yoav Weiss (@Shopify)

On Fri, May 24, 2024 at 7:12 PM Panos Astithas  wrote:

>
>
> On Wed, May 22, 2024 at 2:16 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>>
>>
>> On Wed, May 22, 2024 at 10:29 AM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>>
>>>
>>> On Tuesday, May 21, 2024 at 1:04:44 PM UTC+2 Yoav Weiss wrote:
>>>
>>> Contact emailsyoavwe...@chromium.org
>>>
>>> Explainerhttps://github.com/guybedford/import-maps-extensions#integrity
>>>
>>> Specificationhttps://github.com/whatwg/html/pull/10269
>>>
>>> The PR is ready to land, but we're holding off on that for 2 weeks at
>>> Mozilla's request. See below.
>>>
>>> Summary
>>>
>>> Imported ES modules can't currently have their integrity checked, and
>>> hence cannot run in environments that require Subresource Integrity or with
>>> `require-sri-for` CSP directives. This feature adds an `integrity` section
>>> to import maps, enabling developers to map ES module URLs to their
>>> integrity metadata, and ensure they only load when they match their
>>> expected hashes.
>>>
>>>
>>> Blink componentBlink>Loader
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELoader>
>>>
>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/944
>>>
>>> TAG review statusIssues addressed
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> On the interoperability front, this got a positive position from WebKit,
>>> and I'm implementing the feature there
>>> <https://github.com/whatwg/html/pull/10269>. Mozilla didn't object to
>>> the feature, but asked
>>> <https://docs.google.com/document/d/1iaarr4Ho715CUULrvi_LD3TwshAcN2odDLBBEK0FjH0/edit#bookmark=id.li7pdpi5uloq>
>>>
>>>
>> I just realized that the meeting notes are not publicly viewable.
>> +Panos Astithas  - would you be able to open them
>> up to the public somehow? (e.g. as a Chromium.org doc)
>>
>
> They were published
> <https://github.com/whatwg/html/issues/10340#:~:text=Benjamin%3A%20I%27d%20like%20a%20further%20two%20weeks>
>  that
> same day, we try to post the minutes publicly in less than 24 hours.
>

Oops!! My bad for using the wrong artifact!


>
>>
>>
>>> for a couple more weeks to evaluate it and provide a position, as they
>>> might be planning broader-scope work on the front of application integrity,
>>> and want to make sure this doesn't collide with it.
>>>
>>>
>>> On the compatibility front, the feature is polyfilled
>>> <https://github.com/guybedford/es-module-shims/pull/424>, but it's turned
>>> off for browsers that support import maps
>>> <https://github.com/guybedford/es-module-shims#:~:text=The%20ES%20Module%20Shims%20polyfill%20will%20analyze%20the%20browser%20to%20see%20if%20it%20supports%20import%20maps.%20If%20it%20does%2C%20it%20doesn%27t%20do%20anything%20more>
>>> .
>>>
>>>
>>> Adding Guy Bedford, the polyfill author to this thread. Guy, can you
>>> confirm this is the case?
>>>
>>> *Gecko*: No signal
>>> <https://github.com/mozilla/standards-positions/issues/1010>
>>>
>>> *WebKit*: Support
>>> <https://github.com/WebKit/standards-positions/issues/335>
>>>
>>>
>>> WebKit PR <https://github.com/WebKit/WebKit/pull/28253> has landed.
>>>
>>>
>>>
>>>
>>> *Web developers*: Positive
>>> <https://x.com/yoavweiss/status/1778067431417954803>
>>> This is based on a proposal from a developer (Guy Bedford).
>>> Multiple Shopify properties are interested in this, to enable using ES
>>> modules as bundler output in security sensitive environments. Asking about
>>> this on twitter and mastodon showed that some developers are interested in
>>> this, while others discount SRI in general.
>>>
>>> *Other signals*:
>>>
>>> Activation
>>>
>>> As long as support is not ubiquitous, the `integrity` part of import
>>> maps will be ignored in non-supporting browsers, resulting in scripts
>>> loading in those browsers even if they're supposed to fail their integrity
>>> checks.
>>>
>>> There's also a polyfill
>>> <https://github.com/guybedford/es-module-shims/pull/424> that would
>>> enable

Re: [blink-dev] Re: Intent to Ship: Importmap integrity

2024-05-24 Thread Yoav Weiss (@Shopify)

On Fri, May 24, 2024 at 5:57 PM Alex Russell 
wrote:

> I'm also not sure why we would wait.
>

Waiting a few more days won't change much, so it's perfectly fine.


> That said, if we're expanding SRI, it would be great to see media
> resources included. Won't block this intent on it, but for architectural
> consistency want to flag that we aren't "done".
>

I agree in principle, but media resources are more complex, as they can be
"executed" progressively.
SRI in its current form would mean they are inherently slower, and
expanding SRI to enable something like Merkle-Tree
<https://en.wikipedia.org/wiki/Merkle_tree#:~:text=In%20cryptography%20and%20computer%20science,labels%20of%20its%20child%20nodes.>-based
hashes seems like a significant expansion.
At the same time, maybe Mozilla's plans around application integrity would
cover that use case.


> On Wed, May 22, 2024, 6:39 PM Mike Taylor  wrote:
>
>> I'm inclined to LGTM this now - but don't see a lot of harm waiting for 1
>> additional week (per Mozilla's request in the not-public minutes). Happy to
>> do so before, so long as the HTML PR lands.
>> On 5/22/24 5:15 AM, Yoav Weiss (@Shopify) wrote:
>>
>>
>>
>> On Wed, May 22, 2024 at 10:29 AM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>>
>>>
>>> On Tuesday, May 21, 2024 at 1:04:44 PM UTC+2 Yoav Weiss wrote:
>>>
>>> Contact emailsyoavwe...@chromium.org
>>>
>>> Explainerhttps://github.com/guybedford/import-maps-extensions#integrity
>>>
>>> Specificationhttps://github.com/whatwg/html/pull/10269
>>>
>>> The PR is ready to land, but we're holding off on that for 2 weeks at
>>> Mozilla's request. See below.
>>>
>>> Summary
>>>
>>> Imported ES modules can't currently have their integrity checked, and
>>> hence cannot run in environments that require Subresource Integrity or with
>>> `require-sri-for` CSP directives. This feature adds an `integrity` section
>>> to import maps, enabling developers to map ES module URLs to their
>>> integrity metadata, and ensure they only load when they match their
>>> expected hashes.
>>>
>>>
>>> Blink componentBlink>Loader
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELoader>
>>>
>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/944
>>>
>>> TAG review statusIssues addressed
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> On the interoperability front, this got a positive position from WebKit,
>>> and I'm implementing the feature there
>>> <https://github.com/whatwg/html/pull/10269>. Mozilla didn't object to
>>> the feature, but asked
>>> <https://docs.google.com/document/d/1iaarr4Ho715CUULrvi_LD3TwshAcN2odDLBBEK0FjH0/edit#bookmark=id.li7pdpi5uloq>
>>>
>>>
>> I just realized that the meeting notes are not publicly viewable.
>> +Panos Astithas  - would you be able to open them
>> up to the public somehow? (e.g. as a Chromium.org doc)
>>
>>
>>> for a couple more weeks to evaluate it and provide a position, as they
>>> might be planning broader-scope work on the front of application integrity,
>>> and want to make sure this doesn't collide with it.
>>>
>>>
>>> On the compatibility front, the feature is polyfilled
>>> <https://github.com/guybedford/es-module-shims/pull/424>, but it's turned
>>> off for browsers that support import maps
>>> <https://github.com/guybedford/es-module-shims#:~:text=The%20ES%20Module%20Shims%20polyfill%20will%20analyze%20the%20browser%20to%20see%20if%20it%20supports%20import%20maps.%20If%20it%20does%2C%20it%20doesn%27t%20do%20anything%20more>
>>> .
>>>
>>>
>>> Adding Guy Bedford, the polyfill author to this thread. Guy, can you
>>> confirm this is the case?
>>>
>>> *Gecko*: No signal
>>> <https://github.com/mozilla/standards-positions/issues/1010>
>>>
>>> *WebKit*: Support
>>> <https://github.com/WebKit/standards-positions/issues/335>
>>>
>>>
>>> WebKit PR <https://github.com/WebKit/WebKit/pull/28253> has landed.
>>>
>>>
>>>
>>>
>>> *Web developers*: Positive
>>> <https://x.com/yoavweiss/status/1778067431417954803>
>>> This is based on a proposal from a developer (Guy Bedford).
>>> Multiple Shopify properties are interested in

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

2024-05-23 Thread 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
<https://groups.google.com/a/chromium.org/g/blink-dev/c/xU3gTW4aTfg/m/LaUu7IN2BAAJ?utm_medium=email_source=footer>.
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
>>> <https://developers.google.com/privacy-sandbox/3pcd/temporary-exceptions/first-party-deprecation-trial>
>>> and one for embedded sites
>>> <https://developers.google.com/privacy-sandbox/3pcd/temporary-exceptions/third-party-deprecation-trial>.
>>> 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
>>> <https://datatracker.ietf.org/doc/html/rfc8615>, specified here
>>> <https://github.com/explainers-by-googlers/3pcd-deprecation-trial-staged-rollout/blob/main/well-known-specification.md>.
>>> 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 <https://b.corp.google.com/components/1457231>
>>>
>>> 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

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

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/CAOmohS%2B13j_wjzqsqoOEdnsnWmd9uAoWHr9HVyFUYSeUhr-0sA%40mail.gmail.com.

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

LGTM to extend the deprecation trial M127-M132 inclusive

On Wed, May 22, 2024 at 4:44 PM Mike Taylor  wrote:

> On 5/22/24 8:11 AM, Yoav Weiss (@Shopify) wrote:
>
>
>
> On Tue, May 21, 2024 at 8:55 PM Mike Taylor 
> wrote:
>
>> *Contact emails*
>>
>>
>>
>>
>>
>>
>>
>> * miketa...@chromium.org  Explainer
>> https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md
>> <https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md>
>> Specification None Summary We shipped “storage partitioning” in Chrome 115,
>> and a Deprecation Trail
>> <https://developer.chrome.com/origintrials/#/view_trial/-8517432795264450559>
>> (DT) beginning in M113 that is set to expire in M126. There are also
>> enterprise policies available:
>> https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting
>> <https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting>
>> https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins
>> <https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins>
>> We are requesting a renewal for 6 milestones (M127 - M132 inclusive) for
>> the DisableThirdPartyStoragePartitioning
>> <https://developer.chrome.com/origintrials/#/view_trial/-8517432795264450559>
>> DT (but not the
>> DisableThirdPartySessionStoragePartitioningAfterGeneralPartitioning
>> <https://developer.chrome.com/origintrials/#/view_trial/3444127815031586817>
>> DT). Since we shipped the first Deprecation Trial, we have also shipped the
>> non-cookie storage extension to SAA
>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/F5EV8I-j7Eg/m/OAi7lcykAAAJ>
>> (M125+) to address sites impacted by storage partitioning. We are confident
>> this API extension will address the majority of “unpartitioned” storage use
>> cases, however, we are aware of a few partners with slightly different use
>> cases that we are currently exploring API solutions for. Our near-term goal
>> is to have this Deprecation Trial expire and migrate the platform to
>> partitioned-by-default 3rd party storage, communications APIs, and service
>> workers, especially ahead of 3rd party cookie deprecation. Given that, we
>> propose to only allow an extension for sites that have already enrolled in
>> the current non-expired Deprecation Trial, taking advantage of the new OT
>> registration approval workflow. *
>>
>
> That's exciting! Are there numbers you can share regarding the current
> participants? Is it realistic to expect the 6 milestone renewal to be the
> last one?
>
> Sure thing - we have on the order of 600 registrants, but if you de-dupe
> the list that takes you down to about 400. Further removing localhost, or
> staging or obvious test domains (stuff like
> "https://testing-this-ot.vercel.app; <https://testing-this-ot.vercel.app>,
> we're down to ~300. My hand-wavey guess is the majority of these will be
> served by the non-cookie SAA stuff we shipped, or have already resolved
> their need to use the OT.
>
> Will this be the last renewal? Hard to predict the future, but if we do
> find ourselves in that bucket I would like to craft it in such a way to
> continue to narrow the funnel further than we are right now, especially to
> avoid timeline contention and side-channels with 3PCD.
>
>
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> * We will respond to this intent with a link to a blog post once the
>> renewal process is in place. Blink component Blink>Storage
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorage>
>> TAG review Early Design Review
>> https://github.com/w3ctag/design-reviews/issues/629
>> <https://github.com/w3ctag/design-reviews/issues/629> TAG review status
>> Resolution Satisfied Chromium Trial Name
>> DisableThirdPartyStoragePartitioning Origin Trial documentation link
>> https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/
>> <https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/>
>> Risks Interoperability and Compatibility Gecko: Shipped/Shipping WebKit:
>> Shipped/Shipping Web developers: Mixed signals (some supportive, some
>> concerns around compatibility) WebView application risks Does this

Re: [blink-dev] Intent to Ship: Protected Audience ads reporting - allow cross-origin subframes to send reportEvent() beacons

LGTM2

On Tuesday, May 21, 2024 at 2:11:37 PM UTC+2 Mike Taylor wrote:

> Thanks Liam!
>
> LGTM1 to ship.
> On 5/20/24 3:51 PM, Liam Brady wrote:
>
> Thanks for your feedback on this intent! We plan on modifying the 
> "Allow-Cross-Origin-Event-Reporting" response header to accept a boolean 
> instead of a string literal to match the preferred convention for response 
> headers.
>
> On Thursday, May 9, 2024 at 1:21:43 PM UTC-4 Liam Brady wrote:
>
>> Can I ask why string literal vs boolean?
>>
>>
>> I had done this to match the convention already being used for other 
>> Protected Audience-related response headers (such as 
>> Ad-Auction-Allowed/X-Allow-FLEDGE 
>> ).
>>  
>> At the time of implementation, I wasn't aware of the preferred boolean 
>> convention of "?0" and "?1" defined in RFC8941 
>> . Even though this 
>> isn't what's preferred, I think it should still be fine to keep in place 
>> for now, and being consistent with the rest of the Protected Audience API 
>> is always a plus.
>>
>> On Thu, May 9, 2024 at 12:19 PM Mike Taylor  wrote:
>>
>>> On 5/9/24 12:13 PM, Liam Brady wrote:
>>>
>>> Can you clarify what the type is for this new header? It reads as if 
 you're adding a String Item that looks like a boolean, rather than a 
 Boolean Item. Is that correct? It doesn't seem to be actually defined in 
 the spec. 
>>>
>>>
>>> This is meant to be a string literal that is either "true" or "false". I 
>>> have a spec PR  up to 
>>> formally define that and remove any confusion over what values it's 
>>> expecting. Thanks for calling this out!
>>>
>>> Can I ask why string literal vs boolean?
>>>
>>>
>>> This change would impact the ability of first parties to regulate and 
 prevent reportEvent beacons. Although this requires mutual opt-in, I 
 expect 
 scenarios to eventually come up where a site owner wants to allow 
 cross-origin reportEvent only for certain origins.
>>>
>>>
>>> To clarify the first party piece, control over sending reportEvent() 
>>> beacons rests within the worklet owner that invokes 
>>> registerAdBeacon()/registerAdMacro() i.e. seller/ buyer and the document 
>>> loaded with the main ad renderURL (i.e. the buyer/advertisers). The 
>>> first-party (i.e. the publishers) don't have control over reportEvent() 
>>> beacons since that is considered part of the overall Protected Audience 
>>> API, and this feature doesn't change that.
>>>
>>> On Wed, May 8, 2024 at 1:27 PM Mike Taylor  wrote:
>>>
 On 5/8/24 11:30 AM, 'Liam Brady' via blink-dev wrote:

 Contact emails

 lbr...@google.com, shiva...@chromium.org, jka...@chromium.org

 Explainer(s)

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

 Spec(s)

 https://github.com/WICG/fenced-frame/pull/152

 Summary

 Ad frames (both fenced frames and urn-iframes) created through a 
 Protected Audience auction, as well as their same-origin nested iframes, 
 are allowed to call reportEvent() API 

 to send event-level reports. It's also important for third-parties on 
 Protected Audience-created ads to have the same measurement and reporting 
 capabilities for spam detection, brand safety, and measurement 
 verification. However, the API as it exists currently has a same-origin 
 child iframe restriction which poses a complication as described below.

 If an ad buyer wins an ad auction and its ad frame is displayed on a 
 page, it might choose to embed a subframe that points to a third-party 
 server that hosts the actual ad instead. With this use case, and with the 
 current state of the reportEvent() API, the actual ad's document cannot 
 directly call reportEvent() the way that its embedder can since the 
 document is in a cross-origin nested iframe. Instead, it has to get its 
 embedder to actually send the beacon by letting the embedder know via a 
 postMessage. This will not be an ergonomic solution for this use case.

 With this change, a cross-origin subframe can opt in to sending 
 reportEvent() beacons using its ancestor's reporting metadata by calling 
 reportEvent() with the parameter crossOriginExposed=true. This is the same 
 syntax as is currently used by the main render URL frame to opt in to 
 sending cross-origin automatic beacons with data (this means the 
 FenceEvent 
 IDL will stay the same).

 The main ad render URL frame will opt in with a new 
 "Allow-Cross-Origin-Event-Reporting" response header. Its valid values

Re: [blink-dev] Intent to Ship: Adding Cross-site Ancestor Chain Bit to CHIPS Partition Key

Any news from Paypal?

On Friday, May 3, 2024 at 7:15:58 PM UTC+2 Aaron Selya wrote:

> Thank you for suggesting a deeper dive into this Yoav as I might not have 
> discovered the significant impact that the "receive-cookie-deprication" 
> cookies were having on my metrics without your prompting. 
>
> I've reached out to some engineers at Paypal and hopefully they'll get 
> back to me sometime next week. 
>
> On Fri, May 3, 2024 at 8:50 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>> Thanks for diving into this!!
>>
>> I guess the scariest bit here would be paypal losing a cookie in the 
>> redirect. Even if you didn't find a visible impact in your testing, they 
>> may not be exhaustive, and breakage there feels riskier than in other 
>> mentioned domains.
>>
>> Have you tried to reach out to Paypal folks and see what they say?
>>
>> On Wed, May 1, 2024 at 8:05 PM Aaron Selya  wrote:
>>
>>> My apologies for the delay in following up on this.
>>>
>>> When I finished my initial implementation and got to the point where I 
>>> could begin testing, I found that my metrics were being flooded with a 
>>> cookie named, "receive-cookie-deprication". After doing some research and 
>>> testing I learned that this cookie is used by sites for testing the 
>>> potential impact of third party cookie depreciation but doesn't have any 
>>> impact on website functionality. To get a better sense of potential 
>>> breakage, I landed updated metrics that filtered out that cookie. I then 
>>> conducted a manual audit on 10 (of the 104) sites that indicated a possible 
>>> impact with a build of chromium that had the finch flag turned on. 
>>>
>>> I've summarized my findings in this slide deck 
>>> <https://docs.google.com/presentation/d/1S2N2vyGDaKAwP-5W5pVYqRNQ1RQndjlq4yVTny6hEIY/edit?usp=sharing>
>>>  
>>> but I was unable to find a breakage that caused a site to not perform as 
>>> expected from the user's perspective. To be clear, this doesn't mean that 
>>> there won't be breakage that occurs if/when this feature goes live, only 
>>> that I was unable to find an example where the website was unable to 
>>> perform as expected.
>>>
>>> Additionally, with the filtering out of the "receive-cookie-deprication" 
>>> cookie from the metrics, the occurrences of an A1->B-A2 cookie which this 
>>> change would impact drops from 0.032% of overall page loads to 0.0012% of 
>>> overall page loads.
>>>
>>
>> That's extremely reassuring!
>>  
>>
>>>
>>> On Tue, Mar 19, 2024 at 12:05 PM Aaron Selya  wrote:
>>>
>>>> Yoav, your understanding is correct.
>>>>
>>>> I'm still in the process of finalizing the implementation. Once that is 
>>>> done, I'll audit some sites that metrics have indicated will 
>>>> experience breakage and report back my findings.
>>>>
>>>> On Tue, Mar 19, 2024 at 8:52 AM Mike Taylor  
>>>> wrote:
>>>>
>>>>> It would also be helpful to discuss what breakage looks like in this 
>>>>> case. Would it be a one-time loss of state (i.e., have to log in again), 
>>>>> or 
>>>>> something different?
>>>>> On 3/19/24 5:08 AM, Yoav Weiss (@Shopify) wrote:
>>>>>
>>>>> OK, so just to summarize my understanding: 
>>>>>
>>>>>- We expect this to have some impact on 0.032% of page views 
>>>>>- We have a Finch flag that can be used as a kill switch in case 
>>>>>we see lots of breakage in the wild 
>>>>>- Developers can get around this deprecation by changing their 
>>>>>cookies to be "same-site: none" *and* requesting SAA from users 
>>>>>
>>>>> Is the above correct? 
>>>>>
>>>>> If so, 0.032% sounds like a lot. Would it be possible for y'all to 
>>>>> same pages that trigger that use counter and see how many of them break 
>>>>> and 
>>>>> what does breakage look like?
>>>>>
>>>>> On Wed, Mar 13, 2024 at 8:23 PM Aaron Selya  wrote:
>>>>>
>>>>>> The flag is a base::features flag named 
>>>>>> kAncestorChainBitEnabledInPartitionedCookies.
>>>>>>
>>>>>> Updated the review gates on chromestatus.com
>>>>>>
>>>>>> On

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

On Tue, May 21, 2024 at 8:55 PM Mike Taylor  wrote:

> *Contact emails*
>
>
>
>
>
>
>
> * miketa...@chromium.org  Explainer
> https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md
> 
> Specification None Summary We shipped “storage partitioning” in Chrome 115,
> and a Deprecation Trail
> 
> (DT) beginning in M113 that is set to expire in M126. There are also
> enterprise policies available:
> https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting
> 
> https://chromeenterprise.google/policies/#ThirdPartyStoragePartitioningBlockedForOrigins
> 
> We are requesting a renewal for 6 milestones (M127 - M132 inclusive) for
> the DisableThirdPartyStoragePartitioning
> 
> DT (but not the
> DisableThirdPartySessionStoragePartitioningAfterGeneralPartitioning
> 
> DT). Since we shipped the first Deprecation Trial, we have also shipped the
> non-cookie storage extension to SAA
> 
> (M125+) to address sites impacted by storage partitioning. We are confident
> this API extension will address the majority of “unpartitioned” storage use
> cases, however, we are aware of a few partners with slightly different use
> cases that we are currently exploring API solutions for. Our near-term goal
> is to have this Deprecation Trial expire and migrate the platform to
> partitioned-by-default 3rd party storage, communications APIs, and service
> workers, especially ahead of 3rd party cookie deprecation. Given that, we
> propose to only allow an extension for sites that have already enrolled in
> the current non-expired Deprecation Trial, taking advantage of the new OT
> registration approval workflow.*
>

That's exciting! Are there numbers you can share regarding the current
participants? Is it realistic to expect the 6 milestone renewal to be the
last one?


>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> * We will respond to this intent with a link to a blog post once the
> renewal process is in place. Blink component Blink>Storage
> 
> TAG review Early Design Review
> https://github.com/w3ctag/design-reviews/issues/629
>  TAG review status
> Resolution Satisfied Chromium Trial Name
> DisableThirdPartyStoragePartitioning Origin Trial documentation link
> https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/
> 
> Risks Interoperability and Compatibility Gecko: Shipped/Shipping WebKit:
> Shipped/Shipping Web developers: Mixed signals (some supportive, some
> concerns around compatibility) 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? Not enabled on WebView
> for now. Will this feature be supported on all six Blink platforms
> (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? No, all but
> WebView. Is this feature fully tested by web-platform-tests
> ?
> We have basic WPT coverage. DevTrial instructions
> https://developer.chrome.com/en/blog/storage-partitioning-dev-trial
>  Finch
> feature name DisableThirdPartyStoragePartitioning Non-finch justification
> N/A Requires code in //chrome? False Tracking bug
> https://bugs.chromium.org/p/chromium/issues/detail?id=1191114
>  Launch bug
> https://launch.corp.google.com/launch/4214498
>  Estimated milestones
> Shipping on desktop 115 Origin trial desktop first 113 Origin trial desktop
> last 132 DevTrial on desktop 105 Shipping on Android 115 DevTrial on
> Android 105 Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5723617717387264?gate=5117857892663296
> 
> Links to previous Intent discussions Intent to Experiment:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d395956d-3a59-1ba9-1b5c-33505e1518d3%40chromium.org
>

[blink-dev] Re: Intent to Ship: Importmap integrity

On Wed, May 22, 2024 at 10:29 AM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

>
>
> On Tuesday, May 21, 2024 at 1:04:44 PM UTC+2 Yoav Weiss wrote:
>
> Contact emailsyoavwe...@chromium.org
>
> Explainerhttps://github.com/guybedford/import-maps-extensions#integrity
>
> Specificationhttps://github.com/whatwg/html/pull/10269
>
> The PR is ready to land, but we're holding off on that for 2 weeks at
> Mozilla's request. See below.
>
> Summary
>
> Imported ES modules can't currently have their integrity checked, and
> hence cannot run in environments that require Subresource Integrity or with
> `require-sri-for` CSP directives. This feature adds an `integrity` section
> to import maps, enabling developers to map ES module URLs to their
> integrity metadata, and ensure they only load when they match their
> expected hashes.
>
>
> Blink componentBlink>Loader
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELoader>
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/944
>
> TAG review statusIssues addressed
>
> Risks
>
>
> Interoperability and Compatibility
>
> On the interoperability front, this got a positive position from WebKit,
> and I'm implementing the feature there
> <https://github.com/whatwg/html/pull/10269>. Mozilla didn't object to the
> feature, but asked
> <https://docs.google.com/document/d/1iaarr4Ho715CUULrvi_LD3TwshAcN2odDLBBEK0FjH0/edit#bookmark=id.li7pdpi5uloq>
>
>
I just realized that the meeting notes are not publicly viewable.
+Panos Astithas  - would you be able to open them up
to the public somehow? (e.g. as a Chromium.org doc)


> for a couple more weeks to evaluate it and provide a position, as they
> might be planning broader-scope work on the front of application integrity,
> and want to make sure this doesn't collide with it.
>
>
> On the compatibility front, the feature is polyfilled
> <https://github.com/guybedford/es-module-shims/pull/424>, but it's turned
> off for browsers that support import maps
> <https://github.com/guybedford/es-module-shims#:~:text=The%20ES%20Module%20Shims%20polyfill%20will%20analyze%20the%20browser%20to%20see%20if%20it%20supports%20import%20maps.%20If%20it%20does%2C%20it%20doesn%27t%20do%20anything%20more>
> .
>
>
> Adding Guy Bedford, the polyfill author to this thread. Guy, can you
> confirm this is the case?
>
> *Gecko*: No signal
> <https://github.com/mozilla/standards-positions/issues/1010>
>
> *WebKit*: Support
> <https://github.com/WebKit/standards-positions/issues/335>
>
>
> WebKit PR <https://github.com/WebKit/WebKit/pull/28253> has landed.
>
>
>
>
> *Web developers*: Positive
> <https://x.com/yoavweiss/status/1778067431417954803>
> This is based on a proposal from a developer (Guy Bedford).
> Multiple Shopify properties are interested in this, to enable using ES
> modules as bundler output in security sensitive environments. Asking about
> this on twitter and mastodon showed that some developers are interested in
> this, while others discount SRI in general.
>
> *Other signals*:
>
> Activation
>
> As long as support is not ubiquitous, the `integrity` part of import maps
> will be ignored in non-supporting browsers, resulting in scripts loading in
> those browsers even if they're supposed to fail their integrity checks.
>
> There's also a polyfill
> <https://github.com/guybedford/es-module-shims/pull/424> that would
> enable sites to get integrity support for ES modules in browsers that don't
> support import maps at all. That's an increasingly slim part of the browser
> population.
>
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
>
> None
>
>
> Debuggability
>
> No issues in particular. The feature does emit a few console errors in
> cases where parsing fails, to help developers debug this.
>
>
> 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
> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
> ?Yes
>
> https://chromium-review.googlesource.com/c/chromium/src/+/5441822
>
>
> Flag name on chrome://flagsNone
>
> Finch feature nameImportMapIntegrity
>
> Requires code in //chrome?False
>
> Tracking bughttps://issues.chromium.org/issues/334251999
>
> MeasurementNo use-counter was added so far. If one is needed, I can add
> it when flipping on the flag.
>

[blink-dev] Re: Intent to Ship: Importmap integrity

On Tuesday, May 21, 2024 at 1:04:44 PM UTC+2 Yoav Weiss wrote:

Contact emailsyoavwe...@chromium.org

Explainerhttps://github.com/guybedford/import-maps-extensions#integrity

Specificationhttps://github.com/whatwg/html/pull/10269

The PR is ready to land, but we're holding off on that for 2 weeks at
Mozilla's request. See below.

Summary

Imported ES modules can't currently have their integrity checked, and hence
cannot run in environments that require Subresource Integrity or with
`require-sri-for` CSP directives. This feature adds an `integrity` section
to import maps, enabling developers to map ES module URLs to their
integrity metadata, and ensure they only load when they match their
expected hashes.

Blink componentBlink>Loader
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELoader>

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

TAG review statusIssues addressed

Risks

Interoperability and Compatibility

On the interoperability front, this got a positive position from WebKit,
and I'm implementing the feature there
<https://github.com/whatwg/html/pull/10269>. Mozilla didn't object to the
feature, but asked
<https://docs.google.com/document/d/1iaarr4Ho715CUULrvi_LD3TwshAcN2odDLBBEK0FjH0/edit#bookmark=id.li7pdpi5uloq>

for a couple more weeks to evaluate it and provide a position, as they
might be planning broader-scope work on the front of application integrity,
and want to make sure this doesn't collide with it.

On the compatibility front, the feature is polyfilled
<https://github.com/guybedford/es-module-shims/pull/424>, but it's turned
off for browsers that support import maps
<https://github.com/guybedford/es-module-shims#:~:text=The%20ES%20Module%20Shims%20polyfill%20will%20analyze%20the%20browser%20to%20see%20if%20it%20supports%20import%20maps.%20If%20it%20does%2C%20it%20doesn%27t%20do%20anything%20more>
.

Adding Guy Bedford, the polyfill author to this thread. Guy, can you
confirm this is the case?

*Gecko*: No signal
<https://github.com/mozilla/standards-positions/issues/1010>

*WebKit*: Support <https://github.com/WebKit/standards-positions/issues/335>

WebKit PR <https://github.com/WebKit/WebKit/pull/28253> has landed.

*Web developers*: Positive
<https://x.com/yoavweiss/status/1778067431417954803>
This is based on a proposal from a developer (Guy Bedford).
Multiple Shopify properties are interested in this, to enable using ES
modules as bundler output in security sensitive environments. Asking about
this on twitter and mastodon showed that some developers are interested in
this, while others discount SRI in general.

*Other signals*:

Activation

As long as support is not ubiquitous, the `integrity` part of import maps
will be ignored in non-supporting browsers, resulting in scripts loading in
those browsers even if they're supposed to fail their integrity checks.

There's also a polyfill
<https://github.com/guybedford/es-module-shims/pull/424> that would enable
sites to get integrity support for ES modules in browsers that don't
support import maps at all. That's an increasingly slim part of the browser
population.

WebView application risks

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

None

Debuggability

No issues in particular. The feature does emit a few console errors in
cases where parsing fails, to help developers debug this.

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
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
?Yes

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

Flag name on chrome://flagsNone

Finch feature nameImportMapIntegrity

Requires code in //chrome?False

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

MeasurementNo use-counter was added so far. If one is needed, I can add it
when flipping on the flag.

I decided to add a usecounter
<https://chromium-review.googlesource.com/c/chromium/src/+/942>.

Availability expectationFeature is available in WebKit within a few months
of launch in Chromium, if not before. Still waiting on Mozilla's position
and plans.

Adoption expectation
I expect web developers that want to rely on SRI for ES modules to use the
feature directly without requiring the polyfill.

Adoption planUpdate MDN <https://github.com/mdn/mdn/issues/541> on the
integrity section.

MDN PR <https://github.com/mdn/content/pull/33712>.

Estimated milestonesShipping on desktop127Shipping on Android127Shipping on
WebView127

Anticipated spec changes

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

[blink-dev] Intent to Ship: Importmap integrity

2024-05-21 Thread Yoav Weiss (@Shopify)

Contact emailsyoavwe...@chromium.org

Explainerhttps://github.com/guybedford/import-maps-extensions#integrity

Specificationhttps://github.com/whatwg/html/pull/10269

The PR is ready to land, but we're holding off on that for 2 weeks at
Mozilla's request. See below.

Summary

Imported ES modules can't currently have their integrity checked, and hence
cannot run in environments that require Subresource Integrity or with
`require-sri-for` CSP directives. This feature adds an `integrity` section
to import maps, enabling developers to map ES module URLs to their
integrity metadata, and ensure they only load when they match their
expected hashes.


Blink componentBlink>Loader


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

TAG review statusIssues addressed

Risks


Interoperability and Compatibility

On the interoperability front, this got a positive position from WebKit,
and I'm implementing the feature there
. Mozilla didn't object to the
feature, but asked

for a couple more weeks to evaluate it and provide a position, as they
might be planning broader-scope work on the front of application integrity,
and want to make sure this doesn't collide with it.


On the compatibility front, the feature is polyfilled
, but it's turned
off for browsers that support import maps

.


Adding Guy Bedford, the polyfill author to this thread. Guy, can you
confirm this is the case?

*Gecko*: No signal


*WebKit*: Support 

*Web developers*: Positive

This is based on a proposal from a developer (Guy Bedford).
Multiple Shopify properties are interested in this, to enable using ES
modules as bundler output in security sensitive environments. Asking about
this on twitter and mastodon showed that some developers are interested in
this, while others discount SRI in general.

*Other signals*:

Activation

As long as support is not ubiquitous, the `integrity` part of import maps
will be ignored in non-supporting browsers, resulting in scripts loading in
those browsers even if they're supposed to fail their integrity checks.

There's also a polyfill
 that would enable
sites to get integrity support for ES modules in browsers that don't
support import maps at all. That's an increasingly slim part of the browser
population.


WebView application risks

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


None


Debuggability

No issues in particular. The feature does emit a few console errors in
cases where parsing fails, to help developers debug this.


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

Is this feature fully tested by web-platform-tests

?Yes

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


Flag name on chrome://flagsNone

Finch feature nameImportMapIntegrity

Requires code in //chrome?False

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

MeasurementNo use-counter was added so far. If one is needed, I can add it
when flipping on the flag.

Availability expectationFeature is available in WebKit within a few months
of launch in Chromium, if not before. Still waiting on Mozilla's position
and plans.

Adoption expectation
I expect web developers that want to rely on SRI for ES modules to use the
feature directly without requiring the polyfill.

Adoption planUpdate MDN  on the
integrity section.

Estimated milestones
Shipping on desktop 127
Shipping on Android 127
Shipping on WebView 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).


No open questions.

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5157245026566144?gate=5203447331946496

Links to previous Intent discussionsIntent to prototype:

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

2024-05-17 Thread Yoav Weiss (@Shopify)

On Thu, May 16, 2024 at 10:05 PM 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.
>

Other than publishing mechanics, was the PR reviewed and good to go?


>
> On Thu, May 16, 2024 at 3:41 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>>
>>
>> On Wed, May 15, 2024 at 6:40 PM 'Sahir Vellani' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> From my understanding, we need to wait for the PointerEvents spec V3 to
>>> be published before the PR can be merged; this change is slated for the 4th
>>> iteration of the spec.
>>>
>>
>> That's an odd work mode. Do all other feature extensions just wait in PRs
>> up until publishing?
>> Even for specs that still work with levels, I'd expect "current" and
>> "future" branches, where future PRs can be merged to the "future" one as
>> they're ready..
>>
>> With that said, it seems like there's still active discussion on the PR.
>> Could we get to a state where it's reviewed by relevant folks that sign off
>> on it before shipping?
>> I agree we shouldn't wait for arbitrary publishing points before
>> shipping, but a spec review would help ensure that what we're shipping is
>> well defined.
>>
>>
>>>
>>> On Wednesday, May 15, 2024 at 9:02:52 AM UTC-7 Chris Harrelson wrote:
>>>
>>>> Hi,
>>>>
>>>> I see the spec PR is still pending. Is there a reason it can't land
>>>> before shipping?
>>>>
>>>> On Thu, May 9, 2024 at 12:23 PM 'Sahir Vellani' via blink-dev <
>>>> blin...@chromium.org> wrote:
>>>>
>>>>> Done! I've updated the explainer as well as the links in the TAG
>>>>> review.
>>>>>
>>>>> On Thursday, May 9, 2024 at 8:51:02 AM UTC-7 jyas...@chromium.org
>>>>> wrote:
>>>>>
>>>>>> Oops, Ben's not at Microsoft anymore, so you've done the best you can
>>>>>> with the Mozilla and WebKit position requests. Thanks.
>>>>>>
>>>>>> On Thu, May 9, 2024 at 8:48 AM Jeffrey Yasskin 
>>>>>> wrote:
>>>>>>
>>>>>>> If you've moved the explainer, could you replace the content of
>>>>>>> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md
>>>>>>> with a pointer to the new location? Then people who follow the old links
>>>>>>> won't be confused. You can and should also update the links in
>>>>>>> https://github.com/w3ctag/design-reviews/issues/880, and @Ben
>>>>>>> Mathwig should update the links in
>>>>>>> https://github.com/mozilla/standards-positions/issues/715 and
>>>>>>> https://github.com/WebKit/standards-positions/issues/102.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jeffrey
>>>>>>>
>>>>>>> On Wed, May 8, 2024 at 7:14 PM 'Sahir Vellani' via blink-dev <
>>>>>>> blin...@chromium.org> wrote:
>>>>>>>
>>>>>>>> I've published the spec PR. Since I can't update the links in the
>>>>>>>> original comment of this thread, I'd like to link the updated explainer
>>>>>>>> here for visibility.  
>>>>>>>> pointer-event-extensions/pointer-event-device-id-explainer.md
>>>>>>>> at main · WICG/pointer-event-extensions (github.com)
>>>>>>>> <https://github.com/WICG/pointer-event-extensions/blob/main/pointer-event-device-id-explainer.md>
>>>>>>>> I have added comments to both request-for-positions informing of
>>>>>>>> the changes to the API.
>>>>>>>> Thanks for your comments Dan!
>>>>>>>>
>>>>>>>> On Wednesday, May 8, 2024 at 6:10:48 PM UTC-7 dan...@microsoft.com
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> A non-blocking comment: now that the syntax has been changed I
>>>>>>>>> think it would be great if you could update the Explainer and the 
>>>>>>>>> Mozilla
>>>>>>>>> and WebKit requests-for-position to reduce potential for confusion.
>>>&g

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

2024-05-16 Thread Yoav Weiss (@Shopify)

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.
Do you have a rough estimate on the length of the grace period? (I'm
guessing this will not be relevant after it)


> 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?
>
> No
>
> Debuggability
>
> N/A
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> All except WebView. (Third-party cookie deprecation launches don’t include
> WebView.)
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> No
>
> Flag name on chrome://flags
>
> N/A
>
> Finch feature name
>
> base::features::TpcdMetadataStageControl
>
> Non-finch justification
>
> N/A
>
> Requires code in //chrome?
>
> No. All code for the grace period and new staged opt-out handling is in
> //components/tpcd/metadata
> 
> .
>
> Estimated milestones
>
> Client support is shipping to M125 on May 14.  Server-side file processing
> will begin some time after that date.  A separate notice will be sent when
> that process begins.
>
> Anticipated spec changes
>
> None
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5205350707101696
>
> Links to previous Intent discussions
>
> Intent to prototype:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/O9mh5XvbqqE/m/IyK22zHkAAAJ
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
>

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

2024-05-16 Thread Yoav Weiss (@Shopify)

On Wed, May 15, 2024 at 6:40 PM 'Sahir Vellani' via blink-dev <
blink-dev@chromium.org> wrote:

> From my understanding, we need to wait for the PointerEvents spec V3 to be
> published before the PR can be merged; this change is slated for the 4th
> iteration of the spec.
>

That's an odd work mode. Do all other feature extensions just wait in PRs
up until publishing?
Even for specs that still work with levels, I'd expect "current" and
"future" branches, where future PRs can be merged to the "future" one as
they're ready..

With that said, it seems like there's still active discussion on the PR.
Could we get to a state where it's reviewed by relevant folks that sign off
on it before shipping?
I agree we shouldn't wait for arbitrary publishing points before shipping,
but a spec review would help ensure that what we're shipping is well
defined.


>
> On Wednesday, May 15, 2024 at 9:02:52 AM UTC-7 Chris Harrelson wrote:
>
>> Hi,
>>
>> I see the spec PR is still pending. Is there a reason it can't land
>> before shipping?
>>
>> On Thu, May 9, 2024 at 12:23 PM 'Sahir Vellani' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Done! I've updated the explainer as well as the links in the TAG review.
>>>
>>> On Thursday, May 9, 2024 at 8:51:02 AM UTC-7 jyas...@chromium.org wrote:
>>>
 Oops, Ben's not at Microsoft anymore, so you've done the best you can
 with the Mozilla and WebKit position requests. Thanks.

 On Thu, May 9, 2024 at 8:48 AM Jeffrey Yasskin 
 wrote:

> If you've moved the explainer, could you replace the content of
> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md
> with a pointer to the new location? Then people who follow the old links
> won't be confused. You can and should also update the links in
> https://github.com/w3ctag/design-reviews/issues/880, and @Ben Mathwig 
> should
> update the links in
> https://github.com/mozilla/standards-positions/issues/715 and
> https://github.com/WebKit/standards-positions/issues/102.
>
> Thanks,
> Jeffrey
>
> On Wed, May 8, 2024 at 7:14 PM 'Sahir Vellani' via blink-dev <
> blin...@chromium.org> wrote:
>
>> I've published the spec PR. Since I can't update the links in the
>> original comment of this thread, I'd like to link the updated explainer
>> here for visibility.  
>> pointer-event-extensions/pointer-event-device-id-explainer.md
>> at main · WICG/pointer-event-extensions (github.com)
>> 
>> I have added comments to both request-for-positions informing of the
>> changes to the API.
>> Thanks for your comments Dan!
>>
>> On Wednesday, May 8, 2024 at 6:10:48 PM UTC-7 dan...@microsoft.com
>> wrote:
>>
>>> A non-blocking comment: now that the syntax has been changed I think
>>> it would be great if you could update the Explainer and the Mozilla and
>>> WebKit requests-for-position to reduce potential for confusion.
>>>
>>> Also, is there a reason the spec PR is still in Draft status? Could
>>> it be published so that there's no ambiguity for reviewers that this is
>>> (hopefully) moving forward imminently?
>>>
>>> -- Dan
>>>
>>> On Wednesday, May 8, 2024 at 2:00:38 PM UTC-7 sahir.vellani via
>>> Chromestatus wrote:
>>>
 This is ready for another review :)

>>> --
>> 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/52090dcd-f068-456d-be41-bfadbb9055d1n%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+...@chromium.org.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6034517b-2f18-4f57-b36c-dc58cdce99afn%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
>

Re: [blink-dev] New API owner: Vladimir Levin!

Congrats!! :)

On Wed, May 15, 2024 at 9:46 PM Ken Russell  wrote:

> Congratulations Vlad!
>
>
> On Wed, May 15, 2024 at 10:43 AM Mike Taylor 
> wrote:
>
>> Congrats Vlad!
>> On 5/15/24 12:22 PM, danakj wrote:
>>
>> Congrats, Vlad :)
>>
>> On Wed, May 15, 2024 at 12:19 PM Chris Harrelson 
>> wrote:
>>
>>> Hi all,
>>>
>>> I'd like to welcome Vlad as our newest API owner. He is a long-time
>>> member of the Blink community that many of you know well, and has quite a
>>> bit of experience in graphics, Blink rendering and standards.
>>>
>>> Welcome Vlad, and congratulations!
>>> --
>>> 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/CAOMQ%2Bw9BACT3QX34KLKXKkA02WccSJmACtJa1nK8eVm0PNe55Q%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/CAHtyhaTEFMFARkpKtj_4JbcHREMNQAPRxEqPDFhVO-HextRDNQ%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/419eb2b4-6eb6-499e-9321-d4caa9c4a6fb%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/CAMYvS2cUsGy0tt%3DgOezbObdnPJpnwtcz0Xp5g8KE2Wr6cb9czA%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/CAOmohSK7p%3Dc-R4dY8Cvy75_SOs7oGZ1qSHyhVqfyLkBefTqeBQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Deprecate Mutation Events

On Wed, May 15, 2024 at 9:03 PM Mason Freed  wrote:

> Contact emailsmas...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://w3c.github.io/uievents/#legacy-event-types
>
> Summary
>
> Mutation Events, including `DOMSubtreeModified`, `DOMNodeInserted`,
> `DOMNodeRemoved`, `DOMNodeRemovedFromDocument`,
> `DOMNodeInsertedIntoDocument`, and `DOMCharacterDataModified`, are quite
> bad for page performance, and also significantly increase the complexity of
> adding new features to the Web. These APIs were deprecated from the spec (
> https://w3c.github.io/uievents/#legacy-event-types) in 2011, and were
> replaced (in 2012) by the much better-behaved Mutation Observer API. Usage
> of the obsolete Mutation Events must now be migrated to Mutation Observer.
> Mutation event support will be disabled by default starting in Chrome 127,
> around July 30, 2024. Code should be migrated before that date to avoid
> site breakage. If more time is needed, there are a few options: - The
> Mutation Events Deprecation Trial (
> https://developer.chrome.com/origintrials/#/view_trial/919297273937002497)
> can be used to re-enable the feature for a limited time on a given site.
> This can be used through Chrome 134, ending March 25, 2025. - A
> MutationEventsEnabled enterprise policy (
> https://chromeenterprise.google/policies/#MutationEventsEnabled) can also
> be used for the same purpose, also through Chrome 134. Please see this blog
> post for more detail:
> https://developer.chrome.com/blog/mutation-events-deprecation Report bugs
> here: https://issues.chromium.org/new?component=1456718=1948649
>
>
> Blink componentBlink>DOM
> 
>
> Search tagsMutationEvent
> , DOMSubtreeModified
> ,
> DOMNodeInserted ,
> DOMNodeRemoved ,
> DOMNodeRemovedFromDocument
> ,
> DOMNodeInsertedIntoDocument
> ,
> DOMCharacterDataModified
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Chromium Trial NameMutationEvents
>
> Origin Trial documentation link
> https://developer.chrome.com/blog/mutation-events-deprecation
>
> WebFeature UseCounter namekDOMNodeRemovedEvent
>
> Risks
>
>
> Interoperability and Compatibility
>
> There are technically 9 Mutation Events, but Chromium only implements 6 of
> them. Their use counters vary significantly: - DOMNodeInsertedIntoDocument:
> 0.008% - DOMNodeRemovedFromDocument: 0.009% - DOMCharacterDataModified:
> 0.011% - DOMNodeRemoved: 0.73% - DOMSubtreeModified: 0.68% -
> DOMNodeInserted: 1.086%
>

1% is a *lot*. Did UKM reveal anything interesting about this usage? Do we
know if all of it is driven by site content, vs e.g. extensions?


> Chrome has shipped an experiment since M124 that disables all Mutation
> Events for 99% of users of Canary, Dev, and Beta versions of Chrome. Very
> few bugs have been filed in the intervening months, and all that were filed
> have been resolved quickly via the site owner making changes to not rely on
> the deprecated events.
>
This gives me significant confidence that removing the events will not be
> as big of a deal as the use counters would suggest. Still, due to the
> still-high numbers, extreme care will be taken in the removal process. I
> plan to disable the events via Finch only, so that if issues are
> encountered, Finch will be a safe way to re-enable the events.
> Additionally, there are the deprecation trial and enterprise policies to
> offer an easy relief valve for affected sites.
>
>
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/807) "very strong
> positive position"
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/192)
>
> *Web developers*: No signals
>
> *Other signals*:
>
> Activation
>
> This npm package attempts to polyfill Mutation Events using Mutation
> Observer: https://www.npmjs.com/package/mutation-events.
>
>
> 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
>
>
>
> 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://flagsmutation-events
>
> Finch feature nameMutationEvents
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1446498
>
> Estimated milestones
>

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

LGTM3

On Wed, May 15, 2024 at 6:02 PM Daniel Bratell  wrote:

> LGTM2
>
> /Daniel
> On 2024-05-15 07:13, Domenic Denicola wrote:
>
> LGTM1.
>
> I have a small non-blocking request: update your Chrome Status entry to
> avoid using ClassName.staticMethod() syntax for what appears to be an
> instance method. (See e.g. this related discussion
>  and this bug I filed on
> Chrome Status a year ago
> .) This
> will avoid a confusing experience for web developers when this information
> makes its way into the beta blog post and other documentation.
>
> On Wednesday, May 15, 2024 at 5:49:30 AM UTC+9 Eugene Zemtsov wrote:
>
>> By reading an MDN article that I'll update after the launch.
>>
>> Even now allocationSize() is supposed to be called before copyTo()
>> anyway, to figure out the size of the buffer for the output. (see example
>> 1,
>> example2
>> 
>> )
>> That's why I don't think that it's an ergonomic burden for developers.
>>
>> On Tue, May 14, 2024 at 1:41 PM Mike Taylor 
>> wrote:
>>
>>> Ergonomics-wise, it does not seem intuitive to use a method called
>>> allocationSize() to feature detect copyTo support, even if the semantics
>>> are the same. Besides a very careful reading of the spec, how do we expect
>>> developers to know about it?
>>> On 5/14/24 4:32 PM, Eugene Zemtsov wrote:
>>>
>>> In that discussion Marcos Cáceres asked for a synchronous way to detect
>>> if format conversion is supported.
>>> We have a synchronous call allocationSize()
>>>  that
>>> throws an unsupported error in cases where format conversion is not
>>> supported.
>>> I added a WPT test around it in a recent CL
>>> .
>>>
>>> canCopyTo() might be needed if we have more settings in
>>> VideoFrameCopyToOptions
>>>  and
>>> might want to know which part exactly is causing an error.
>>>
>>> On Tue, May 14, 2024 at 12:25 PM Mike Taylor 
>>> wrote:
>>>
 I see that WebKit raised an API concern around detectability
 .
 In your reply, you said "we should consider...". Has that consideration
 happened, perhaps as follow-up work? :)
 On 5/8/24 4:05 PM, Eugene Zemtsov wrote:

 This feature has Privacy, Security, Enterprise, and Debuggability
 approvals. Webkit gave a positive signal.

 Any objections or questions from the API owners?



 On Wed, May 1, 2024 at 4:26 PM Eugene Zemtsov 
 wrote:

> I've filed issues for TAG review and firefox and webkit positions.
>
> >  Have you looked into other platform APIs that could benefit from
> being able to explicitly specify intermediate format hinting and/or
> transformation?
> I don't think this kind of review can be done for all web APIs by one
> person. It's up to spec editors in each area to identify these small
> changes that improve dev experience and performance.
>
> For media related things:
> -  VideoFrame is a versatile tool that can be created from
> HTMLOrSVGImageElement, HTMLVideoElement, HTMLCanvasElement,
> ImageBitmap,
>  OffscreenCanvas without a copy. In a way this change extends
> variety of export formats for all of them.
> So lots of things can be exported to RGB bitmaps without a canvas
> now.
> -  AudioData has a way to be exported into different sampling formats.
>
>
>
> On Wed, May 1, 2024 at 9:41 AM Mike Taylor 
> wrote:
>
>> +1. Would you mind also filing gecko and webkit positions? I expect
>> them to be positive, given the informal signals you have in the spec PRs
>> already - but this also lets them know we're moving ahead with shipping.
>> Thanks - Mike
>> On 5/1/24 11:51 AM, Alex Russell wrote:
>>
>> hey Eugene,
>>
>> This is an exciting an useful addition! Have you looked into other
>> platform APIs that could benefit from being able to explicitly specify
>> intermediate format hinting and/or transformation? It's a place where 
>> (had
>> the TAG been consulted) I would have expected to see a larger chain of
>> additions to make this work in other areas, or at least a discussion of 
>> why
>> they aren't (or are?) being pursued. Have you looked into that?
>>
>> Best,
>>
>> Alex
>>
>> On Tuesday, April 30, 2024 at 3:51:01 PM UTC-7 Eugene Zemtsov wrote:
>>
>>> > Can you please request reviews for privacy, security, enterprise,
>>> etc in the chromestatus entry?
>>>

Re: [blink-dev] Request for Deprecation Trial: Media Previews opt-out

Can you expand on how (if) this is different from the past intent 

 
with a similar title?

On Monday, May 13, 2024 at 7:21:48 PM UTC+2 Mike Taylor wrote:

> FWIW, a deprecation trial can surpass 6 milestones - but they require 
> sufficient justification as well as 3 LGTMs. 
>
> That said, I'm not sure I understand the request here. I read the linked 
> "Chrome Camera and Mic Previews" document, but I think the Rollout plan 
> section is assuming more info than I have. Could you explain how this 
> feature and PEPC relate, and why having them work together is a bad thing? 
> Do you plan to deprecate one of the features once the Deprecation Trial is 
> finished? (Or are you just requesting an Origin Trial to temporarily 
> disable something, and expect it to be re-enabled in the future?)
>
> Something that approaches an Explainer would probably be helpful here - 
> thanks!
>
> On 5/10/24 5:05 PM, mark a. foltz wrote:
>
> I'm fine with shortening the trial, as long as extensions are possible in 
> case we need longer to ship a long-term solution.
>
> On Fri, May 10, 2024 at 12:39 PM Vladimir Levin  
> wrote:
>
>>
>>
>> On Fri, May 10, 2024 at 2:40 PM mark a. foltz  
>> wrote:
>>
>>> Contact emails mfo...@chromium.org, bryantchand...@chromium.org
>>>
>>> Explainer None
>>>
>>> Specification 
>>> https://docs.google.com/document/d/1ZnX2JROjr9l4y2_OPMpfVlLOo-A5cQzD4mWarj9kXQ0/edit
>>>
>>> Design docs 
>>>
>>> https://docs.google.com/document/d/1ZnX2JROjr9l4y2_OPMpfVlLOo-A5cQzD4mWarj9kXQ0/edit
>>>
>>> Summary 
>>>
>>> Allow coordination between sites using Page Embedded Permissions 
>>> Controls and concurrent experiments with the camera and microphone 
>>> permissions UI in Chrome.
>>>
>>>
>>> Blink component Blink>MediaStream 
>>> 
>>>
>>> TAG review None
>>>
>>> TAG review status Not applicable
>>>
>>> Chromium Trial Name MediaPreviewsOptOutPersistent
>>>
>>> Origin Trial documentation link 
>>> https://docs.google.com/document/d/1ZnX2JROjr9l4y2_OPMpfVlLOo-A5cQzD4mWarj9kXQ0/edit?usp=sharing
>>>
>>> WebFeature UseCounter name kOBSOLETE_PageDestruction
>>>
>>> Risks 
>>>
>>>
>>> Interoperability and Compatibility 
>>>
>>> None as this feature concerns the functionality of Chrome's permissions 
>>> UI, and does not change the behavior of the APIs that are gated by it: 
>>> navigator.mediaDevices.enumerateDevices and 
>>> navigator.mediaDevices.getUserMedia Other browsers implement their own 
>>> permissions UIs independently of Chrome. 
>>>
>>>
>>> *Gecko*: N/A
>>>
>>> *WebKit*: N/A
>>>
>>> *Web developers*: No signals
>>>
>>> *Other signals*:
>>>
>>> Ergonomics 
>>>
>>> N/A
>>>
>>>
>>> Activation 
>>>
>>> N/A
>>>
>>>
>>> Security 
>>>
>>> N/A
>>>
>>>
>>> WebView application risks 
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such 
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> None
>>>
>>>
>>> Goals for experimentation 
>>>
>>> Ongoing technical constraints 
>>>
>>> There are no plans to add media previews to Chrome on platforms other 
>>> than Windows/Mac/Linux.
>>>
>>>
>>> Debuggability 
>>>
>>> N/A
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>>> Linux, ChromeOS, Android, and Android WebView)? No 
>>>
>>> There are currently no plans to launch previews outside of 
>>> Windows/Mac/Linux.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests 
>>> 
>>> ? No 
>>>
>>> N/A
>>>
>>>
>>> DevTrial instructions https://tinyurl.com/yc6mvth8
>>>
>>> Flag name on chrome://flags --enable-features=camera-mic-preview
>>>
>>> Finch feature name CameraMicPreview
>>>
>>> Requires code in //chrome? False
>>>
>>> Tracking bug https://issues.chromium.org/330762482
>>>
>>> Launch bug https://launch.corp.google.com/launch/4304480
>>>
>>> Estimated milestones 
>>> Origin trial desktop first 126 
>>> Origin trial desktop last 137 
>>> DevTrial on desktop 122 
>>>
>>
>> According to 
>> https://www.chromium.org/blink/launching-features/#deprecation-trial, 
>> deprecation trials should only run for up to 6 milestones before an 
>> extension is required, so this may need to be adjusted
>>
>>
>>>
>>> Link to entry on the Chrome Platform Status 
>>> https://chromestatus.com/feature/5100528783851520?gate=5123374989967360
>>>
>>> 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 
>>>

[blink-dev] Re: Intent to Ship: Stop modifying author-defined selection colors

LGTM1

On Thursday, May 9, 2024 at 1:41:40 AM UTC+2 Stephen Chenney wrote:

> Contact emailsschen...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://www.w3.org/TR/css-pseudo-4/#highlight-selectors
>
> SummaryChromium currently checks all selection highlight colors against 
> the text color and inverts the highlight color if it matches the text. 
> Hence, author-defined ::selection CSS properties may be modified by the 
> browser despite explicit author intent. For example, a CSS rule 
> "::selection { color: cyan; background: cyan; }" the background is inverted 
> and red color is used. In https://github.com/w3c/csswg-drafts/issues/6150 
> the CSS Working Group resolved to disallow the chromium behavior. We 
> propose to implement this spec change and bring chromium into compatibility 
> with other browsers.
>
> Blink componentBlink>CSS 
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> Low risk. Gecko and WebKit both respect author colors from 
> ::selection already. The change makes chromium compatible. It is highly 
> unlikely that authors are depending on chromium behavior given it is hard 
> to predict and the number of people who have looked at the workarounds. 
> Note the workarounds (adding some transparency) will not be broken by the 
> change.
>
>
> *Gecko*: Shipped
>
> *WebKit*: Shipped
>
> *Web developers*: 
> https://stackoverflow.com/questions/14970891/css-selection-color-behaving-strangely-on-chrome
>
> *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
>
> Improved because the rendered result now matches the colors specified by 
> authors and reported in DevTools.
>
>
> 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
>
> Flag name on chrome://flagsNone
>
> Finch feature nameSelectionRespectsColors
>
> Non-finch justification
>
> The change has been behind Experimental Web Platform Features for 4 
> months, with no issues reported.
>
>
> Requires code in //chrome?False
>
> Tracking bughttps://issues.chromium.org/issues/40771258
>
> Estimated milestones
> Shipping on desktop 127
> Shipping on Android 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/5657973985640448?gate=6583848377253888
>

-- 
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/357a778c-cd0e-4468-9c90-2dc48e051a24n%40chromium.org.

Re: [blink-dev] Re: Intent to Experiment: Element Capture

LGTM3

On Tue, May 14, 2024 at 8:40 PM Chris Harrelson 
wrote:

> LGTM2
>
> On Tue, May 14, 2024 at 11:36 AM Mike Taylor 
> wrote:
>
>> OK - thanks for the clarification. I would ask that you get in touch with
>> every registered origin - expiring the experiment early may be surprising.
>>
>> LGTM1 to experiment from M127 to M132 inclusive.
>> On 5/14/24 12:08 PM, Elad Alon wrote:
>>
>> I'm asking for a break-off period starting July 1 and ending July 22
>> (inclusive). That means that the original trial will end on June 30, and be
>> restarted on July 23. This corresponds to breaking the original experiment
>> early during the cycle of what would have otherwise been its final
>> milestone (m126), the restarting the experiment over the m127-m132 range.
>> (CC Panos for feasibility.)
>>
>> On Friday, May 10, 2024 at 10:25:03 PM UTC+2 mike...@chromium.org wrote:
>>
>>> Note: Because you're asking for a renewal of 6 milestones, this will
>>> require 3 LGTMs.
>>>
>>> Can you clarify which milestones you're asking for? You've written
>>> "(2024-May-14 to 2024-Jun-04)" - that range maps to M125 and M126 stable
>>> releases.
>>> On 5/10/24 6:44 AM, 'Elad Alon' via blink-dev wrote:
>>>
>>> Hello Blink owners,
>>>
>>> We are asking for a breaking period of 3 weeks to this API, followed by
>>> a renewed experiment for the traditional 6 milestones (2024-May-14 to
>>> 2024-Jun-04). A request
>>> 
>>> that seems similar to me was granted in January 2022 for another API, and
>>> later shipped successfully with consensus with Mozilla and Apple.
>>>
>>> At the time of writing, we have public support
>>> 
>>> for this API from such companies as Zoom, Jitsi, Mux, DialPad, Whereby,
>>> Intel and Tella. Tango’s co-founder wrote
>>> 
>>> “I can't emphasize enough how instrumental this specification would be for
>>> our product and user experience.” However, none of them have signed up for
>>> the OT as of yet.
>>>
>>> From the OT perspective:
>>>
>>> This API allows Web developers to build novel new features; however, it
>>> requires a non-trivial investment. We are hoping that after giving more
>>> time, we will see more participation.
>>>
>>> From the standardization perspective:
>>>
>>> We need time to pick up discussions with Mozilla and Apple again. As
>>> Chrome’s Security and Privacy experts do not share the concerns Mozilla and
>>> Apple have previously voiced, it stands to reason that additional
>>> discussions will allow us to converge - and we will prioritize these
>>> discussions now.
>>>
>>> Additionally, some possibilities remain for API changes that could
>>> perhaps allow for a compromise, mostly around cross-origin isolation. (Full
>>> disclosure - this is not my ideal outcome, but it’s a fallback possibility
>>> worth mentioning.)
>>>
>>> Progress made:
>>>
>>>-
>>>
>>>Spec: The spec has evolved and is now more mature, dealing better
>>>with such edge cases as loss of “eligibility for restriction.”
>>>-
>>>
>>>TAG: Previously we held off on the request for a TAG review until we
>>>got some more developer feedback about the API shape. Having received 
>>> this
>>>initial feedback, the TAG request
>>> has now been
>>>submitted.
>>>-
>>>
>>>Signals: Signals have been requested. Mozilla responded. We intend
>>>to prioritize this discussion with them now.
>>>-
>>>
>>>Feedback: Outreach for feedback from the spec community - multiple
>>>issues
>>>
>>>were filed on the spec by Web developers.
>>>-
>>>
>>>WPT: Coverage has recently been extended
>>>
>>> 
>>>.
>>>
>>>
>>> Reasons to run a new trial:
>>>
>>> Gain additional feedback from new participants. Examples for remaining
>>> areas where new feedback could help include:
>>>
>>>-
>>>
>>>Uncover new edge cases which were not uncovered by the spec authors
>>>and reviewers, implementers and current OT participants. The current edge
>>>cases here
>>>
>>> 
>>>demonstrate how non-obvious these may be.
>>>-
>>>
>>>Validate (or refute) the assumptions we have made about the
>>>viability of an MVP that is missing some functionality. Examples:
>>>-
>>>
>>>   Events notifying apps when an element stops/starts being
>>>   “eligible for restriction”.
>>>   -
>>>
>>>   Mechanism to force elements into

[blink-dev] Re: Intent to Ship: Protected Audience: reporting timeouts & multiple-bids



On Monday, May 6, 2024 at 10:03:16 PM UTC+2 Paul Jensen wrote:

Contact emails

pauljen...@chromium.org


Explainer

Protected Audience reporting timeouts: https://github.com/WICG/
turtledove/pull/1101

Protected Audience multiple-bids: https://github.com/WICG/
turtledove/pull/1048


Specification

Protected Audience reporting timeouts: https://github.com/WICG/
turtledove/pull/1102

Protected Audience multiple-bids: https://github.com/WICG/
turtledove/pull/1138


Summary

Protected Audience (PA) reporting timeouts:

After a PA auction finishes selecting an ad and that ad is allowed to start 
rendering, the browser then runs a JavaScript function from the seller(s) 
and winning buyer to assemble reports that are sent back to their servers. 
These functions are currently given 50ms to run, after which they're 
aborted. We've heard feedback from users of the API that 50ms may not be 
sufficient to assemble the reports and may result in broken billing and 
other basic functionality, resulting in lower website revenue.  We’re 
proposing making the timeout configurable up to 5s. (This JavaScript 
generally runs in a separate process, i.e. off the main thread.)


I'm concerned about this timeout, tbh.
It feels very arbitrary and if set by the wrong party, it can create some 
adversarial effects.
Can you expand on why do we need a configurable timeout here, rather than 
just increasing it for everyone?
If a configurable timeout is indeed needed, am I correct that the timeout 
would be set by the publisher, and its consequences would be felt by the 
seller?

Also, can you expand on "This JavaScript generally runs in a separate 
process"? Where is it run?


Protected Audience multiple-bids:

Presently buyers participating in PA ad selection auctions are only allowed 
to return one bid per interest group stored on a user's device. This has a 
couple downsides:

   1. 
   
   When that one bid does not pass the k-anonymity threshold, the bid 
   generation logic must be invoked again which can be slow, potentially 
   doubling auction runtime.
   2. 
   
   This preferences adtechs that store more interest groups on device as a 
   way to get more bids into the auction. Many interest groups on device is 
   something we publicly have stated is undesirable: 
   https://developers.google.com/privacy-sandbox/relevance/
   protected-audience-api/latency#fewer_interest_group_owners 
   

   
To fix this we're allowing bidding scripts to return multiple bids.


Blink component

Blink>InterestGroups 



TAG review

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


TAG review status

Completed for Protected Audience, resolved unsatisfied.


RisksInteroperability and Compatibility

Both features represent optional new behavior that shouldn’t break existing 
usage.


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


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


I'd love for the Edge team to review this, if at all possible.
I know it's exceeding the bounds of our process, but given the lack of 
interest in reviewing this from the TAG, Mozilla and Apple, and the ongoing 
complexity of this feature, it's be great to try and get some deep 
technical review from a different browser team.
 


Web developers:

Protected Audience reporting timeouts: Multiple companies requesting on Github 
issue  and WICG meeting 
though notes 

 
are missing several comments from others.

Protected Audience multiple-bids: 3+ companies requesting on Github issue 
, discussed in 6 different WICG 
meetings 

.


Debuggability

PA reporting and bidding scripts are debuggable in DevTools.  Generated 
bids also show up in the Application -> Storage -> Interest Groups DevTools 
pane.


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

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


Is this feature fully tested by web-platform-tests

[blink-dev] Re: Intent to Ship: Document picture-in-picture: propagate user activation

2024-05-08 Thread Yoav Weiss (@Shopify)

LGTM1

On Tuesday, May 7, 2024 at 11:33:01 PM UTC+2 Tommy Steimel wrote:

> Contact emailsstei...@chromium.org, liber...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://github.com/WICG/document-picture-in-picture/pull/117
>
> Design docs
>
> https://docs.google.com/document/d/1vtjK3iMEAjcfDCu-qZOYg2zAtTbhohmCX77T1Eu3usQ/edit?usp=sharing
>
> Summary
>
> This makes user activations in a document picture-in-picture window usable 
> inside its opener window and vice versa. This makes it more ergonomic to 
> use user-activation-gated APIs, since often event handlers in the document 
> picture-in-picture window are actually run in the opener's context, so the 
> opener's context needs access to the user gesture.
>
>
> Blink componentBlink>Media>PictureInPicture 
> 
>
> TAG review
> https://github.com/w3ctag/design-reviews/issues/798#issuecomment-2096837171
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: No signal (
> https://github.com/mozilla/standards-positions/issues/670#issuecomment-2096824367
> )
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/41#issuecomment-2096824691
> )
>
> *Web developers*: No signals
>
> *Other signals*:
>
> Ergonomics
>
> This should improve the ergnomics of user-activation-gated APIs in 
> document picture-in-picture windows, as the website no longer needs to 
> ensure that the user gesture occurred in the same context as the code that 
> is calling the API.
>
>
> Activation
>
> N/A
>
>
> Security
>
> One potential risk is that the website could use the same gesture as two 
> gestures (by using it in the opener and in the picture-in-picture window). 
> We mitigate this by ensuring that consuming user activation in one uses it 
> in the other.
>
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that 
> it has potentially high risk for Android WebView-based applications?
>
> N/A
>
>
> Debuggability
>
> N/A
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, ChromeOS, Android, and Android WebView)?No
>
> Document picture-in-picture is only available on desktop platforms
>
>
> Is this feature fully tested by web-platform-tests 
> 
> ?Yes
>
> document-picture-in-picture/propagate-user-activation-from-opener.https.html 
> document-picture-in-picture/propagate-user-activation-to-opener.https.html
>
>
> Flag name on chrome://flagsdocument-picture-in-picture-user-activation
>
> Finch feature nameDocumentPictureInPictureUserActivation
>
> Requires code in //chrome?False
>
> Tracking bughttps://issues.chromium.org/331246719
>
> Sample links
> https://steimelchrome.github.io/document-pip/user-gesture.html
>
> Estimated milestones
> Shipping on desktop 126
>
> 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).
> N/A
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5185710702460928?gate=5078256593403904
>
> Links to previous Intent discussionsIntent to prototype: 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE-AwApczWrtoZNMqtAJx-%2BNAxVF9Kqim2h1HBrAD3ukXTKgWA%40mail.gmail.com
>
> This intent message was generated by Chrome Platform Status 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8e5d025d-9351-47d4-a79a-f7f23c88851dn%40chromium.org.

Re: [blink-dev] Intent to Ship: Tabbed web apps

2024-05-07 Thread Yoav Weiss (@Shopify)

Can you elaborate on the cross-platform story here? What kind of fallback
do we expect developers to use in non-supporting platforms?

On Tue, May 7, 2024 at 12:34 AM Marijn Kruisselbrink 
wrote:

> I don't think there are major technical reasons, no. With some rough edges
> the flagged implementation should more or less work on other
> desktop platforms as well. My understanding is that this is largely a
> product choice and a choice not to prioritize the remaining engineering
> needed to clean up the rough edges on other desktop platforms.
>
> On Mon, May 6, 2024 at 3:29 PM Daniel Herr 
> wrote:
>
>> May I ask why? I've tried out the flagged implementation on Chrome OS,
>> and I think it is a pretty nice UI paradigm. I don't see any technical
>> reason it shouldn't be available on other platforms.
>>
>> On Monday, May 6, 2024 at 10:30:58 AM UTC-4 Brett Wilson wrote:
>>
>>> On Mon, May 6, 2024 at 3:02 AM Yoav Weiss (@Shopify) <
>>> yoav...@chromium.org> wrote:
>>>
>>>>
>>>>
>>>> On Fri, May 3, 2024 at 7:28 PM Brett Wilson 
>>>> wrote:
>>>>
>>>>> Contact emailsbre...@chromium.org, alanc...@chromium.org,
>>>>> mgi...@chromium.org, loub...@google.com
>>>>>
>>>>> Explainer
>>>>> https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md
>>>>>
>>>>> Specificationhttps://wicg.github.io/manifest-incubations/#dfn-tabbed
>>>>>
>>>>> Summary
>>>>>
>>>>> Allow web app windows to have a tab strip. This adds a new display
>>>>> mode "tabbed" and a new manifest field to allow customizations to the tab
>>>>> strip.
>>>>>
>>>>>
>>>>> Blink componentBlink>AppManifest
>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EAppManifest>
>>>>>
>>>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/841
>>>>>
>>>>> TAG review statusIssues addressed
>>>>>
>>>>> Chromium Trial NameWebAppTabStrip
>>>>>
>>>>> Link to origin trial feedback summary
>>>>> https://github.com/WICG/manifest-incubations/issues
>>>>>
>>>>> Origin Trial documentation link
>>>>> https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md
>>>>>
>>>>> Risks
>>>>>
>>>>>
>>>>> Interoperability and Compatibility
>>>>>
>>>>>
>>>>>
>>>>> *Gecko*: Defer (
>>>>> https://github.com/mozilla/standards-positions/issues/811)
>>>>>
>>>>> *WebKit*: No signal (
>>>>> https://github.com/WebKit/standards-positions/issues/195)
>>>>>
>>>>> *Web developers*: Positive (https://github.com/w3c/manifest/issues/737
>>>>> )
>>>>>
>>>>> *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?
>>>>>
>>>>> N/A
>>>>>
>>>>>
>>>>> Debuggability
>>>>>
>>>>> chrome://web-app-internals can be used for debugging, and the new
>>>>> manifest field could also be added to the DevTools Application pane.
>>>>>
>>>>>
>>>>> Will this feature be supported on all six Blink platforms (Windows,
>>>>> Mac, Linux, ChromeOS, Android, and Android WebView)?No
>>>>>
>>>>> The origin trial is available on ChromeOS only. Support for other
>>>>> desktop platforms is planned.
>>>>>
>>>>>
>>>>> Is this feature fully tested by web-platform-tests
>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>>> ?Yes
>>>>>
>>>>>
>>>>> https://github.com/web-platform-tests/wpt/tree/master/appmanifest/display-override-member
>>>>>
>>>>>
>>>>> Flag name on chrome://flags
>>>>> chrome://flags/#enable-desktop-pwas-tab-strip
>>>>>
>>>>> Finch feature nameDesktopPWAsTabStrip
>>>&

Re: [blink-dev] Intent to Ship: Tabbed web apps

2024-05-06 Thread Yoav Weiss (@Shopify)

On Fri, May 3, 2024 at 7:28 PM Brett Wilson  wrote:

> Contact emailsbre...@chromium.org, alancut...@chromium.org,
> mgi...@chromium.org, loubr...@google.com
>
> Explainer
> https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md
>
> Specificationhttps://wicg.github.io/manifest-incubations/#dfn-tabbed
>
> Summary
>
> Allow web app windows to have a tab strip. This adds a new display mode
> "tabbed" and a new manifest field to allow customizations to the tab strip.
>
>
> Blink componentBlink>AppManifest
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/841
>
> TAG review statusIssues addressed
>
> Chromium Trial NameWebAppTabStrip
>
> Link to origin trial feedback summary
> https://github.com/WICG/manifest-incubations/issues
>
> Origin Trial documentation link
> https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> *Gecko*: Defer (https://github.com/mozilla/standards-positions/issues/811)
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/195)
>
> *Web developers*: Positive (https://github.com/w3c/manifest/issues/737)
>
> *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?
>
> N/A
>
>
> Debuggability
>
> chrome://web-app-internals can be used for debugging, and the new manifest
> field could also be added to the DevTools Application pane.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?No
>
> The origin trial is available on ChromeOS only. Support for other desktop
> platforms is planned.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
>
> https://github.com/web-platform-tests/wpt/tree/master/appmanifest/display-override-member
>
>
> Flag name on chrome://flagschrome://flags/#enable-desktop-pwas-tab-strip
>
> Finch feature nameDesktopPWAsTabStrip
>
> Requires code in //chrome?True
>
> Tracking bughttps://issuetracker.google.com/issues/40598974
>
> Launch bughttps://launch.corp.google.com/launch/4253814
>
> MeasurementLaunch.WebAppDisplayMode: Tabbed
>
> Availability expectationFeature is available only on Chrome-on-ChromeOS
> for the foreseeable future.
>

This seems a bit contradictory with "Support for other desktop platforms is
planned" above. Are there plans for support beyond CrOS?


>
>
> Adoption expectationFeature is used by specific partner(s) to provide
> functionality within 12 months of launch in Chrome. May be of interest to a
> handful of PWA authors primarily in the productivity space.
>
> Adoption planWorking with a small number of partners directly.
>
> Non-OSS dependencies
>
> Does the feature depend on any code or APIs outside the Chromium open
> source repository and its open-source dependencies to function?
> N/A
>
> Sample links
> https://paint-rightful-patch.glitch.me
>
> Estimated milestones
> Shipping on desktop 126
> Origin trial desktop first 118
> Origin trial desktop last 126
> Origin trial extension 1 end milestone 126
>
> 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).
> Chromium implementation currently does not parse string-form URL patterns
> as required by the spec. Marked "at risk". (
> https://github.com/WICG/manifest-incubations/issues/97)
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5128143454076928?gate=6176288199409664
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/IvfIkjvQYuY/m/cixwOyEeAAAJ
>  Intent
> to Experiment:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/m16m2TEq-NM/m/0Bc10numCgAJ
> Intent to Extend Experiment 1:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/5aRDL-E9olQ/m/Pb7ECdcpAAAJ
> Intent to Ship:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/5aRDL-E9olQ/m/Pb7ECdcpAAAJ
>
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
>

Re: [blink-dev] Intent to Extend Experiment: WebRTC encoded transform - Modify Metadata functions (setMetadata method)

2024-05-03 Thread Yoav Weiss (@Shopify)

LGTM to extend experimentation until M129 inclusive

On Fri, May 3, 2024 at 5:05 PM Guido Urdaneta  wrote:

> Yes, but since the main motivation is to let developers migrate to the
> final version of the API (which changed in the last milestone of the
> original OT), it would be acceptable to have a shorter extension. This is,
> of course, assuming the I2S for the final version of the API is approved.
>

That's fine! :)


>
> On Fri, May 3, 2024 at 2:39 PM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>> Do I understand correctly that you want to extend the OT for 3 more
>> milestones, up to 129 (inclusive)?
>>
>>
>>
>> On Thu, May 2, 2024 at 2:45 PM Guido Urdaneta 
>> wrote:
>>
>>> Contact emails...@chromium.org, gui...@chromium.org,
>>> agpa...@chromium.org
>>>
>>> Explainer
>>> https://github.com/guidou/webrtc-extensions/blob/main/constructor-explainer.md
>>>
>>> Specification
>>> https://w3c.github.io/webrtc-encoded-transform/#dom-rtcencodedvideoframe-constructor
>>>
>>> Summary
>>>
>>> Allow WebRTC Encoded Transform API to manipulate audio and video frame
>>> metadata. Some WebRTC Encoded Transform use cases involve manipulation of
>>> not only the payload of encoded video / audio frames but also its metadata.
>>> For example, if a peer connection negotiates a custom codec and an encoded
>>> transform is used to implement part or all of the the custom codec and
>>> needs to set the output codec type as part of the metadata of the output
>>> frame. See https://www.w3.org/2024/04/23-webrtc-minutes.html#t01
>>>
>>>
>>>
>>> Blink componentBlink>WebRTC
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebRTC>
>>>
>>> TAG reviewThe original full spec was reviewed by TAG here:
>>> https://github.com/w3ctag/design-reviews/issues/531
>>> No TAG review requested yet for the setMetadata method (during the
>>> Working Group discussion it was decided to use a constructor, but interest
>>> in the method version was recently revived).
>>>
>>>
>>> Other use cases:
>>>
>>> https://w3c.github.io/webrtc-nv-use-cases/#live-encoded-media
>>>
>>> https://w3c.github.io/webrtc-nv-use-cases/#stored-encoded-media
>>>
>>> https://w3c.github.io/webrtc-nv-use-cases/#auction
>>>
>>> TAG review statusPending
>>>
>>> Chromium Trial NameRTCEncodedFrameSetMetadata
>>>
>>> Origin Trial documentation link
>>> https://github.com/palak8669/webrtc-encoded-transform/blob/create-encoded-explainer/create-encoded-explainer.md
>>>
>>> WebFeature UseCounter nameRTCEncodedFrameSetMetadata
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Interoperability risk: There is always the risk that other browsers will
>>> not implement this feature. This risk is mitigated by alignment across
>>> browser vendors in the W3C WebRTC Working Group around the spec.
>>> Compatibility risk: This is a new feature intended to support new use
>>> cases. It introduces no breaking changes, so we do not expect any
>>> compatibility issues.
>>>
>>> *Gecko*: No signal
>>> However, they have shown interest in reviving the discussion for the
>>> setMetadata() method after achieving consensus on the Custom Codec
>>> negotiation API for WebRTC Encoded Transform.
>>>
>>> *WebKit*: No signal
>>>
>>> *Web developers*: Positive
>>>
>>> *Other signals*:
>>>
>>> Ergonomics
>>>
>>> This feature is an extension to WebRTC Encoded Transform, which itself
>>> is an extension to WebRTC/RTCPeerConnection.
>>>
>>>
>>> Activation
>>>
>>> No significant risks identified.
>>>
>>>
>>> Security
>>>
>>> No new security risks identified.
>>>
>>>
>>> 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?
>>>
>>> No
>>>
>>>
>>> Goals for experimentation
>>>
>>> Determine if the proposed API properly supports the intended use case.
>>>
>>>
>>> Reason this experiment is being extended
>>>
>>> There are two rea

Re: [blink-dev] Intent to Ship: Adding Cross-site Ancestor Chain Bit to CHIPS Partition Key

2024-05-03 Thread Yoav Weiss (@Shopify)

Thanks for diving into this!!

I guess the scariest bit here would be paypal losing a cookie in the
redirect. Even if you didn't find a visible impact in your testing, they
may not be exhaustive, and breakage there feels riskier than in other
mentioned domains.

Have you tried to reach out to Paypal folks and see what they say?

On Wed, May 1, 2024 at 8:05 PM Aaron Selya  wrote:

> My apologies for the delay in following up on this.
>
> When I finished my initial implementation and got to the point where I
> could begin testing, I found that my metrics were being flooded with a
> cookie named, "receive-cookie-deprication". After doing some research and
> testing I learned that this cookie is used by sites for testing the
> potential impact of third party cookie depreciation but doesn't have any
> impact on website functionality. To get a better sense of potential
> breakage, I landed updated metrics that filtered out that cookie. I then
> conducted a manual audit on 10 (of the 104) sites that indicated a possible
> impact with a build of chromium that had the finch flag turned on.
>
> I've summarized my findings in this slide deck
> <https://docs.google.com/presentation/d/1S2N2vyGDaKAwP-5W5pVYqRNQ1RQndjlq4yVTny6hEIY/edit?usp=sharing>
> but I was unable to find a breakage that caused a site to not perform as
> expected from the user's perspective. To be clear, this doesn't mean that
> there won't be breakage that occurs if/when this feature goes live, only
> that I was unable to find an example where the website was unable to
> perform as expected.
>
> Additionally, with the filtering out of the "receive-cookie-deprication"
> cookie from the metrics, the occurrences of an A1->B-A2 cookie which this
> change would impact drops from 0.032% of overall page loads to 0.0012% of
> overall page loads.
>

That's extremely reassuring!


>
> On Tue, Mar 19, 2024 at 12:05 PM Aaron Selya  wrote:
>
>> Yoav, your understanding is correct.
>>
>> I'm still in the process of finalizing the implementation. Once that is
>> done, I'll audit some sites that metrics have indicated will
>> experience breakage and report back my findings.
>>
>> On Tue, Mar 19, 2024 at 8:52 AM Mike Taylor 
>> wrote:
>>
>>> It would also be helpful to discuss what breakage looks like in this
>>> case. Would it be a one-time loss of state (i.e., have to log in again), or
>>> something different?
>>> On 3/19/24 5:08 AM, Yoav Weiss (@Shopify) wrote:
>>>
>>> OK, so just to summarize my understanding:
>>>
>>>- We expect this to have some impact on 0.032% of page views
>>>- We have a Finch flag that can be used as a kill switch in case we
>>>see lots of breakage in the wild
>>>- Developers can get around this deprecation by changing their
>>>cookies to be "same-site: none" *and* requesting SAA from users
>>>
>>> Is the above correct?
>>>
>>> If so, 0.032% sounds like a lot. Would it be possible for y'all to same
>>> pages that trigger that use counter and see how many of them break and what
>>> does breakage look like?
>>>
>>> On Wed, Mar 13, 2024 at 8:23 PM Aaron Selya  wrote:
>>>
>>>> The flag is a base::features flag named
>>>> kAncestorChainBitEnabledInPartitionedCookies.
>>>>
>>>> Updated the review gates on chromestatus.com
>>>>
>>>> On Wed, Mar 13, 2024 at 11:25 AM Yoav Weiss (@Shopify) <
>>>> yoavwe...@chromium.org> wrote:
>>>>
>>>>> Also, can you flip on the relevant review gates in chromestatus.com?
>>>>>
>>>>> On Wed, Mar 13, 2024 at 11:24 AM Yoav Weiss (@Shopify) <
>>>>> yoavwe...@chromium.org> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Mar 12, 2024 at 4:46 PM 'Aaron Selya' via blink-dev <
>>>>>> blink-dev@chromium.org> wrote:
>>>>>>
>>>>>>> The first mitigation listed here is to migrate existing
>>>>>>>> partitioned cookies to include the new bit, and the second mitigation 
>>>>>>>> is to
>>>>>>>> have a flag that can disable this feature. Would disabling the feature 
>>>>>>>> also
>>>>>>>> include migrating the existing cookies back to exclude the new bit?
>>>>>>>>
>>>>>>>
>>>>>>> Disabling the flag would not migrate the existing cookies back to
>>>>>>> exclu

Re: [blink-dev] Intent to Extend Experiment: WebRTC encoded transform - Modify Metadata functions (setMetadata method)

2024-05-03 Thread Yoav Weiss (@Shopify)

Do I understand correctly that you want to extend the OT for 3 more
milestones, up to 129 (inclusive)?



On Thu, May 2, 2024 at 2:45 PM Guido Urdaneta  wrote:

> Contact emails...@chromium.org, gui...@chromium.org, agpa...@chromium.org
>
> Explainer
> https://github.com/guidou/webrtc-extensions/blob/main/constructor-explainer.md
>
> Specification
> https://w3c.github.io/webrtc-encoded-transform/#dom-rtcencodedvideoframe-constructor
>
> Summary
>
> Allow WebRTC Encoded Transform API to manipulate audio and video frame
> metadata. Some WebRTC Encoded Transform use cases involve manipulation of
> not only the payload of encoded video / audio frames but also its metadata.
> For example, if a peer connection negotiates a custom codec and an encoded
> transform is used to implement part or all of the the custom codec and
> needs to set the output codec type as part of the metadata of the output
> frame. See https://www.w3.org/2024/04/23-webrtc-minutes.html#t01
>
>
>
> Blink componentBlink>WebRTC
> 
>
> TAG reviewThe original full spec was reviewed by TAG here:
> https://github.com/w3ctag/design-reviews/issues/531
> No TAG review requested yet for the setMetadata method (during the Working
> Group discussion it was decided to use a constructor, but interest in the
> method version was recently revived).
>
>
> Other use cases:
>
> https://w3c.github.io/webrtc-nv-use-cases/#live-encoded-media
>
> https://w3c.github.io/webrtc-nv-use-cases/#stored-encoded-media
>
> https://w3c.github.io/webrtc-nv-use-cases/#auction
>
> TAG review statusPending
>
> Chromium Trial NameRTCEncodedFrameSetMetadata
>
> Origin Trial documentation link
> https://github.com/palak8669/webrtc-encoded-transform/blob/create-encoded-explainer/create-encoded-explainer.md
>
> WebFeature UseCounter nameRTCEncodedFrameSetMetadata
>
> Risks
>
>
> Interoperability and Compatibility
>
> Interoperability risk: There is always the risk that other browsers will
> not implement this feature. This risk is mitigated by alignment across
> browser vendors in the W3C WebRTC Working Group around the spec.
> Compatibility risk: This is a new feature intended to support new use
> cases. It introduces no breaking changes, so we do not expect any
> compatibility issues.
>
> *Gecko*: No signal
> However, they have shown interest in reviving the discussion for the
> setMetadata() method after achieving consensus on the Custom Codec
> negotiation API for WebRTC Encoded Transform.
>
> *WebKit*: No signal
>
> *Web developers*: Positive
>
> *Other signals*:
>
> Ergonomics
>
> This feature is an extension to WebRTC Encoded Transform, which itself is
> an extension to WebRTC/RTCPeerConnection.
>
>
> Activation
>
> No significant risks identified.
>
>
> Security
>
> No new security risks identified.
>
>
> 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?
>
> No
>
>
> Goals for experimentation
>
> Determine if the proposed API properly supports the intended use case.
>
>
> Reason this experiment is being extended
>
> There are two reasons to request this extension: 1. This proposal
> initially started as a setMetadata() method on encoded frames, but the
> result of discussions in the W3C WebRTC Working Group was that introducing
> a constructor (instead of a method) was a better fit for the use cases for
> which there was consensus in the WG. After a few iterations over the
> constructor API shape, the WG achieved consensus recently and we have sent
> an Intent to Ship for that. However, the final version of the constructor
> only became available in M126 (the last milestone of the Origin Trial) and
> we would like to give developers a little more time to migrate to the
> shipped version of the API. 2. After achieving consensus on the constructor
> with custom metadata, a new use case has been discussed in the WG that has
> revived interest in the original setMetadata() proposal. The WG has
> achieved consensus on a new API for custom codec negotiation for which
> setMetadata() looks like a better fit than the constructor since it doesn't
> require copying the payload of the encoded frame. So the WG might achieve
> consensus on adding setMetadata() after all. See the resolution of
> https://www.w3.org/2024/04/23-webrtc-minutes.html#t01 Since setMetadata()
> might be added to the spec in addition to the constructor, we would like to
> extend the trial to allow developers to continue experimenting with it.
>
>
> Ongoing technical constraints
>
> None
>
>
> Debuggability
>
> N/A
>
>
> 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
>
>
>

Re: [blink-dev] Intent to Prototype and Ship: Align navigator.cookieEnabled with spec

2024-04-30 Thread Yoav Weiss (@Shopify)

LGTM2

On Tue, Apr 30, 2024 at 6:10 PM Rick Byers  wrote:

> Ah good point, thanks. Thanks for your attention to web compat detail
> here. Really any bug fix has the potential to be a significant breaking
> change so the line is very context-dependent.
>
> Rick
>
> On Tue, Apr 30, 2024 at 11:36 AM Ari Chivukula 
> wrote:
>
>> We discussed having this be a PSA+fix, but since developers testing 3PCD
>> have been living in this world for a while and Firefox also has the
>> behavior, it seemed better to go the long route.
>>
>> ~ Ari Chivukula (Their/There/They're)
>>
>>
>> On Tue, Apr 30, 2024 at 11:34 AM Rick Byers  wrote:
>>
>>> Seems maybe like we introduced a bug in regressing from expected
>>> behavior and this could arguably be handled as a bug-fix?
>>>
>>> Regardless LGTM1
>>>
>>> On Tue, Apr 30, 2024 at 11:32 AM Mike Taylor 
>>> wrote:
>>>
 On 4/30/24 7:15 AM, Ari Chivukula wrote:

 Contact emails

 aric...@chromium.org, johann...@google.com

 Specification

 https://html.spec.whatwg.org/multipage/system-state.html#cookies

 Summary

 navigator.cookieEnabled

 currently indicates if “the user agent attempts to handle cookies” in a
 given context. A change in Chrome, shipping as part of third-party
 cookie deprecation (3PCD)
 , would cause it
 to indicate whether unpartitioned cookie access is possible (causing it to
 return false in most cross-site iframes). We should restore the prior
 behavior of navigator.cookieEnabled

 which indicated only if cookies were enabled/disabled for the site and rely
 on the cross-vendor function document.hasStorageAccess

 to indicate if unpartitioned cookie access is possible.

 I find it surprising that we changed the behavior of cookieEnabled in
 https://groups.google.com/a/chromium.org/g/blink-dev/c/RG0oLYQ0f2I/m/xMSdsEAzBwAJ
 - that wasn't clear to me when I LGTM'd. That said, HTML is shelling out to
 RFC6265 - and the eventual promotion of 6265bis and subsequent Cookie
 Layering work should make it all make sense in a 2024+ context one day soon
 (one can dream, anyways).

 (Note I'm recused on voting from this one).

 Blink component

 Internals>Network>Cookies

 Motivation

 Divergence in the meaning

 of navigator.cookieEnabled will cause confusion as Chrome rolls out 3PCD.
 We have a window, before 3PCD ships, to restore prior behavior now that
 there is some amount of consensus
  between browser vendors
 on what navigator.cookieEnabled should indicate in third-party contexts.

 TAG review

 This is a minor change to align browsers on standardized behavior so we
 did not request TAG review.

 Compatibility

 Some websites adapting to Chrome’s 3PCD rollout
  may have used
 navigator.cookieEnabled as a proxy for document.hasStorageAccess, but we
 will start recommending the use of hasStorageAccess moving forward. To be
 clear, the behavior change is only web-observable in Chrome instances where
 third-party cookie blocking is turned on. Metrics on third-party
 context use
  of
 navigator.cookieEnabled are being gathered in M125, but without 3PCD fully
 rolled out the impact should be minimal, especially where websites wish to
 support Safari (which already adopts the behavior we propose aligning 
 with).

 Interoperability

 Safari is already aligned but Firefox mirrors current Chrome behavior.

 Gecko: Preliminary positive feedback.

 We asked if they’d like us to file a standards position for this relatively
 minor change, and they said it’s not needed.

 WebKit: Shipping

 Web developers: No Signal

 Debuggability

 Access to cookies and unpartitioned cookies is visible in DevTools.

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

 Testing the effects of user-provided cookie settings on this function
 cannot be done in WPTs.

 Tracking bug

 https://crbug.com/335553590

 Link to entry on the Chrome

Re: [blink-dev] Intent to Ship: Support Cross-Origin Shared Storage Worklets

2024-04-29 Thread Yoav Weiss (@Shopify)

LGTM3

On Thu, Apr 25, 2024 at 5:57 PM Mike Taylor  wrote:

> LGTM2.
> On 4/24/24 5:45 PM, Yao Xiao wrote:
>
> Hi Yao,
>
> I see that https://github.com/WICG/shared-storage/pull/152 is still open,
>> can that be landed before we ship this?
>
> The PR landed just now.
>
> Also, can you point to the tests for this change?
>
> Yes.
> cross-origin-worklet-select-url-and-verify-data-origin.tentative.https.sub.html
> 
>  is
> a representative one. You can find other relevant tests in the same
> repository, by searching for "cross-origin".
>
> Best,
> Yao
>
>
> On Wed, Apr 24, 2024 at 4:02 PM Chris Harrelson 
> wrote:
>
>> Thanks for the further explanation! It was very helpful.
>>
>> LGTM1, but please make sure to land that open PR before shipping.
>>
>> On Wed, Apr 24, 2024 at 10:48 AM Josh Karlin 
>> wrote:
>>
>>> Hey folks, I wanted to provide a bit more context on this change to help
>>> clarify the intention and any associated risks.
>>>
>>> Today, when a third-party script runs on a page and wants to write data
>>> to shared storage, or use their shared storage data (e.g., create an
>>> aggregate report) under its own name, the script first needs to create a
>>> x-origin iframe and pass the data to that frame. This is because the origin
>>> used by shared storage is that of the context. This is cumbersome to the
>>> developer. They have to create an iframe document to listen for data (e.g.,
>>> via name attribute, url query param, or postMessage) and act on that data
>>> (by writing to shared storage or starting a worklet). It's also terrible
>>> for resource usage and performance (the browser needs to navigate, load a
>>> document, and execute js).
>>>
>>> The primary focus of this change is to allow a third-party on a page to
>>> invoke its own worklet (with access to its own storage) directly, bypassing
>>> the need to create a x-origin iframe. This is accomplished by allowing
>>> x-origin urls to be specified in a new API, `window.sharedStorage.
>>> createWorklet
>>> `.
>>> We are not changing the behavior of addModule, and we are not changing the
>>> capabilities of worklets. We're just making it easier to create x-origin
>>> worklets. In `createWorklet
>>> `,
>>> if a x-origin URL is specified, the response will require both
>>> `Shared-Storage-Cross-Origin-Worklet-Allowed: ?1` and CORS
>>> (Access-Control-Allow-Origin). That is, embedding a x-origin worklet is
>>> strictly opt-in. This is because a shared storage worklet has side-effects
>>> (e.g., sending reports, or selecting a url) which also consumes budget, and
>>> the worklet's origin may want to control who gets to use it. They should
>>> also (always a challenge on the web) take care to ensure that the data that
>>> they're receiving from the embedder is valid.
>>>
>>> Another useful aspect of introducing `createWorklet`, is that it allows
>>> a document to host multiple shared storage worklets and call methods on
>>> them individually. This makes it easier for pages that might have multiple
>>> teams creating them, that don't necessarily want to coordinate their shared
>>> storage worklet scripts.
>>>
>>> Best,
>>>
>>> Josh
>>>
>>>
>>> On Wed, Apr 24, 2024 at 1:19 PM Josh Karlin 
>>> wrote:
>>>


 On Wed, Apr 24, 2024 at 11:52 AM Alex Russell 
 wrote:

> Hey Josh,
>
> I agree that it might not be helpful to ping Gecko and WebKit on this,
> but it would still be helpful to update the TAG on how this design is
> evolving.
>

 Ack. I've updated the TAG thread
 
 .


>
> From that perspective, I would expect the TAG to request that we
> improve consistency by making cross-origin workers (not just worklets)
> possible. Where are we at on that?
>
> Regards,
>
> Alex
>
> On Friday, April 19, 2024 at 12:58:17 PM UTC-7 Josh Karlin wrote:
>
>> On Fri, Apr 19, 2024 at 1:59 PM Vladimir Levin 
>> wrote:
>>
>>>
>>>
>>> On Fri, Apr 19, 2024 at 12:52 PM Yao Xiao 
>>> wrote:
>>>
 *Contact emails*
 cam...@chromium.org
 jkar...@chromium.org
 yao...@chromium.org
 rohitgu...@google.com
 ashame...@google.com

 *Explainer*
 https://github.com/WICG/shared-storage

 *Specification*
 https://wicg.github.io/shared-storage/

 *Additional anticipated specification changes*
 https://github.com/WICG/shared-storage/pull/152

 *Blink component*

Re: [blink-dev] Intent to Ship: FedCM: Credentialed requests will no longer send SameSite=Strict cookies

2024-04-24 Thread Yoav Weiss (@Shopify)

LGTM1

On Wed, Apr 24, 2024 at 5:46 PM Christian Biesinger 
wrote:

> Hi Yoav,
>
> with regards to the spec: As Johann suggests, this can't really be
> specified today and I am hoping we won't block on that as he suggests. (the
> cookie spec linked from the fetch spec does not mention SameSite at all...
> https://httpwg.org/specs/rfc6265.html#cookie)
>

Yeah, I'm convinced that this entire area is not currently specified, and
that y'all are making strides towards that, and we shouldn't block this
particular change on them.
I just wanted to verify that what y'all are planning to ship aligns with my
understanding of what we'd want to eventually specify here.


>
> with regards to the implementation: We do not send SameSite=Lax cookies
>

That makes sense. Thanks!


>
> Christian
>
> On Wed, Apr 24, 2024 at 11:04 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>> fetch-accounts <https://fedidcg.github.io/FedCM/#fetch-accounts> says
>> that the origin for accounts requests is an opaque origin. What does that
>> mean for `Same-Site: Lax` cookies? Will they be sent or not?
>>
>> On Tuesday, April 23, 2024 at 9:08:33 PM UTC+2 Johann Hofmann wrote:
>>
>>> I wanted to chime in on fetch + cookies integration: Yes, it's very
>>> underspecified
>>> <https://fetch.spec.whatwg.org/#http-network-or-cache-fetch:~:text=If%20includeCredentials%20is%20true%2C%20then%3A>
>>> and leaves the computation of the actual SameSite status of cookies
>>> included in the request to the cookies RFC
>>> <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis/#name-same-site-and-cross-site-re>.
>>> This needs work on Fetch, 6265bis, HTML and Cookie Store specs (and now
>>> also needs to consider 3PC blocking!) which we're actively doing right now
>>> and hope to have some progress to share soon. I would not want to block
>>> this feature on it (and we haven't blocked other features in the past). I
>>> would expect the FedCM spec to adjust to the cookie layering work once that
>>> lands, and can work with the team to make sure that happens.
>>>
>>> Hope this helps,
>>>
>>> Johann
>>>
>>> On Tue, Apr 23, 2024 at 8:05 PM Christian Biesinger <
>>> cbiesin...@chromium.org> wrote:
>>>
>>>> Just wanted to ping this thread -- any lgtms? Or will it be discussed
>>>> at tomorrow's meeting?
>>>>
>>>> Christian
>>>>
>>>> On Thu, Apr 18, 2024 at 11:31 AM Christian Biesinger <
>>>> cbiesin...@chromium.org> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Apr 17, 2024 at 10:13 PM Domenic Denicola <
>>>>> dome...@chromium.org> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Apr 18, 2024 at 6:19 AM Christian Biesinger <
>>>>>> cbiesin...@chromium.org> wrote:
>>>>>>
>>>>>>> Contact emails
>>>>>>>
>>>>>>> cbiesin...@chromium.org
>>>>>>>
>>>>>>>
>>>>>>> Explainer
>>>>>>>
>>>>>>> See summary
>>>>>>>
>>>>>>>
>>>>>>> Specification
>>>>>>>
>>>>>>> https://fedidcg.github.io/FedCM/#fetch-identity-assertion
>>>>>>>
>>>>>>
>>>>>> I wasn't able to find the part of the spec that talks about which
>>>>>> cookies are sent. Probably I just don't understand Fetch + cookies
>>>>>> integration well enough. Could you help point it out? Or maybe link to 
>>>>>> the
>>>>>> PR that makes the change?
>>>>>>
>>>>>
>>>>> It turns out our implementation did not match the spec in this
>>>>> respect, so there was no PR (just an impl change).
>>>>>
>>>>> It is probably me who does not understand the fetch + cookies
>>>>> integration, but my thinking is that because we give an origin to the 
>>>>> fetch
>>>>> algorithm (the RP's origin), which is not same-site with the identity
>>>>> provider (normally), fetch should not send SameSite=Strict cookies.
>>>>>
>>>>> Also cc'ing Dominic (Farolino) who has helped us in this area.
>>>>>
>>>>> [You may ask, what happens if the RP is indeed same-site with the IDP?
>

Re: [blink-dev] Intent to Ship: FedCM: Credentialed requests will no longer send SameSite=Strict cookies

2024-04-24 Thread Yoav Weiss (@Shopify)

fetch-accounts  says that 
the origin for accounts requests is an opaque origin. What does that mean 
for `Same-Site: Lax` cookies? Will they be sent or not?

On Tuesday, April 23, 2024 at 9:08:33 PM UTC+2 Johann Hofmann wrote:

> I wanted to chime in on fetch + cookies integration: Yes, it's very 
> underspecified 
> 
>  
> and leaves the computation of the actual SameSite status of cookies 
> included in the request to the cookies RFC 
> .
>  
> This needs work on Fetch, 6265bis, HTML and Cookie Store specs (and now 
> also needs to consider 3PC blocking!) which we're actively doing right now 
> and hope to have some progress to share soon. I would not want to block 
> this feature on it (and we haven't blocked other features in the past). I 
> would expect the FedCM spec to adjust to the cookie layering work once that 
> lands, and can work with the team to make sure that happens.
>
> Hope this helps,
>
> Johann
>
> On Tue, Apr 23, 2024 at 8:05 PM Christian Biesinger <
> cbiesin...@chromium.org> wrote:
>
>> Just wanted to ping this thread -- any lgtms? Or will it be discussed at 
>> tomorrow's meeting?
>>
>> Christian
>>
>> On Thu, Apr 18, 2024 at 11:31 AM Christian Biesinger <
>> cbiesin...@chromium.org> wrote:
>>
>>>
>>>
>>> On Wed, Apr 17, 2024 at 10:13 PM Domenic Denicola  
>>> wrote:
>>>


 On Thu, Apr 18, 2024 at 6:19 AM Christian Biesinger <
 cbiesin...@chromium.org> wrote:

> Contact emails
>
> cbiesin...@chromium.org
>
>
> Explainer
>
> See summary
>
>
> Specification
>
> https://fedidcg.github.io/FedCM/#fetch-identity-assertion
>

 I wasn't able to find the part of the spec that talks about which 
 cookies are sent. Probably I just don't understand Fetch + cookies 
 integration well enough. Could you help point it out? Or maybe link to the 
 PR that makes the change?

>>>
>>> It turns out our implementation did not match the spec in this respect, 
>>> so there was no PR (just an impl change).
>>>
>>> It is probably me who does not understand the fetch + cookies 
>>> integration, but my thinking is that because we give an origin to the fetch 
>>> algorithm (the RP's origin), which is not same-site with the identity 
>>> provider (normally), fetch should not send SameSite=Strict cookies.
>>>
>>> Also cc'ing Dominic (Farolino) who has helped us in this area.
>>>
>>> [You may ask, what happens if the RP is indeed same-site with the IDP? I 
>>> think we would send SameSite=Strict cookies in that situation, but that 
>>> case is rare]
>>>
>>> Christian
>>>  
>>>
  

>
> Summary
>
> We recently changed 
>  FedCM to send ID 
> assertion requests with CORS. As a side-effect, that change also meant 
> that 
> we no longer send SameSite=Strict cookies to the ID assertion endpoint 
> (we 
> still send SameSite=None). Since it does not make sense to send a 
> different 
> set of cookies to the accounts endpoint and the ID assertion endpoint, 
> this 
> change makes them consistent – they both should get the same credentials 
> as 
> they identify the user in the same way.
>
> Not sending SameSite=Strict cookies is also consistent with 
> requestStorageAccess 
> behavior 
> 
>  
> and cross-site requests in general.
> Blink component
>
> Blink>Identity>FedCM 
> 
> Search tags
>
> fedcm , samesite 
> , cookies 
> 
>
>
> TAG review
>
> None
>
>
> TAG review status
>
> Not applicable
>
>
> Risks
>
>
>
> Interoperability and Compatibility
>
> There should be no interop risk because no other browser has shipped 
> FedCM yet and this change was requested by Webkit, with Gecko supporting 
> the request.
>
> With regards to compatibility, we have tested the known IDPs that use 
> FedCM and this is not an issue. In addition, for any IDP that supports 
> "Sign in with X" on the web without FedCM, cookies must already be 
> SameSite=None because these requests are cross-origin by definition.
>
> Gecko: Positive. Change supported by Gecko 
> (https://github.com/fedidcg/FedCM/issues/320#issassessment 
> the team has done

Re: [blink-dev] Re: Intent to Ship: WebGLObject Web IDL superinterface

2024-04-23 Thread Yoav Weiss (@Shopify)

LGTM3

On Tue, Apr 23, 2024 at 6:45 PM Mike Taylor  wrote:

> LGTM2
> On 4/23/24 1:18 AM, Domenic Denicola wrote:
>
> LGTM1
>
> On Tue, Apr 23, 2024 at 7:36 AM Ken Russell  wrote:
>
>> Yes. N/As and explanations have been requested for all of these now.
>>
>>
>> On Sun, Apr 21, 2024 at 7:37 PM Domenic Denicola 
>> wrote:
>>
>>> Can you request Privacy, Security, Enterprise, Debuggability, and
>>> Testing reviews by following the procedure on ChromeStatus? Most of them
>>> should be pretty simple, or even N/A, for this feature. But we're not
>>> supposed to give API owner approvals until they're underway.
>>>
>>> On Sat, Apr 20, 2024 at 12:42 PM Ken Russell  wrote:
>>>
 Correction: this API change is already tested in the Web Platform
 Tests, by wpt/webgl/idlharness.any and wpt/webgl/idlharness.any.worker.
 I've updated the Chromestatus entry to indicate this; these tests are
 progressed by this change.

 https://chromium-review.googlesource.com/c/chromium/src/+/5466430 ,
 implementing this, passes the trybots. Would appreciate LGTMs from OWNERs
 for this small change to minimize the number of rebases that need to be
 done before it lands.

 Thanks in advance.

 -Ken



 On Thu, Apr 18, 2024 at 5:45 PM Ken Russell  wrote:

> Contact emails k...@chromium.org
>
> Explainer None
>
> Specification https://registry.khronos.org/webgl/specs/latest/1.0
>
> Summary
>
> The WebGL specification has defined a WebGLObject superinterface for
> many years, but Chromium's implementation never exposed it. This did not
> significantly affect applications in practice, but prevented enabling 
> WebGL
> IDL tests in the Interop suite. The WebGL working group also aims to
> finally utilize this superinterface to improve application-level 
> debugging.
> This feature exposes the WebGLObject type in the same contexts where the
> WebGL API is exposed - on the main thread and workers.
>
>
> Blink component Blink>WebGL
> 
>
> TAG review None
>
> TAG review status Not applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> No risk. Chrome, Firefox and Safari all intend to expose this
> interface.
>
>
> *Gecko*: Positive (https://github.com/KhronosGroup/WebGL/pull/3637)
> Firefox approves of and proposes using this superinterface to add
> application-level debugging functionality.
>
> *WebKit*: Positive (https://github.com/KhronosGroup/WebGL/pull/3637)
> Safari approves of using this superinterface to add application-level
> debugging functionality.
>
> *Web developers*: Positive (
> https://github.com/KhronosGroup/WebGL/issues/3514) Web developers
> request debugging functionality built on this superinterface, per the link
> above.
>
> *Other signals*:
>
> Ergonomics
>
> N/A for this change; follow-on ones will improve developer ergonomics
> and integration with platform-specific graphics debugging tools.
>
>
> Activation
>
> N/A for this change.
>
>
> Security
>
> None
>
>
> 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 for this change.
>
>
> 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
>
> Not tested by web-platform-tests yet. This change enables automated
> WebGL IDL tests, which were previously failing, to be added to the Interop
> suite. It will also be tested in the WebGL conformance suite, which is
> separate from web-platform-tests.
>
>
> Flag name on chrome://flags None
>
> Finch feature name None
>
> Non-finch justification
>
> Trivial addition of a superinterface to multiple WebGL object types.
>
>
> Requires code in //chrome? False
>
> Measurement Does not apply; this is currently an empty web-exposed
> interface which can be used in "instanceof" checks.
>
> Availability expectation Feature is available on Web Platform
> mainline within 12 months of launch in Chrome.
>
> Adoption expectation Feature is considered a best practice for some
> use case within 12 months of reaching Web Platform baseline.
>
> Adoption plan Chrome, Firefox and Safari plan to ship debugging
> functionality for application developers on top of this

Re: [blink-dev] Intent to Ship: URL.parse()

2024-04-23 Thread Yoav Weiss (@Shopify)

LGTM1

Thanks for catching us up here! :)

On Tue, Apr 23, 2024 at 10:20 AM Domenic Denicola 
wrote:

> Thanks. One more thing: our process requires all features have a Finch
> feature name (i.e., a base::Feature) so that we can turn off the feature
> remotely. Can you ensure your implementation has one, and then update
> ChromeStatus with its name?
>

Looks like a flag

is already in place, but indeed please update the chromestatus entry with
that flag's name.


>
> On Tue, Apr 23, 2024 at 2:29 PM Jxck  wrote:
>
>> Thanks, I've done them.
>>
>> On Monday, April 22, 2024 at 3:53:27 PM UTC+9 Domenic Denicola wrote:
>>
>>> Can you request privacy, security, enterprise, debuggability, and
>>> testing reviews on Chrome Status?
>>>
>>> On Thu, Apr 18, 2024 at 11:36 PM Jack J  wrote:
>>>
 Contact emailsj...@chromium.org

 ExplainerNone

 Specificationhttps://url.spec.whatwg.org/#dom-url-parse

 Design docs
 https://github.com/whatwg/url/pull/825

 Summary

 Parsing url string and returning URL object. If it's invalid url
 format, returning null instead of throwing Error.


 Blink componentBlink>Network
 

 Search tagsURL 

 TAG reviewNone

 TAG review statusNot applicable

 Risks


 Interoperability and Compatibility

 None


 *Gecko*: Shipped/Shipping (
 https://bugzilla.mozilla.org/show_bug.cgi?id=1887611)

 *WebKit*: Shipped/Shipping (https://github.com/WebKit/WebKit/pull/26403
 )

 *Web developers*: Positive (
 https://github.com/denoland/deno/issues/23069)
 https://github.com/nodejs/node/issues/52208

 *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


 https://wpt.fyi/results/url?label=master=experimental=url-statics-parse


 Flag name on chrome://flags
 chrome://flags/#enable-experimental-web-platform-features

 Finch feature nameNone

 Non-finch justificationNone

 Requires code in //chrome?False

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

 Estimated milestones
 Shipping on desktop 126
 Shipping on Android 126
 Shipping on WebView 126
 Shipping on WebView 126

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

 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/CAFBcQZ--hCtq-W37%2BkXCf89uKdEQ6Ot8RAdDO5LFXd7qReY_xw%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/CAM0wra_800vnfaubD_W4X77V21MYLgwxhYQ-oG0pH_8BuFyk4Q%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop

Re: [blink-dev] Re: Intent to Ship: Remove Authorization header upon cross-origin redirect

On Mon, Apr 15, 2024 at 2:18 PM Tom Komarnicki 
wrote:

> Hey,
>
> Sorry for necro'ing this thread, I'm aware that this has been on the
> "done" pile for a while - and maybe it should've been brought up earlier,
> but how do you "disable" this feature ? It's making the BE dev exhaustingly
> painful, not being able to intercept requests and re-forward them to the
> local BE.
> Is there a flag, or whatnot, to re-enable the old flow ?
>

Can you expand on the issue you're hitting? By "BE" do you mean backend? Or
something else?


> Thanks
>
> On Tuesday 5 September 2023 at 18:29:10 UTC+3 Chris Harrelson wrote:
>
>> LGTM3
>>
>> On Tue, Sep 5, 2023 at 8:27 AM Mike Taylor  wrote:
>>
>>> LGTM2
>>> On 9/3/23 8:12 PM, Yoav Weiss wrote:
>>>
>>> LGTM1
>>>
>>>
>>>
>>> On Mon, Sep 4, 2023 at 2:24 AM Kenichi Ishibashi 
>>> wrote:
>>>
>>>> Hi, sorry for the long delay.
>>>>
>>>> The feature page
>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4470>
>>>> now shows sites that use Authorization header for cross-origin redirects. I
>>>> randomly picked some of them and examined to see if they could work when
>>>> Chrome removes Authorization header up on cross-origin redirects. As far as
>>>> I can tell, none of them are broken. We would like to ship this behind a
>>>> feature flag.
>>>>
>>>
>>> Thanks for the analysis!
>>> As you pointed out elsewhere, since our previous discussions on this
>>> thread, this was shipped
>>> <https://wpt.fyi/results/fetch/api/credentials/authentication-redirection.any.html?label=stable=master>
>>> by Firefox and Safari.
>>> I think that changes the risk calculus (from compat to interop) and
>>> makes shipping this (with a base feature just in case) the right choice.
>>>
>>>
>>>> Thanks,
>>>>
>>>> On Fri, Sep 1, 2023 at 1:39 AM Ioan-Cristian Linte <
>>>> linte.ioa...@gmail.com> wrote:
>>>>
>>>>> Any updates on this?
>>>>> Other browser have already made the change for some time so it's
>>>>> surprising that Chrome is so worried about breaking change.
>>>>>
>>>>> The Authorization propagating in cross origin redirects is causing a
>>>>> performance issue for us. Our server redirects to AWS S3 with pre-signed
>>>>> url and this will return 400 error as AWS S3 disallows specifying multiple
>>>>> authorizations (e.g. signature in url and Authorization header) in a
>>>>> request. Also the 400 error response includes a close connection header. 
>>>>> To
>>>>> make this work, the web client checks for the 400 error and uses the
>>>>> response.url to make a new fetch request without the Authorization header.
>>>>> Because the previous connection was closed this incurs the cost of
>>>>> initiating a new connection.
>>>>>
>>>>> On Wednesday, June 28, 2023 at 6:34:42 PM UTC+3 Yoav Weiss wrote:
>>>>>
>>>>>> Friendly ping! :) Any news on UKM data here?
>>>>>>
>>>>>> On Wednesday, April 5, 2023 at 10:53:41 AM UTC+2 Yoav Weiss wrote:
>>>>>>
>>>>>>> Sounds great, thanks!! :)
>>>>>>>
>>>>>>> On Wed, Apr 5, 2023 at 10:44 AM Kenichi Ishibashi <
>>>>>>> ba...@chromium.org> wrote:
>>>>>>>
>>>>>>>> Hi Yoav,
>>>>>>>>
>>>>>>>> Sorry I haven't sent an update in this thread. (1) sounds
>>>>>>>> reasonable. I added the usercounters to UKM a few weeks ago and I'm 
>>>>>>>> waiting
>>>>>>>> for data. I will report back after manual inspections are done.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Apr 5, 2023 at 5:14 PM Yoav Weiss 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Friendly ping on the above :) Does (1) sound reasonable from your
>>>>>>>>> perspective?
>>>>>>>>>
>>>>>>>>> On Wed, Mar 15, 2023 at 7:16 PM Yoav Weiss 
>>>>>>>>> wrote:
>>>>>>

Re: [blink-dev] Intent to Extend Reverse Origin Trial: Trial for SharedArrayBuffers in non-isolated pages on Desktop platforms

LGTM to extend the deprecation trial till M131 (inclusive)

On Thu, Apr 11, 2024 at 11:21 AM Camille Lamy  wrote:

> Contact emails
>
> v...@chromium.org cl...@chromium.org
>
> Explainer
>
>
> https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k
>
> Specification
>
> https://tc39.github.io/ecma262/#sec-sharedarraybuffer-objects
>
> Design docs Including the new security requirements
>
>
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer
>
> Discussion how and what to gate
>
> https://github.com/whatwg/html/issues/4732
>
> Summary
>
> ‘SharedArrayBuffers’ (SABs) on desktop platforms are restricted to
> cross-origin isolated environments, matching the behavior we've recently
> shipped on Android and Firefox. We've performed that change in Chrome 92. A
> reverse OT was started to give developers the option to use SABs in case
> they are not able to adopt cross origin isolation yet.
>
> We’ve worked with multiple internal and external users of the OT to
> understand their use cases and why they can’t adopt yet. With
> COEP:credentialless and iframes credentialless now available, the SAB non
> COI usage went further down.
>
> Unfortunately, the cascading requirements of COEP are still a blocker for
> COI adoption. Some of the users of the OT rely heavily on credentialled
> cross-origin subresources, so credentialless modes are not an option for
> them. And their apps are complex enough that they are still blocked on
> child iframes supporting COEP.
>
> To address this, we’ve explored ways of enabling COI that would take
> advantage of process isolation in order to waive requirements on child
> frames to enforce COEP.
>
> We’ve sent out the I2P for Document-Isolation-Policy and are aiming to OT
> it starting with M128. Giving developers 3 milestones to verify and provide
> feedback, we’re aiming for a release in M131.
>
> As we know the cascading is the final blocker for COI adoption and
> therefore SAB usage on Desktop, we’re asking to extend the OT to M131.
>
> Blink component
>
> Blink>JavaScript
> 
>
> Search tags
>
> SharedArrayBuffer
> , SAB
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/471
> TAG review statusClosed
> RisksInteroperability and Compatibility
>
> We expect this change to negatively impact developers using
> `SharedArrayBuffer` today. Chrome was the only platform where SABs have
> been available without COOP/COEP. Therefore we need to give developers the
> right capabilities and a clear path forward to ensure they have enough time
> to adopt. We aim to mitigate these risks by adopting a longer-than-usual
> depreciation period with console warnings/issues and a reverse origin
> trial.
>
> Good news is usage is down to ~0.0777%
> 
> page loads and that other browsers have or are shipping SABs again gated
> behind COOP/COEP. Bad news is that Chromium was the only browser that
> supported SABs without COI, therefore we need to provide a migration path
> to not break existing sites.
>
> Gecko: Shipped/Shipping (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1312446)
>
> WebKit: Added COOP/COEP and SAB support recently gated behind COOP/COEP
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> No - This OT is only for desktop, as this was the only platform where SABs
> have been available without COOP/COEP.
>
> Android re-enabled SABs gated behind COOP/COEP:
> https://chromestatus.com/feature/5171863141482496
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1144104
>
> Launch bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1138860
>
> Blink-dev Thread
>
> Planning isolation requirements (COOP/COEP) for SharedArrayBuffer
> 
>
> I2S
> 
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/4570991992766464
>
> --
> 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/CAMKsNvrmoF0hRkDzA3U0pVW-dXHvWZ1Objr4eABsy%2BJOPgmJUg%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are

Re: [blink-dev] Intent to Ship: Gamepad API Trigger-Rumble Extension

On Thu, Apr 11, 2024 at 1:02 AM 'Gabriel Brito' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
> gabrielbr...@microsoft.com
>
> Explainer
>
> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/GamepadHapticsActuatorTriggerRumble/explainer.md
>
> Specification
> https://w3c.github.io/gamepad/#dom-gamepadhapticeffecttype-trigger-rumble
>
> Design docs
> None
>
> Summary
>
> Extend the GamepadHapticActuator interface to expose the trigger-rumble
> capability in the Web for compatible gamepads. This extension will allow
> Web applications that take advantage of the Gamepad API to also vibrate the
> triggers of gamepad devices that come equipped with this functionality.
>
>
> Blink component
> Blink>GamepadAPI
> 
>
> TAG review
> https://github.com/w3ctag/design-reviews/issues/934
>
> TAG review status
> Issues addressed
>
> Risks
>
>
> Interoperability and Compatibility
>
> The trigger-rumble extension has been added to the Gamepad API spec. Both
> Chromium and WebKit have this feature implemented behind a feature flag.
>
> https://w3c.github.io/gamepad/#dom-gamepadhapticeffecttype-trigger-rumble
>
>
> *Gecko*: No signal (
> https://github.com/mozilla/standards-positions/issues/656)
>
> *WebKit*: In development (
> https://github.com/WebKit/standards-positions/issues/1) The feature has
> been specified and is currently working behind a feature flag in WebKit.
> https://bugs.webkit.org/show_bug.cgi?id=250352
>

I'm confused by the status of this position. IIUC WebKit are opposed to
this, but (partially) implemented this for compat reasons? Can you expand
on the status here?


>
> *Web developers*: Positive. One cloud gaming company is currently using
> this API.
>
> *Other signals*:
>
> WebView application risks
> Not supported on Android.
>
>
> Debuggability
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?
> No
>
> The feature is fully supported on both Windows and macOS. It is also
> supported on ChromeOS and Linux over Bluetooth. However, it is not
> supported on:
> - Linux and ChromeOS over USB: xpad  does
> not support this capability.
> - Android: both xpad and Android's VibratorManager do not support this
> capability.
>
> Is this feature fully tested by web-platform-tests
> 
> ?
> A manual test to verify the trigger rumble behavior is currently in review
> .
> This feature added the GamepadHapticActuator.effects array and the test
> below checks for its presence.
>
>
> https://wpt.fyi/results/gamepad/idlharness.window.html?label=experimental=master
>
> Flag name on chrome://flags
> chrome://flags/#enable-gamepad-trigger-rumble
>
> Finch feature name
> WGIGamepadTriggerRumble
>
> Requires code in //chrome?
> False
>
> Tracking bug
> https://crbug.com/40834175
>
> Launch bug
> https://launch.corp.google.com/launch/4316636
>
> Sample links
> https://nondebug.github.io/gamepad-explorer
>
> Estimated milestones
> Shipping on desktop
> 126
> DevTrial on desktop
> 105
>
>
> Anticipated spec changes
> None
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5162940951953408
>
> Links to previous Intent discussions
> Intent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DM5PR21MB0172E0D85E13D52B90A0A4D8D5B09%40DM5PR21MB0172.namprd21.prod.outlook.com
>
> This intent message was generated by Chrome Platform Status
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CY8PR00MB1645E134520E311663BE6ECCD5062%40CY8PR00MB1645.namprd00.prod.outlook.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/CAOmohS%2B7WD2shvwe6iGFfbs_g%3DymzOr%2BwX%2Bpjuv_SxE3JNou1Q%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype: Importmap integrity

I somehow missed the fact that `require-sri-for` was removed. That doesn't
change the value of this feature from my perspective.

On Mon, Apr 15, 2024 at 9:39 PM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

>
>
> On Mon, Apr 15, 2024 at 8:17 PM Jeffrey Yasskin 
> wrote:
>
>> This looks great; thanks for working on it! One question:
>>
>> My understanding is that there's an alternate design here in which the
>> integrity information is attached to the `import` statements inside
>> modules, which would allow developers to attach integrity information to
>> url-based modules without needing to add import maps. However, IIUC that
>> would cause caching problems since if a leaf dependency changed, all
>> modules on the path to the root would also need to change their embedded
>> integrity information, even if nothing else in those files changed.
>>
>
> That would indeed be the issue with such a design. This is a current
> problem with hash based URL schemes, where any code change in any resource
> delivered to the browser invalidates all the resources that load it, and
> that invalidation then bubbles up the module tree. That can get even worse
> in cases of circular dependency.
>
> Import maps solve this very problem, and attaching the integrity hashes at
> the import site would be a regression.
>
> Am I right that the design you're actually implementing avoids that
>> problem by concentrating integrity information in the import map?
>>
>
> Indeed.
>
>
>>
>> Jeffrey
>>
>> On Mon, Apr 15, 2024 at 7:46 AM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>> Contact emailsyoavwe...@chromium.org
>>>
>>> Explainerhttps://github.com/guybedford/import-maps-extensions#integrity
>>>
>>> Specificationhttps://github.com/whatwg/html/pull/10269
>>>
>>> Summary
>>>
>>> Imported ES modules can't currently have their integrity checked, and
>>> hence cannot run in environments that require Subresource Integrity or with
>>> `require-sri-for` CSP directives. This feature adds an `integrity` section
>>> to import maps, enabling developers to map ES module URLs to their
>>> integrity metadata, and ensure they only load when they match their
>>> expected hashes.
>>>
>>>
>>> Blink componentBlink>Loader
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELoader>
>>>
>>> Motivation
>>>
>>> Since modules initiate requests, there is a need for the ability to
>>> specify the integrity of dependencies, and not just the top level

Re: [blink-dev] Intent to Prototype: Importmap integrity

On Mon, Apr 15, 2024 at 8:17 PM Jeffrey Yasskin 
wrote:

> This looks great; thanks for working on it! One question:
>
> My understanding is that there's an alternate design here in which the
> integrity information is attached to the `import` statements inside
> modules, which would allow developers to attach integrity information to
> url-based modules without needing to add import maps. However, IIUC that
> would cause caching problems since if a leaf dependency changed, all
> modules on the path to the root would also need to change their embedded
> integrity information, even if nothing else in those files changed.
>

That would indeed be the issue with such a design. This is a current
problem with hash based URL schemes, where any code change in any resource
delivered to the browser invalidates all the resources that load it, and
that invalidation then bubbles up the module tree. That can get even worse
in cases of circular dependency.

Import maps solve this very problem, and attaching the integrity hashes at
the import site would be a regression.

Am I right that the design you're actually implementing avoids that problem
> by concentrating integrity information in the import map?
>

Indeed.


>
> Jeffrey
>
> On Mon, Apr 15, 2024 at 7:46 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>> Contact emailsyoavwe...@chromium.org
>>
>> Explainerhttps://github.com/guybedford/import-maps-extensions#integrity
>>
>> Specificationhttps://github.com/whatwg/html/pull/10269
>>
>> Summary
>>
>> Imported ES modules can't currently have their integrity checked, and
>> hence cannot run in environments that require Subresource Integrity or with
>> `require-sri-for` CSP directives. This feature adds an `integrity` section
>> to import maps, enabling developers to map ES module URLs to their
>> integrity metadata, and ensure they only load when they match their
>> expected hashes.
>>
>>
>> Blink componentBlink>Loader
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELoader>
>>
>> Motivation
>>
>> Since modules initiate requests, there is a need for the ability to
>> specify the integrity of dependencies, and not just the top level

[blink-dev] Intent to Prototype: Importmap integrity

Contact emailsyoavwe...@chromium.org

Explainerhttps://github.com/guybedford/import-maps-extensions#integrity

Specificationhttps://github.com/whatwg/html/pull/10269

Summary

Imported ES modules can't currently have their integrity checked, and hence
cannot run in environments that require Subresource Integrity or with
`require-sri-for` CSP directives. This feature adds an `integrity` section
to import maps, enabling developers to map ES module URLs to their
integrity metadata, and ensure they only load when they match their
expected hashes.


Blink componentBlink>Loader


Motivation

Since modules initiate requests, there is a need for the ability to specify
the integrity of dependencies, and not just the top level

Re: [blink-dev] Intent to Experiment: FedCM Button Mode API and Use Other Account API

That's indeed very useful to get a better understanding of the overall
flow, thanks! :)

On Mon, Apr 8, 2024 at 5:06 PM Yi Gu  wrote:

> Hi Yoav,
>
> Thanks for the suggestion! We have a flowchart
> <https://raw.githubusercontent.com/yi-gu/fedcm-images/main/button_flow/ButtonFlow.jpeg>
> in that thread to try to explain what a browser would do in case a user is
> not logged in to the IdP but maybe it's not very clear. The answer to your
> questions is yes. IdP controls which login page the new window would load
> (by reusing the required "login_url
> <https://developers.google.com/privacy-sandbox/3pcd/fedcm-developer-guide#login-url>"
> field from LoginStatus API). However they cannot choose another way to
> handle user logged-out in the middle of a FedCM button flow. In addition,
> we provided this deck
> <https://docs.google.com/presentation/d/1iURrPakaHgBfQ6mAefKijjxToiTTgBSPz1rtaV0od98/edit?usp=sharing>
>  of
> mocks w.r.t. how Chrome plans to implement the Button flow. We may change
> some of the UI affordance during OT and will publish a blog post with
> instruction and proposed UX soon.
>
> Please let us know if we could make it more clear for developers.
>
> Yi
>
> On Fri, Apr 5, 2024 at 9:36 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>>
>>
>> On Tuesday, February 27, 2024 at 1:43:01 AM UTC+1 Mike Taylor wrote:
>>
>> That said, please request approvals from the various review gates in your
>> chromestatus entry before experimenting.
>> On 2/26/24 7:41 PM, Mike Taylor wrote:
>>
>> LGTM to experiment from M124 to M127 inclusive.
>> On 2/26/24 5:45 PM, Yi Gu wrote:
>>
>> Contact emails
>>
>>
>> * y...@chromium.org , cbiesin...@chromium.org
>> , tanzach...@chromium.org
>>  * Explainer
>>
>> * https://github.com/fedidcg/FedCM/issues/442
>> <https://github.com/fedidcg/FedCM/issues/442#issuecomment-1949323416>*
>>
>> With my API owner hat off, this is not sufficient as an explainer, and
>> makes it hard for me to assess the technical complexity of participating in
>> the OT.
>> I think it'd be good to elaborate on the exact flows that button mode
>> enables. (e.g. what happens when the user is not logged in to the IdP? Does
>> the browser automatically opens a separate window to handle that log in? Is
>> this something that the IdP should handle? If so, how?)
>>
>>
>> Specification
>>
>>
>> * https://fedidcg.github.io/FedCM <https://fedidcg.github.io/FedCM> This
>> will be added as an extension. * Summary
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> * We plan to experiment with two new extensions for the Federated
>> Credential Management (FedCM) API: - Button Mode API - The button mode lets
>> websites trigger FedCM directly when a user clicks a button (like a
>> "Sign-in with IdP" button). This means FedCM will always display a visible
>> user interface for login, in contrast to the widget mode where no UI is
>> shown if a user’s login status is logged out.  - When the FedCM API is used
>> in "button mode" and a user isn't logged in, they'll be taken to the IdP
>> login screen (in a pop-up window). Since this happens in response to a
>> clear user action, the UI might even be more prominent (e.g., centered and
>> modal) compared to the more subtle UI of widget mode. - Use Other Account
>> API - With this API, an Identity Provider can request the browser to show a
>> button that allows users to choose other accounts. * Blink component
>>
>>
>> * Blink>Identity>FedCM
>> <https://issues.chromium.org/u/1/issues?q=status:open%20componentid:1456331=created_time:desc>
>> * Search tags
>>
>>
>> * fedcm <https://chromestatus.com/features#fedcm> * TAG review
>>
>>
>> * https://github.com/w3ctag/design-reviews/issues/935
>> <https://github.com/w3ctag/design-reviews/issues/935>  * TAG review
>> status
>>
>>
>> * Pending * Risks
>>
>> Interoperability and Compatibility
>>
>>
>>
>>
>>
>>
>>
>> * These are extensions to the FedCM API. Apple and Mozilla have both
>> expressed a positive opinion on the initial FedCM API [1]. They have not
>> yet shipped but Mozilla is prototyping [2]. If a user agent chooses not to
>> implement these extensions, the sign-in flow should not be affected in that
>> user agent because developers can fallback to the existing federated
>> sign-in mechanisms. [1]
>> https://groups.google.com/a/chromium

Re: [blink-dev] Intent to Ship: Protected Audience: Split up large trusted signals fetches & deprectedReplaceInURN via auction config

LGTM2

On Mon, Apr 8, 2024 at 5:36 PM Mike Taylor  wrote:

> LGTM1
> On 4/3/24 11:05 AM, Daniel Bratell wrote:
>
> Thanks, that clarifies a bit and calms my worries considerably.
>
> /Daniel
> On 2024-03-29 14:27, Paul Jensen wrote:
>
> Daniel, I hear your concerns, but I should clarify that this splitting up
> of large requests does not do any reassembly or combining of responses, so
> sequencing or ordering between responses is not a concern.  The Key-Value
> servers answering the queries are stateless and should have no ability to
> associate requests
> <https://github.com/privacysandbox/protected-auction-services-docs/blob/main/key_value_service_trust_model.md#:~:text=the%20return%20value%20for%20each%20key%20will%20be%20based%20only%20on%20that%20key>.
>
> The browser has a number of interest groups or bids that need their
> trusted signals fetched.  The browser can make each fetch individually or
> in a combined fashion, but each individual response is only supplied to the
> corresponding requesters; responses are not combined for requesters.
>
> On Wed, Mar 27, 2024 at 12:21 PM Daniel Bratell 
> wrote:
>
>> I can't help thinking about all the problems exposed when malicious use
>> of Out of Sequence TCP became a thing among the evil-doers. It turned out
>> that once you split something up, it's not always easy to put it back
>> together again. It is a solved problem (but not quite, I found newly
>> discovered exploits when searching for references) in network layers but
>> only through a lot of pain and suffering.
>>
>> There were the things that people with evil intent did, like sending only
>> part of a sequence, filling up buffers that were waiting for the rest or
>> reorder in complicated ways, or make a million small parts instead of one
>> large. Could that become an attack surface here?
>>
>> And there were the random reordering that just happened due to networks
>> being unpredictable which servers were in general badly equipped to handle.
>> Could reordering happen here?
>>
>> Either way, I worry that this could become a source of random problems
>> that would be hard to understand or debug. Is there any third or fourth
>> option to consider?
>>
>> /Daniel
>> On 2024-03-25 17:44, 'Paul Jensen' via blink-dev wrote:
>>
>>
>>
>> On Wed, Mar 20, 2024 at 2:02 PM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>>
>>>
>>> On Thu, Mar 14, 2024 at 8:48 PM Paul Jensen 
>>> wrote:
>>>
>>>> Contact emails
>>>>
>>>> pauljen...@chromium.org
>>>>
>>>>
>>>> Explainer
>>>>
>>>> Split up large trusted signals fetches:
>>>> https://github.com/WICG/turtledove/pull/1070
>>>>
>>>> deprectedReplaceInURN via auction config:
>>>> https://github.com/WICG/turtledove/pull/1069
>>>>
>>>>
>>>> Specification
>>>>
>>>> Split up large trusted signals fetches:
>>>> https://github.com/WICG/turtledove/pull/1065
>>>>
>>>> deprectedReplaceInURN via auction config:
>>>> https://github.com/WICG/turtledove/pull/1051
>>>>
>>>>
>>>> Summary
>>>>
>>>> These are the changes to Protected Audience that we’d like to ship:
>>>>
>>>> Split up large trusted signals fetches:
>>>>
>>>> During Protected Audience auctions the browser fetches real-time
>>>> signals from buyers' and sellers' key-value servers. These fetches are
>>>> currently HTTP GET requests with URLs that the browser assembles by
>>>> concatenating several individual requests together. The URLs can grow
>>>> larger than some HTTP servers support resulting in failing requests and
>>>> reduced website ad revenue. The proposal here is for buyers and sellers to
>>>> specify the maximum size of these URLs and for the browser to split large
>>>> requests into chunks no larger than the specified maximum size.
>>>>
>>>
>>> If I understand correctly what y'all are trying to do here, you're
>>> trying to effectively recreate with GETs what should've been a POST.
>>> Is the reasoning for that outlined somewhere?
>>>
>>> POSTs have many advantages over GETs when transferring large amounts of
>>> data to the server. Most importantly, they tend to actually pass through.
>>> Beyond that, the data is not typically saved to logs (whereas URLs often
>>> are). Fina

Re: [blink-dev] Intent to Ship: CSS Stepped Value Functions

Can you please flip on the "debuggability" review bit in chromestatus?
(feel free to mark it as "N/A" if you think that's the case)

On Mon, Apr 8, 2024 at 4:40 PM Yoav Weiss (@Shopify) 
wrote:

> LGTM1
>
> Thanks for catching us up here!
>
> On Fri, Apr 5, 2024 at 3:53 PM Daniil Sakhapov 
> wrote:
>
>> Contact emailssakha...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://drafts.csswg.org/css-values/#round-func
>>
>> Summary
>>
>> The stepped-value functions, round(), mod(), and rem(), all transform a
>> given value according to another "step value". The round() CSS function
>> returns a rounded number based on a selected rounding strategy. The mod()
>> CSS function returns a modulus left over when the first parameter is
>> divided by the second parameter, similar to the JavaScript remainder
>> operator (%). The modulus is the value left over when one operand, the
>> dividend, is divided by a second operand, the divisor. It always takes the
>> sign of the divisor. The rem() CSS function returns a remainder left over
>> when the first parameter is divided by the second parameter, similar to the
>> JavaScript remainder operator (%). The remainder is the value left over
>> when one operand, the dividend, is divided by a second operand, the
>> divisor. It always takes the sign of the dividend.
>>
>>
>> Blink componentBlink>CSS
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>
>> TAG reviewNone
>>
>> TAG review statusIssues addressed
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> None
>>
>>
>> *Gecko*: Shipped/Shipping
>>
>> *WebKit*: Shipped/Shipping
>>
>> *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)?Yes
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ?Yes
>>
>> https://wpt.fyi/results/css/css-values/round-mod-rem-computed.html
>> https://wpt.fyi/results/css/css-values/round-mod-rem-invalid.html
>> https://wpt.fyi/results/css/css-values/round-mod-rem-serialize.html
>>
>>
>> Flag name on chrome://flagsCSSSteppedValueFunctions
>>
>> Finch feature nameNone
>>
>> Non-finch justificationNone
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://issues.chromium.org/issues/40253179
>>
>> Estimated milestones
>> Shipping on desktop 125
>> DevTrial on desktop 119
>> Shipping on Android 125
>> DevTrial on Android 119
>> Shipping on WebView 125
>>
>> 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/5500897196244992
>>
>> This intent message was generated by Chrome Platform Status
>> <https://chromestatus.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/CAH3Z92_-CiZrV1FR4wBuDV2ootDfhgcERNO6%3DB5HGfPwW1aaBA%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH3Z92_-CiZrV1FR4wBuDV2ootDfhgcERNO6%3DB5HGfPwW1aaBA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

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

Re: [blink-dev] Intent to Ship: CSS Stepped Value Functions

LGTM1

Thanks for catching us up here!

On Fri, Apr 5, 2024 at 3:53 PM Daniil Sakhapov 
wrote:

> Contact emailssakha...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://drafts.csswg.org/css-values/#round-func
>
> Summary
>
> The stepped-value functions, round(), mod(), and rem(), all transform a
> given value according to another "step value". The round() CSS function
> returns a rounded number based on a selected rounding strategy. The mod()
> CSS function returns a modulus left over when the first parameter is
> divided by the second parameter, similar to the JavaScript remainder
> operator (%). The modulus is the value left over when one operand, the
> dividend, is divided by a second operand, the divisor. It always takes the
> sign of the divisor. The rem() CSS function returns a remainder left over
> when the first parameter is divided by the second parameter, similar to the
> JavaScript remainder operator (%). The remainder is the value left over
> when one operand, the dividend, is divided by a second operand, the
> divisor. It always takes the sign of the dividend.
>
>
> Blink componentBlink>CSS
> 
>
> TAG reviewNone
>
> TAG review statusIssues addressed
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: Shipped/Shipping
>
> *WebKit*: Shipped/Shipping
>
> *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)?Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
> https://wpt.fyi/results/css/css-values/round-mod-rem-computed.html
> https://wpt.fyi/results/css/css-values/round-mod-rem-invalid.html
> https://wpt.fyi/results/css/css-values/round-mod-rem-serialize.html
>
>
> Flag name on chrome://flagsCSSSteppedValueFunctions
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://issues.chromium.org/issues/40253179
>
> Estimated milestones
> Shipping on desktop 125
> DevTrial on desktop 119
> Shipping on Android 125
> DevTrial on Android 119
> Shipping on WebView 125
>
> 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/5500897196244992
>
> 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/CAH3Z92_-CiZrV1FR4wBuDV2ootDfhgcERNO6%3DB5HGfPwW1aaBA%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/CAOmohSLV8RBivu9GCvudaXzd9G%2BQi9nvbT64tGvuVEqH935p1g%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype: Document-Isolation-Policy

This is very interesting!

Do I understand correctly and the main reason this would be easier to
deploy is because embedded iframes and popups won't need to deploy COEP in
this model?

On Fri, Apr 5, 2024 at 12:14 PM Camille Lamy  wrote:

> Yes the user agent keying is deterministic, and we're adding reporting to
> warn developers if they end up having two same origin documents that could
> normally have DOM access but can't due to Document-Isolation-Policy.


I'm not sure same-origin isolation won't end up being a desired feature
on its own. I heard developers asking for stronger isolation primitives on
more than one occasion. I'll talk to folks and think about it some more.


> Our recommendation would be to adopt the header on all documents of an
> origin, which removes the concerns around script access. As a followup, we
> might resurrect the Origin-Policy work to help with this issue.


Origin-Policy would definitely help avoid mistakes here..


>
> For COOP and COEP, you're correct to note that they are not available due
> to the platform limitations on Android WebView. Because of this, the
> crossOriginIsolated spec already has a notion of crossOriginIsolation being
> either logical (ie no API access) or effective (ie API access). We're
> building on this existing notion.
>
> In terms of platform support, our goal is to first release on desktop, in
> order to finally end the ungated SAB reverse Origin Trial. Then we'll
> extend to Android (but not Android WebView). For Android, the situation is
> a bit different from full Site Isolation, because here the isolation and
> resulting increase memory consumption is driven by the website as opposed
> to the platform. We might not implement full functionality on low-end
> Android, but then none of the developers interested in the API want to have
> it run on low-end Android. Basically, this gives access to
> SharedArrayBuffers, which are mostly useful to cut calculation time in
> heavy web apps, that wouldn't run on devices with limited hardware.
>
> Hope that helps!
> Camille
>
> On Thursday, April 4, 2024 at 9:45:04 PM UTC+2 Charlie Reis wrote:
>
>> I seem to recall that Android Chrome is also limited here, but maybe that
>>> has changed and my knowledge is outdated.
>>>
>>
>> Correct, we don't usually create out-of-process iframes on Android Chrome
>> if the device has less than 2G of RAM.  Otherwise we allow it (e.g., for 
>> partial
>> Site Isolation
>> ).
>> I'm not sure if COOP+COEP has any restrictions on low-end Android devices,
>> since that mode requires multiple processes but not out-of-process
>> iframes.  For Document-Isolation-Policy, I believe there's some notes about
>> low-end Android devices in the explainer, maybe suggesting that it's less
>> needed on such devices?  I'll let Camille clarify.
>>
>> Charlie
>>
>> On Thu, Apr 4, 2024 at 12:27 PM Vladimir Levin 
>> wrote:
>>
>>>
>>>
>>> On Thu, Apr 4, 2024 at 12:11 PM Charlie Reis  wrote:
>>>
 My understanding is that at least this behavior is deterministic,
> right? That is, either the same-origin frames will be able to script each
> other or they won't and this will happen consistently (based on the agent
> cluster key).
>

 Yes, I think it would be deterministic based on the headers, so
 hopefully education via error messages would help.

 An observation I had is that it seems that the
> Document-Isolation-Policy is still at the mercy of the platform having the
> resources to process-isolate frames.
>

 Camille can probably confirm the details, but I believe that's right.
 COOP+COEP depends on the platform being able to open a new window in a
 different process, which I think all platforms but Android WebView can
 support at this point (?).  Document-Isolation-Policy would depend on
 out-of-process iframes, which wouldn't work on Android WebView or iOS, at
 least for the time being.  On platforms that do support out-of-process
 iframes, it would make crossOriginIsolated modes much easier to adopt,
 though.

>>>
>>> I seem to recall that Android Chrome is also limited here, but maybe
>>> that has changed and my knowledge is outdated.
>>>
>>>

 Also I'm not sure if it would be possible for 3p iframes to starve
> platform of such resources so that the top level frame would no longer be
> able to create 1p frames that have access to COI-gated APIs
>

 IIUC, I think each origin is limited in the number of processes it
 could create in a given page (basically one with SAB access and one
 without), which helps.

>>>
>>> Ah that makes sense. There may still be some possibility with just
>>> spamming 3p iframes but that likely exists today anyway
>>>
>>> Thanks!
>>> Vlad
>>>
>>>

 Charlie

 On Thu, Apr 4, 2024 at 8:05 AM Vladimir

Re: [blink-dev] Web-Facing Change PSA: Support "color-interpolation: linearrgb" on SVG gradients

2024-04-07 Thread Yoav Weiss (@Shopify)

+1 to sending an intent here. Thanks!! :)

On Sun, Apr 7, 2024 at 1:12 AM Mike Taylor  wrote:

>
> On 4/4/24 4:29 AM, Fredrik Söderquist wrote:
>
> On Thu, Apr 4, 2024 at 1:22 AM Mike Taylor  wrote:
>
>> Hi Fredrik,
>>
>> Just to confim - this is adding support for a new `color-interpolation`
>> property value, yes (vs a bugfix or behavior change to an existing
>> feature)? If so, can you send an Intent to Ship rather than a PSA?
>>
> No, it's applying an existing property value ('linearRGB') in yet another
> context (SVG gradients). Previously it was applied within SVG 
> elements.
>
> Thanks - I did misunderstand then. That said, this will still need an
> Intent to Ship, as we're exposing new functionality that did not previously
> exist in Chromium.
>
> thanks,
> Mike
>
>
>
> /fs
>
>
>> thanks,
>> Mike
>> On 4/3/24 10:15 AM, Fredrik Söderquist wrote:
>>
>> Contact emails f...@opera.com
>>
>> Specification
>> https://svgwg.org/svg2-draft/painting.html#ColorInterpolation
>>
>> Summary
>>
>> Allows SVG gradients to interpolate in a linear-light sRGB color space.
>> Currently all SVG gradients interpolate in a gamma-encoded sRGB color space.
>>
>>
>> Blink component Blink>SVG
>> 
>>
>> TAG review None. This feature (property-value pair) has been specified
>> for ~20 years by now.
>>
>> TAG review status Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> The risk along both axes is fairly low since the difference is in
>> rendering only (even if the rendering can differ quite significantly).
>>
>>
>> *Gecko*: Shipped/Shipping (
>> https://www.mozilla.org/en-US/firefox/123.0/releasenotes)
>>
>> *WebKit*: No signal (Implementation bug,
>> https://bugs.webkit.org/show_bug.cgi?id=234783, was pinged)
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> None
>>
>>
>> Debuggability
>>
>> Nothing specific need, this feature just changes how colors are
>> interpolated
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, ChromeOS, Android, and Android WebView)? Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ? Yes
>>
>>
>> https://wpt.fyi/results/svg/pservers/reftests/gradient-color-interpolation.svg
>>
>>
>> Flag name on chrome://flags None
>>
>> Finch feature name SvgGradientColorInterpolationLinearRgbSupport
>>
>> Requires code in //chrome? No
>>
>> Estimated milestones
>> Shipping on desktop 125
>> Shipping on Android 125
>> Shipping on WebView 125
>> Shipping on WebView 125
>>
>> Anticipated spec changes
>>
>> None
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5120997943672832?gate=5096917471330304
>>
>> 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/CAHediLSKwbQdU%2B%3DWa7_qRyK1bVF1-v0WFwfJgtf9xcYv5w86_g%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/de0d4da4-85a6-491a-88ca-5503edbe30f8%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/CAOmohSLLvQzstfWG7nQOwR5X1pjOFGLkv9P5RH3rGX0woo_HNg%40mail.gmail.com.

Re: [blink-dev] Intent to Experiment: FedCM Button Mode API and Use Other Account API

2024-04-05 Thread Yoav Weiss (@Shopify)



On Tuesday, February 27, 2024 at 1:43:01 AM UTC+1 Mike Taylor wrote:

That said, please request approvals from the various review gates in your 
chromestatus entry before experimenting.
On 2/26/24 7:41 PM, Mike Taylor wrote:

LGTM to experiment from M124 to M127 inclusive.
On 2/26/24 5:45 PM, Yi Gu wrote:

Contact emails 


* y...@chromium.org , cbiesin...@chromium.org 
, tanzach...@chromium.org 
 * Explainer 

* https://github.com/fedidcg/FedCM/issues/442 
*

With my API owner hat off, this is not sufficient as an explainer, and 
makes it hard for me to assess the technical complexity of participating in 
the OT.
I think it'd be good to elaborate on the exact flows that button mode 
enables. (e.g. what happens when the user is not logged in to the IdP? Does 
the browser automatically opens a separate window to handle that log in? Is 
this something that the IdP should handle? If so, how?)


Specification 


* https://fedidcg.github.io/FedCM  This 
will be added as an extension. * Summary 









* We plan to experiment with two new extensions for the Federated 
Credential Management (FedCM) API: - Button Mode API - The button mode lets 
websites trigger FedCM directly when a user clicks a button (like a 
"Sign-in with IdP" button). This means FedCM will always display a visible 
user interface for login, in contrast to the widget mode where no UI is 
shown if a user’s login status is logged out.  - When the FedCM API is used 
in "button mode" and a user isn't logged in, they'll be taken to the IdP 
login screen (in a pop-up window). Since this happens in response to a 
clear user action, the UI might even be more prominent (e.g., centered and 
modal) compared to the more subtle UI of widget mode. - Use Other Account 
API - With this API, an Identity Provider can request the browser to show a 
button that allows users to choose other accounts. * Blink component 


* Blink>Identity>FedCM 

 
* Search tags 


* fedcm  * TAG review 


* https://github.com/w3ctag/design-reviews/issues/935 
  * TAG review status 


* Pending * Risks 

Interoperability and Compatibility 







* These are extensions to the FedCM API. Apple and Mozilla have both 
expressed a positive opinion on the initial FedCM API [1]. They have not 
yet shipped but Mozilla is prototyping [2]. If a user agent chooses not to 
implement these extensions, the sign-in flow should not be affected in that 
user agent because developers can fallback to the existing federated 
sign-in mechanisms. [1] 
https://groups.google.com/a/chromium.org/g/blink-dev/c/URpYPPH-YQ4/m/bzghj9N3AQAJ
 

  
[2] 
https://groups.google.com/a/mozilla.org/g/dev-platform/c/ncmUwK1uO98/m/COhPA4ZrAAAJ
 

  
Gecko: No signal WebKit: No signal Web developers: Positive 
(https://github.com/fedidcg/FedCM/issues/442 
) These features are being 
developed to address existing feedback for the FedCM API. Other signals: * 
Activation 




* Similar to the FedCM API, we deliberately leave the bulk of the work to 
the IdP to ensure that minimal RP change is needed.  This feature, 
specifically, is one that can be currently controlled by IdP (via JS SDK 
for “button mode”, via server-side config for “use other account”), so we 
expect activation to have a similar profile as FedCM: immediately enabled 
to websites (without redeployment) by IdPs making use of it (by redeploying 
their JS SDKs). * Security 




* The button mode shares most of the security properties from the widget 
mode. e.g. honoring CSP, CORS, using security headers, not asking users to 
type in the browser UI etc. It’s worth noting that the pop-up window has 
the same web platform properties as what one would get with 
window.open(url,””,”popup,noopener,noreferrer”) that loads the login_url. 
It is important to note that there's no communication allowed between the 
website and this pop-up (e.g. no postMessage, no window.opener). We have 
shipped LoginStatus API and Error API in FedCM that use this type of pop-up 
window. * 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 * 
Goals 
for experimentation 


* Gather data on whether a browser mediated sign in flow on a critical user 
journey is well received by users and developers. We'd like to see how the 
proposed UI/API play out and iterate on them to ship the API in its best 
shape. * Ongoing technical constraints 



* None * Debuggability

Re: [blink-dev] Intent to Extend Deprecation Trial: Removal of X-Requested-With in WebView

2024-04-04 Thread Yoav Weiss (@Shopify)

LGTM2 to continue the Deprecation Trial until M138.

Thanks for pushing this through! It'd be great if by the time this trial
expires we'd have a clearer picture of the required replacement mechanisms
and some momentum for moving trial participants off to them.

On Thu, Apr 4, 2024 at 3:21 PM Peter Birk Pakkenberg 
wrote:

> Hi Yoav,
>
> The X-Requested-With header exposes the app package name of the embedding
> application on all HTTP requests made from WebView. The header value is not
> signed, and can be changed either by web content loaded in the WebView, or
> by the host app, through various well known methods.
>
> Media content providers have been using this information in an effort to
> help identify abuse and fraud, and the WebView Media Integrity API has been
> developed to be a more direct fit for these use cases.
>
> We are working with the remaining OT participants to determine what, if
> any, further solutions are needed for their use cases of the header.
>
> Sincerely,
> [image: Google Logo]
> Peter Birk Pakkenberg
> Software Engineer
> pb...@chromium.org
>
>
> On Wed, 3 Apr 2024 at 11:06, Yoav Weiss (@Shopify) 
> wrote:
>
>>
>>
>> On Thursday, March 28, 2024 at 12:53:04 PM UTC+1 Peter Pakkenberg wrote:
>>
>> Hi Yoav,
>>
>> A number of large websites are working on adopting the new WebView Media
>> Integrity API as an alternative
>>
>>
>> Can you elaborate on the connection between the two? Are there
>> overlapping use cases?
>> I guess I'm missing context on what information is currently exposed with
>> X-Requested-With..
>>
>>
>> , however, that said, other websites have expressed hesitancy to move
>> away from using the header, citing the lack of alternative signals that
>> solve their more precise use cases.
>>
>>
>> So in order for those websites to move away from the header's use, we'd
>> need to ship another alternative API? Is this being worked on?
>>
>>
>>
>> Looking at the signed up origins, it appears that the usage of the header
>> is quite unevenly distributed, and we are working directly with the largest
>> users to reduce usage.
>>
>> Sincerely,
>> [image: Google Logo]Peter Birk PakkenbergSoftware Engineer
>> pb...@chromium.org
>>
>> On Thu, 28 Mar 2024 at 08:40, Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>> Of the 100+ origins that signed up for the trial, do you know if any made
>> progress towards reducing their dependence on this header? Any that no
>> longer need the trial?
>>
>> On Wed, Mar 27, 2024 at 5:03 PM Daniel Bratell 
>> wrote:
>>
>> This being beyond the normal scope of an extension will require three
>> LGTMS so here is the first one:
>>
>> LGTM1
>>
>> I appreciate that it's not optimal in any way to have something like this
>> running this long, but I sympathize with the end result and understand that
>> App developers can need both longer to develop and especially longer to
>> deploy to all users. That as many as 10k applications have adapted the new
>> API is a good sign too.
>>
>> If I were going to ask for anything else (which might make it easier for
>> others to approve it), it would be proof that usage is dropping so that we
>> won't have to extend it again.
>>
>> /Daniel
>> On 2024-03-27 12:15, Peter Birk Pakkenberg wrote:
>>
>> Hello Blink-dev.
>>
>> I would like to extend the ‘X-Requested-With in WebView Deprecation’
>> trial until M138 in line with the premise made below in the Summary below.
>> I am asking for an extension of 12 milestones instead of the customary 6
>> <https://www.chromium.org/blink/launching-features/#deprecation-trial>
>> to avoid undue churn for the almost 100 origins that have signed up for the
>> trial, as we expect that it will take at least another year to address the
>> remaining use cases.
>>
>> The feature is currently disabled on 5% of stable traffic, and we have
>> developed the Android WebView Media Integrity API
>> <https://android-developers.googleblog.com/2023/11/increasing-trust-for-embedded-media.html>
>> as a solution for uses of the header for media content providers. We have
>> also launched an Android API for app developers to enable the header for
>> select origins
>> <https://developer.android.com/reference/androidx/webkit/WebSettingsCompat#setRequestedWithHeaderOriginAllowList(android.webkit.WebSettings,java.util.Set%3Cjava.lang.String%3E)>
>> which has been adopted by almost 10k applications so far. This is an
>&g

Re: [blink-dev] Intent for Reverse Origin Trial: Media Previews opt-out

Another question - do you want this browser UI feature to be controlled
with an Origin Trial? If so, can you expand on the reasoning?

On Wed, Apr 3, 2024 at 7:25 PM mark a. foltz  wrote:

> That's correct.  This will impact Chrome's permission UI but not the
> behavior of the gated web APIs (navigator.mediaDevices.getUserMedia /
> navigator.mediaDevices.enumerateDevices).
>
>
> On Wed, Apr 3, 2024 at 3:02 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>> Do I understand correctly that this intent only concerns the permission
>> UI itself and is not web exposed in any way?
>>
>> On Tue, Apr 2, 2024 at 7:16 PM mark a. foltz  wrote:
>>
>>> FYI, this request has been shifted one milestone forward (from 124 =>
>>> 135, to 125 => 136) because of some UI changes that will require additional
>>> eng work to address.
>>>
>>> On Fri, Mar 29, 2024 at 10:04 AM mark a. foltz 
>>> wrote:
>>>
>>>> The automatically generated subject wasn't appropriate for this intent,
>>>> so I edited it by hand.  I think Jason is aware of it as I was conversing
>>>> with him on a GitHub issue about it.
>>>>
>>>> On Wed, Mar 27, 2024 at 8:28 AM Yoav Weiss (@Shopify) <
>>>> yoavwe...@chromium.org> wrote:
>>>>
>>>>> As a heads up, this wasn't caught in the API owner tooling, probably
>>>>> due to the unconventional title.
>>>>>
>>>>> +Jason Robbins  - FYI
>>>>>
>>>>> On Tue, Mar 26, 2024 at 9:33 PM mark a. foltz 
>>>>> wrote:
>>>>>
>>>>>> Contact emailsmfo...@chromium.org, bryantchand...@chromium.org
>>>>>>
>>>>>> ExplainerNone
>>>>>>
>>>>>> Specification
>>>>>> https://docs.google.com/document/d/1ZnX2JROjr9l4y2_OPMpfVlLOo-A5cQzD4mWarj9kXQ0/edit
>>>>>>
>>>>>> Design docs
>>>>>>
>>>>>> https://docs.google.com/document/d/1ZnX2JROjr9l4y2_OPMpfVlLOo-A5cQzD4mWarj9kXQ0/edit
>>>>>>
>>>>>> Summary
>>>>>>
>>>>>> Allow coordination between sites using Page Embedded Permissions
>>>>>> Controls and concurrent experiments with the camera and microphone
>>>>>> permissions UI in Chrome.
>>>>>>
>>>>>>
>>>>>> Blink componentBlink>MediaStream
>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EMediaStream>
>>>>>>
>>>>>> TAG reviewNone
>>>>>>
>>>>>> TAG review statusNot applicable
>>>>>>
>>>>>> Risks
>>>>>>
>>>>>>
>>>>>> Interoperability and Compatibility
>>>>>>
>>>>>> None as this feature concerns the functionality of Chrome's
>>>>>> permissions UI, and does not change the behavior of the APIs that are 
>>>>>> gated
>>>>>> by it: navigator.mediaDevices.enumerateDevices and
>>>>>> navigator.mediaDevices.getUserMedia Other browsers implement their own
>>>>>> permissions UIs independently of Chrome.
>>>>>>
>>>>>>
>>>>>> *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
>>>>>>
>>>>>>
>>>>>> Is this feature fully tested by web-platform-tests
>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>>>> ?No
>>>>>>
>>>>>> Flag name on chrome://flags--enable-features=camera-mic-preview
>>>>>>
>>>>>> Finch feature nameCameraMicPreview
>>>>>>
>>>>>> Requires code in //chrome?False
>>>>>>
>>>>>> Tracking bughttps://issues.chromium.org/330762482
>>>>>>
>>>>>> Launch bughttps://launch.corp.google.com/launch/4304480
>>>>>>
>>>>>> Estimated milestones
>>>>>> Origin trial desktop first 124
>>>>>> Origin trial desktop last 135
>>>>>>
>>>>>> Link to entry on the Chrome Platform Status
>>>>>> https://chromestatus.com/feature/5100528783851520?gate=5076768018137088
>>>>>>
>>>>>> This intent message was generated by Chrome Platform Status
>>>>>> <https://chromestatus.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/CALgg%2BHG8dcBFh%2Bw4WbVwVbYvTJ8y5DzrhaxkU%3D2vWMyB0ixUeQ%40mail.gmail.com
>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALgg%2BHG8dcBFh%2Bw4WbVwVbYvTJ8y5DzrhaxkU%3D2vWMyB0ixUeQ%40mail.gmail.com?utm_medium=email_source=footer>
>>>>>> .
>>>>>>
>>>>>

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

Re: [blink-dev] Intent to Ship: RegExp modifiers

LGTM3

On Thu, Mar 28, 2024 at 3:38 AM Domenic Denicola 
wrote:

> LGTM2
>
> On Thu, Mar 28, 2024 at 3:11 AM Mike Taylor 
> wrote:
>
>> LGTM1 - looks like a useful addition already supported in a number of
>> other RegExp engines.
>> On 3/27/24 11:38 AM, 'Shu-yu Guo' via blink-dev wrote:
>>
>> Contact emails s...@chromium.org, pth...@chromium.org
>>
>> Explainer None
>>
>> Specification https://tc39.es/proposal-regexp-modifiers
>>
>> Summary
>>
>> RegExp modifiers adds the ability to locally modify the 'i', 'm', and 's'
>> flags inside a pattern. To enable a flag for a subexpression, use
>> `(?X:subexpr)` where X is one of 'i', 'm', or 's'. To disable a flag for a
>> subexpression, use `(-X:subexpr)`. For example, for the case-insensitivity
>> 'i' flag: ``` const re1 = /^[a-z](?-i:[a-z])$/i; re1.test("ab"); // true
>> re1.test("Ab"); // true re1.test("aB"); // false const re2 =
>> /^(?i:[a-z])[a-z]$/; re2.test("ab"); // true re2.test("Ab"); // true
>> re2.test("aB"); // false ```
>>
>>
>> Blink component Blink>JavaScript>Regexp
>> 
>>
>> TAG review None
>>
>> TAG review status Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> No interoperability risk. This is a Stage 3 TC39 proposal.
>>
>>
>> *Gecko*: Positive TC39 Stage 3
>>
>> *WebKit*: Positive TC39 Stage 3
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None
>>
>>
>> Debuggability
>>
>> No special needs. JS RegExps already debuggable.
>>
>>
>> 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
>>
>> In test262: https://github.com/tc39/test262/pull/3960
>>
>>
>> Flag name on chrome://flags --js-regexp-modifiers
>>
>> Finch feature name JavaScriptRegExpModifiers
>>
>> Requires code in //chrome? False
>>
>> Estimated milestones
>> DevTrial on desktop 122
>> DevTrial on Android 122
>>
>> 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/5100254548721664
>>
>> 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/CAN-e9e948%3DQSg6zskRN25JGkvxXVP67RDkXHvijzBRueP1DnzA%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/719d4913-1462-479c-b2e4-7ad6cd36c539%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/CAM0wra8qfsTjt%2Bw62YBzV74FN4SKLOLqjrVky52Jzp03wyfjQA%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/CAOmohSKi-bQZWCMkkprVE0v0i%3DJi_XPm5E91qLV9xfxm7OGAkg%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: visualViewport.onscrollend Support

LGTM3 as a test was added!

On Wednesday, March 27, 2024 at 4:21:49 PM UTC+1 Mike Taylor wrote:

> LGTM2
> On 3/26/24 10:50 PM, Domenic Denicola wrote:
>
> LGTM1, this is a very small change that IMO does not require any signals 
> or TAG review. It's just bringing this event in line with all other events 
> on the platform. 
>
> (It would be cool if there were some automated way of preventing this kind 
> of omission in the future.)
>
> On Wednesday, March 27, 2024 at 9:49:16 AM UTC+9 David Awogbemila wrote:
>
>> Contact emails awogbem...@google.com
>>
>> Explainer None
>>
>> Specification 
>> https://drafts.csswg.org/cssom-view/#the-visualviewport-interface
>>
>> Summary 
>>
>> Scrollend is a JavaScript event that fires to signal that a scrolling 
>> operation has come to an end. Similar to the Element interface[1], the 
>> visualViewport interface[2] includes an onscrollend event handler that 
>> should be invoked when a scrolling operation on the visualViewport has 
>> ended. Chromium already supports adding a scrollend event listener via 
>> `visualViewport.addEventListener("scrollend")`. This just makes it possible 
>> to also add an event listener using `visualViewport.onscrollend`. [1]
>> https://html.spec.whatwg.org/multipage/webappapis.html#handler-onscrollend 
>> [2]https://drafts.csswg.org/cssom-view/#dom-visualviewport-onscrollend.
>>
>>
>> Blink component Blink>Scroll 
>> 
>>
>> TAG review None
>>
>> TAG review status Not applicable
>>
>> Risks 
>>
>>
>> Interoperability and Compatibility 
>>
>> None
>>
>>
>> *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 
>>
>> This makes it possible to add breakpoints to event handlers added by 
>> `visualViewport.onscrollend` similar to `visualViewport.onscroll` or 
>> onscrollend for any other element.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>> Linux, ChromeOS, Android, and Android WebView)? Yes
>>
>> Is this feature fully tested by web-platform-tests 
>> 
>> ? Yes 
>>
>>
>> https://wpt.fyi/results/dom/events/scrolling/scrollend-event-fires-on-visual-viewport.html?label=experimental=master
>>
>>
>> Flag name on chrome://flags None
>>
>> Finch feature name ScrollEndEvents
>>
>> Requires code in //chrome? False
>>
>> Tracking bug https://crbug.com/325307785
>>
>> Estimated milestones 
>> Shipping on desktop 125 
>> Shipping on Android 125 
>> Shipping on WebView 125 
>>
>> 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/5774579609108480?gate=4770235262697472
>>
>> 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/db5674cc-3c3c-4092-bed7-9cf64c2fc59bn%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/313623d6-afe6-40a9-88aa-d34b4c53042cn%40chromium.org.

Re: [blink-dev] Intent to Extend Deprecation Trial: Removal of X-Requested-With in WebView



On Thursday, March 28, 2024 at 12:53:04 PM UTC+1 Peter Pakkenberg wrote:

Hi Yoav,

A number of large websites are working on adopting the new WebView Media 
Integrity API as an alternative


Can you elaborate on the connection between the two? Are there overlapping 
use cases?
I guess I'm missing context on what information is currently exposed with 
X-Requested-With..
 

, however, that said, other websites have expressed hesitancy to move away 
from using the header, citing the lack of alternative signals that solve 
their more precise use cases.


So in order for those websites to move away from the header's use, we'd 
need to ship another alternative API? Is this being worked on?
 


Looking at the signed up origins, it appears that the usage of the header 
is quite unevenly distributed, and we are working directly with the largest 
users to reduce usage.

Sincerely,
[image: Google Logo]Peter Birk PakkenbergSoftware engineerpb...@chromium.org

On Thu, 28 Mar 2024 at 08:40, Yoav Weiss (@Shopify)  
wrote:

Of the 100+ origins that signed up for the trial, do you know if any made 
progress towards reducing their dependence on this header? Any that no 
longer need the trial?

On Wed, Mar 27, 2024 at 5:03 PM Daniel Bratell  wrote:

This being beyond the normal scope of an extension will require three LGTMS 
so here is the first one:

LGTM1

I appreciate that it's not optimal in any way to have something like this 
running this long, but I sympathize with the end result and understand that 
App developers can need both longer to develop and especially longer to 
deploy to all users. That as many as 10k applications have adapted the new 
API is a good sign too.

If I were going to ask for anything else (which might make it easier for 
others to approve it), it would be proof that usage is dropping so that we 
won't have to extend it again.

/Daniel
On 2024-03-27 12:15, Peter Birk Pakkenberg wrote:

Hello Blink-dev.

I would like to extend the ‘X-Requested-With in WebView Deprecation’ trial 
until M138 in line with the premise made below in the Summary below. I am 
asking for an extension of 12 milestones instead of the customary 6 
<https://www.chromium.org/blink/launching-features/#deprecation-trial> to 
avoid undue churn for the almost 100 origins that have signed up for the 
trial, as we expect that it will take at least another year to address the 
remaining use cases.

The feature is currently disabled on 5% of stable traffic, and we have 
developed the Android WebView Media Integrity API 
<https://android-developers.googleblog.com/2023/11/increasing-trust-for-embedded-media.html>
 
as a solution for uses of the header for media content providers. We have 
also launched an Android API for app developers to enable the header for 
select origins 
<https://developer.android.com/reference/androidx/webkit/WebSettingsCompat#setRequestedWithHeaderOriginAllowList(android.webkit.WebSettings,java.util.Set%3Cjava.lang.String%3E)>
 
which has been adopted by almost 10k applications so far. This is an 
alternative available to Android apps that only display Web content they 
trust. We are still looking to address further use cases in the anti-abuse 
and anti-fraud space before we can fully disable the header.


Contact emails 

pb...@google.com

Explainer 

None

Specification 

None

Summary 

Removes the default X-Requested-With header from HTTP requests made by 
WebView.

The X-Requested-With header is set by WebView, with the package name of the 
embedding apk as the value. This use of the header will be discontinued.

Developers who rely on this header can sign up for a deprecation origin 
trial [1] to continue to receive the header during the deprecation period.

The deprecation origin trial will be extended until replacement APIs are 
available to address use cases of the header, as explained in this Android 
Developer Blog Post [2]

[1]: https://developer.chrome.com/origintrials/#/view_trial/
1390486384950640641

[2]: https://android-developers.googleblog.com/2023/02/
improving-user-privacy-by-requiring-opt-in-to-send-x-
requested-wih-header-from-webview.html


Blink component 

Mobile>WebView 
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Mobile%3EWebView>

Search tags 

Headers <https://chromestatus.com/features#tags:Headers>

TAG review 

TAG review status 

Not applicable

Chromium Trial Name 

WebViewXRequestedWithDeprecation

Link to origin trial feedback summary 

https://docs.google.com/document/d/e/2PACX-1vR-
ZraJ4sDSGpo2mhye1c2Z1HOl8ZqQ2iDnT2TCQ-Mj1cS1_-2OzN0OeV0Ctayu9Sm6XejgZmwXVDqE
/pub


Origin Trial documentation link 

https://docs.google.com/document/d/e/2PACX-1vSSTEsHVfTXwOW80Tqy4c5TW6wSnt
9b8v7-ZWUF3ZqLDs03EatEuyPCqwaUaa2s0a7mFm3Wh61bgVoz/pub

Risks 

Interoperability and Compatibility 

Gecko: N/A

WebKit: N/A

Web developers: The X-Requested-With header is widely used for both 
anti-fraud and application allowlisting use cases, de

Re: [blink-dev] Intent for Reverse Origin Trial: Media Previews opt-out