[blink-dev] Intent to Ship: CSS Trigonometric functions

[Seokho Song]

Contact emailsseo...@chromium.org

Explainer
https://github.com/DevSDK/css-trigonometric-functions/blob/main/Explainer.md

Specificationhttps://www.w3.org/TR/css-values-4/#trig-funcs

Summary

Add trigonometric functions sin(), cos(), tan(), asin(), acos(), atan(),
atan2() to CSS math expressions.

Resolving relative length on atan2() has tricky problems. So, Using its
double value for now.

FYR: https://crbug.com/1392594 Gecko:
https://bugzilla.mozilla.org/show_bug.cgi?id=1802744 Webkit:
https://bugs.webkit.org/show_bug.cgi?id=248513 CSSWG:
https://github.com/w3c/csswg-drafts/issues/8169


Blink componentBlink>CSS


Search tagscss , trigonometric
function ,
sin , cos
, tan
, asin
, acos
, atan
, atan2


TAG reviewNot required

TAG review statusNot applicable

Risks


Interoperability and Compatibility

This feature will improve web compatibility, as we are adding support for a
feature that WebKit and Gecko already support


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

*WebKit*: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=203311)

*Web developers*: No signals

*Other signals*:

Debuggability

Automatically supported as a CSS feature in DevTools


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

Is this feature fully tested by web-platform-tests

?Yes

Flag nameRequires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1190444

Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1190444

Estimated milestones

111

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPzLR4KH9tBj26wbiAC%3DYhshFDYv66fM9LW-ZuPmeSDrzzxEyg%40mail.gmail.com


This intent message was generated by Chrome Platform Status
.

-- 
Regards,
Seokho

-- 
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/CAPzLR4KB7SX6JbfSG%2BHUVK%2Bo-MaCzPm-XL3E54BP%3DwHx6D2jag%40mail.gmail.com.

[blink-dev] Intent to Ship: Unprefix -webkit-image-set

[Traian Captan]

Contact emailstcap...@chromium.org

ExplainerNone

Specification
https://w3c.github.io/csswg-drafts/css-images-4/#image-set-notation

Summary

Unprefix -webkit-image-set to expose the current image-set functionality
without needing the '-webkit-' prefix.


Blink componentBlink

Motivation

Currently Blink only supports '-webkit-' prefixed image-set, while Gecko
and WebKit support both prefixed and unprefixed versions. With this change
interop with Gecko and WebKit will be increased by allowing web developers
to use the current Blink image-set functionality both with and without the
'-webkit-' prefix.

Search tagsimage-set 

TAG reviewSkipping because this is a straightforward interop fix.

TAG review statusNot applicable

Risks


Interoperability and Compatibility

The Interoperability Risk is Low. This change increases interop with Gecko
and WebKit which already support both '-webkit-' prefixed and unprefixed
image-set. The Compatibility Risk is Low. If both prefixed and standard
versions are defined in the right order, and the standard version fails
parsing, Blink will fallback to the prefixed version. The
'image-set-fallback' test has been added to verify this behavior.


*Gecko*: Shipped/Shipping (
https://hg.mozilla.org/integration/autoland/rev/5c09b1d070e2)

*WebKit*: Shipped/Shipping (https://trac.webkit.org/changeset/202765/webkit)

*Web developers*: Strongly positive - This issue has been Starred by 55
users.

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

No


Debuggability

N/A

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

Is this feature fully tested by web-platform-tests

?Yes
https://wpt.fyi/results/css/css-images/image-set

Flag nameCSSImageSet

Requires code in //chrome?False

Tracking bughttps://crbug.com/630597

Estimated milestones

110 Or 111


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

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/CAFxahvvZZpc5osC5XD_Zu6Lsz5%3Decp7%3DjM0ePgou8UQ-DRPTpQ%40mail.gmail.com.

[blink-dev] PSA: Use Origin header instead of Referer in FedCM requests

['Yi Gu' via blink-dev]

Contact emails

y...@chromium.org

Specification

https://github.com/fedidcg/FedCM/issues/379

Summary

Currently we use “Referer” in the header when sending requests to identity
providers. “Origin” on the other hand, is a more modern concept and its
semantics agree with the value we have. As a result, we decided to use
“Origin” instead during a recent discussion
 with
Safari and Firefox. In particular:

   -

   UA should use Origin instead of Referer for the requests that need to
   expose the RP
   -

   UA should send no Origin (instead of Origin: null) for requests that do
   not expose the RP


Risks

This may break identity providers who have already implemented FedCM API
and had dependency on the “Referer” header. Given that we just shipped
FedCM in M108, the number of implementers is manageable and we have reached
out to them individually to notify the change so there should be no impact
on users.

Blink component

Blink>Identity>FedCM


Debuggability

We are adding WPT tests and unit tests in this patch
.

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1381227

Estimated milestone

M110

-- 
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/CACh2XCNG8u%3D3ZtEuQdVm7BG%2Bk6SHGxmWaFvjOYJwhtStgHvjnA%40mail.gmail.com.

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

['Sahir Vellani' via blink-dev]

Contact emails
bemat...@microsoft.com, 
sahir.vell...@microsoft.com


Explainer
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md


Specification
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md


Summary

As devices with advanced pen input capabilities are becoming increasingly 
prevalent, it is important that the web platform continues to evolve to fully 
support these advanced features in order to unlock rich experiences for both 
end users and developers. One such advancement is the ability for a device's 
digitizer to recognize more than one pen device interacting with it 
simultaneously. This feature is an extension to the PointerEvent interface to 
include a new attribute, deviceId, that represents a session-persistent, 
document isolated, unique identifier that a developer can reliably use to 
identify individual pens interacting with the page.



Blink component
Blink>Input


Motivation

Currently, developers have no way to distinguish between two individual pens on 
an ink-enabled digitizer. The existing PointerEvent.id attribute is implemented 
in different ways and does not always persist for each ink stroke or 
interaction with the screen. Developers can use this change to have a secure 
and reliable way to identify individual pen (pointers) interacting with the 
screen in order to set specific colors or pen shapes for each device 
interacting with the digitizer.



Initial public proposal
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md


TAG review



TAG review status
Pending


Risks
Fingerprinting risks, which will be mitigated by randomizing the ID each 
renderer session.


Interoperability and Compatibility


Gecko: Request for Position: Extending the PointerEvent with Unique DeviceId 
Attribute * Issue #715 * mozilla/standards-positions * 
GitHub

WebKit: Request for Position: Extending the PointerEvent with Unique DeviceId 
Attribute * Issue #102 * WebKit/standards-positions * 
GitHub

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
deviceId will be available via DevTools for front-end debugging.


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


Flag name
PointerEventDeviceId


Requires code in //chrome?
False


Estimated milestones

No milestones specified



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

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/SA0PR00MB1033E5DE0BDE42239E647E9AFB189%40SA0PR00MB1033.namprd00.prod.outlook.com.

Re: [blink-dev] Intent to Ship: Quick intensive timer throttling of loaded background pages

[François Doray]

Hi API owners,

I agree that using a 1 minute grace period (instead of 10 seconds) is less
risky and will likely yield similar resource savings. We'll experiment with
this new grace period and keep you updated with the results.

Side note: Chains of timers on background pages can usually be replaced
with more resource-efficient APIs, see
https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#workarounds.
We think it would be a good thing if, for example, Web content migrated
from polling a server to push Web Sockets in response to tighter
restrictions on timers.

More details below.

Have a nice day,

François

On Wed, Nov 23, 2022 at 12:03 PM Chris Harrelson 
wrote:

> Hi,
>
> The API owners discussed this intent today. In addition to the above
> questions, we achieved consensus that if you were content with 1 minute
> instead of 10 seconds, we'd be prepared to LGTM. For 10 seconds, we have
> additional concerns that would require more discussion and caveats. If 1
> minute achieves your goal of battery savings, could we go with that?
>
Yes we could.


>
> On Wed, Nov 16, 2022 at 5:15 PM Rick Byers  wrote:
>
>> Thinking some more about this, perhaps it really comes down to what the
>> nesting level >5 criteria means in practice? I guess metrics on how common
>> such tasks are won't be helpful because if they weren't common then it
>> wouldn't be attractive for power savings. But do you have anecdotal
>> experience suggesting that user-important events like Daniel and Philip are
>> worried about tend to be a lower nesting level, while things like analytics
>> and ads tracking tends to be higher nesting level? Any idea what data went
>> into the selection of "5" as the threshold?
>>
> For many years, the spec has said that the timeout of a timer with a
nesting level >5 is clamped to be >= 4ms.
https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timers
We used the same criteria to apply intensive throttling.

>
>> It looks like there are other important heuristics too, like timers
>> started in network response handlers aren't subject to throttling. This is
>> clearly pretty nuanced, not something I'd really trust our judgement to be
>> able to accurately evaluate the risk of. Rather than try to speculate on
>> heuristic details here, perhaps it would be more productive to try to align
>> on the principals for how you're evaluating compat risk?
>>
>> In particular, no issue at 50% beta and 1% stable seems like a pretty
>> strong signal to me (especially relative to prior tab freezing efforts).
>> But how confident are you in bugs reaching you? Eg. if a tester bisects
>> based on a customer provided repo, is it likely to point to a CL you
>> landed? Or does this being under finch control mean that a bisect won't
>> work to identify the cause of a regression? I just searched for any bug
>> opened in the last 180 days which mentions setTimeout and setInterval in
>> the summary and didn't find anything relevant, so that's IMHO a significant
>> data point in your favor. Also the example you cite from the previous
>> change looks like it was quickly routed to you, so a good sign.
>>
> I admit that we don't have a perfect process to ensure that bugs are
routed to us. If someone experiences a problem, they could manually disable
features enabled via Finch (listed
at chrome://version/?show-variations-cmd). If they filed a bug with the
experiment name (QuickIntensiveWakeUpThrottlingAfterLoading), we would find
it. But I'm not convinced that most people would do this. We should
probably include clear debug steps in release notes?


>
>> Note I think we avoid 100% trials in beta because that leaves the stable
>> config unvalidated, so topping out at 50% on beta seems right to me. But
>> what's the launch plan after that? Will you go straight to 100% stable and
>> consider backing back down if there are non-trivial reports of breakage? Or
>> do a gradual ramp?
>>
> We definitely want a 1% stable experiment to confirm that this change has
a positive impact. Ramping up to 50% stable gives us more confidence in the
results, but going straight to 100% stable to reduce variations between
Chrome clients also works.


>
>> Reading through the prior example you cited, I suspect the randomness of
>> finch trials could cause some frustration here - eg. some customers
>> complaining of breakage but devs being unable to reproduce it. What would
>> you think about ramping down the timer value predictably rather than
>> gradually ramping up the finch trial? I.e. drop 100% of stable users from 5
>> minutes to 2 minutes first? Perhaps a few weeks at 2 minutes, then 30
>> seconds without issue would be enough to reduce fear of going to 10 seconds
>> while still giving predictability to developers trying to figure out what's
>> going on?
>>
> Gradually reducing the grace period for 100% of stable wouldn't let us
confirm that the intervention has a positive impact. What do you think of
experimenting with the 

Re: [blink-dev] Re: PSA: History Manipulation Intervention

['Shivani Sharma' via blink-dev]

On Mon, Dec 5, 2022 at 9:04 AM Weijar Z  wrote:

> I want to implement the feature  to automatically resume the recently read
> articles when I open the app.
> 1. the user opens the address "pwa.com/"
> 2. App automatically redirects to the last read article "
> pwa.com/articles/1"
> But when the user presses back, the app exits directly and it should go
> back to the article list page.
>
Thanks for raising this! From a user perspective, the browser's back button
not landing on the pwa.com's home page is aligned with their expectation
because the user did not visit the home page. A possible solution is for
pwa.com to have a custom back button inside the app, which when pressed can
invoke history.back() and that will take the user to the app's home page.

>
>
> On Saturday, 29 October 2022 at 03:09:49 UTC+8 shiva...@chromium.org
> wrote:
>
>> Apologies for the delay.
>>
>> 1. history list: [a.com, b.com]. none of the entries are skippable
>> because a.com got a click and b.com hasn't added any new entry yet.
>> 2. [a.com, b.com, b.com/entry1] again no entry should be skippable since
>> b.com got a user interaction.
>> 3. On reload, there should not be any change in the skippable state of
>> the entries as reloads do not interact with the intervention. Can you check
>> at this point if you long press on the back button, does it show b.com
>> or not.
>> 4. I wonder if there is something about the reload that only leads to one
>> b.com entry and therefore pressing the back button navigates to a.com.
>>
>> It would be better to create a crbug
>>  for investigating
>> this and continue any follow up discussions on that.
>>
>>
>> On Wed, Aug 17, 2022 at 7:17 AM eyal sadeh  wrote:
>>
>>> Hello!
>>> I experience a use case where this intervention hurts user-experience,
>>> would love to hear your thoughts:
>>> 1. User is on a.com and clicks to go to b.com (Single Page Application).
>>> 2. The user interacts with the page, and a new history entry is created
>>> using pushState.
>>> 3. The user press the reload button (alternatively, in Android,
>>> sometimes the page reloads automatically).
>>> 4. The user press the back button, b.com is skipped, popstate event
>>> isn't triggered, and the user is being navigated to a.com.
>>>
>>> I feel this use case is valid and b.com shouldn't be skipped. I'd
>>> suggest to skip states only if added during the current session.
>>>
>>> Thanks in advance,
>>> Eyal
>>>
>>> On Monday, June 7, 2021 at 7:40:03 PM UTC+3 mmo...@google.com wrote:
>>>
 Hello!

 It sounds to me like requesting that Navigations initiated from
 Notification handlers be treated as a user-gesture-initiated would be
 enough to make this use case work correctly.  Filed: crbug.com/1217190 if
 that is true.

 (The fact that you use history.replace first here likely should not
 affect the situation.  So long as the subsequent history.push is treated as
 gesture-initiated you should get the back button behaviour you ask for.)

 -Michal

 On Mon, Jun 7, 2021 at 11:11 AM Andrea Puddu  wrote:

> Hello,
>
> This "intervention" by Chrome is breaking a valid use case in our app
> (Progressive Web App).
>
> Specifically:
> - users click on a push notification (the app is in background)
> - notifications open a link, which is e.g. 
> *https://example.app/pwa?noticationId=12345
> *
> - the PWA opens, it fetches the event associated from the
> *notificationId*, and redirect to the corresponding view
> - when users hit the back button we don't want the PWA to be closed
> immediately: it must redirect to the "home" first
>
> To do so, in the notification handler we do:
> *history.replace(homeURL);*
> * history.push(eventURL);*
>
> Note that this works perfectly fine in Safari, Firefox, etc. because
> well, it's just using standard APIs. Moreover, this is widely used pattern
> in native apps: when you click a notification it opens the app, but if you
> hit the "back button" in Android where does it goes? At the app "home",
> indeed.
>
> This is not pretending to hurt anyone, in fact it is done to improve
> user's experience.
>
> I'm sorry but you need to improve your "intervention" heuristics, you
> can't break arbitrary apps out there. And this is a B2B app, not a scam
> website.
>
> Thanks,
> -Andrea
>
> El jueves, 16 de mayo de 2019 a las 17:33:36 UTC+2,
> shiva...@chromium.org escribió:
>
>> (Response inline below.)
>>
>> On Tue, May 14, 2019 at 12:21 PM  wrote:
>>
>>> How would this affect SPA websites that use push.history to allow
>>> navigation?
>>> Could you please clarify what could be the user's gesture?
>>> Thanks ahead,
>>> Lior
>>>
>>
>> As long as there is a user 

Re: [blink-dev] Re: PSA: History Manipulation Intervention

[Weijar Z]

I want to implement the feature  to automatically resume the recently read 
articles when I open the app.
1. the user opens the address "pwa.com/"
2. App automatically redirects to the last read article "pwa.com/articles/1"
But when the user presses back, the app exits directly and it should go 
back to the article list page.


On Saturday, 29 October 2022 at 03:09:49 UTC+8 shiva...@chromium.org wrote:

> Apologies for the delay.
>
> 1. history list: [a.com, b.com]. none of the entries are skippable 
> because a.com got a click and b.com hasn't added any new entry yet.
> 2. [a.com, b.com, b.com/entry1] again no entry should be skippable since 
> b.com got a user interaction. 
> 3. On reload, there should not be any change in the skippable state of the 
> entries as reloads do not interact with the intervention. Can you check at 
> this point if you long press on the back button, does it show b.com or 
> not.
> 4. I wonder if there is something about the reload that only leads to one 
> b.com entry and therefore pressing the back button navigates to a.com.
>
> It would be better to create a crbug 
>  for investigating 
> this and continue any follow up discussions on that.
>
>
> On Wed, Aug 17, 2022 at 7:17 AM eyal sadeh  wrote:
>
>> Hello!
>> I experience a use case where this intervention hurts user-experience, 
>> would love to hear your thoughts:
>> 1. User is on a.com and clicks to go to b.com (Single Page Application).
>> 2. The user interacts with the page, and a new history entry is created 
>> using pushState.
>> 3. The user press the reload button (alternatively, in Android, sometimes 
>> the page reloads automatically).
>> 4. The user press the back button, b.com is skipped, popstate event 
>> isn't triggered, and the user is being navigated to a.com.
>>
>> I feel this use case is valid and b.com shouldn't be skipped. I'd 
>> suggest to skip states only if added during the current session.
>>
>> Thanks in advance,
>> Eyal
>>
>> On Monday, June 7, 2021 at 7:40:03 PM UTC+3 mmo...@google.com wrote:
>>
>>> Hello!
>>>
>>> It sounds to me like requesting that Navigations initiated from 
>>> Notification handlers be treated as a user-gesture-initiated would be 
>>> enough to make this use case work correctly.  Filed: crbug.com/1217190 if 
>>> that is true.
>>>
>>> (The fact that you use history.replace first here likely should not 
>>> affect the situation.  So long as the subsequent history.push is treated as 
>>> gesture-initiated you should get the back button behaviour you ask for.)
>>>
>>> -Michal
>>>
>>> On Mon, Jun 7, 2021 at 11:11 AM Andrea Puddu  wrote:
>>>
 Hello,

 This "intervention" by Chrome is breaking a valid use case in our app 
 (Progressive Web App). 

 Specifically:
 - users click on a push notification (the app is in background)
 - notifications open a link, which is e.g. 
 *https://example.app/pwa?noticationId=12345 
 *
 - the PWA opens, it fetches the event associated from the 
 *notificationId*, and redirect to the corresponding view
 - when users hit the back button we don't want the PWA to be closed 
 immediately: it must redirect to the "home" first

 To do so, in the notification handler we do:
 *history.replace(homeURL);*
 * history.push(eventURL);*

 Note that this works perfectly fine in Safari, Firefox, etc. because 
 well, it's just using standard APIs. Moreover, this is widely used pattern 
 in native apps: when you click a notification it opens the app, but if you 
 hit the "back button" in Android where does it goes? At the app "home", 
 indeed. 

 This is not pretending to hurt anyone, in fact it is done to improve 
 user's experience. 

 I'm sorry but you need to improve your "intervention" heuristics, you 
 can't break arbitrary apps out there. And this is a B2B app, not a scam 
 website.

 Thanks,
 -Andrea

 El jueves, 16 de mayo de 2019 a las 17:33:36 UTC+2, 
 shiva...@chromium.org escribió:

> (Response inline below.)
>
> On Tue, May 14, 2019 at 12:21 PM  wrote:
>
>> How would this affect SPA websites that use push.history to allow 
>> navigation?
>> Could you please clarify what could be the user's gesture?
>> Thanks ahead,
>> Lior
>>
>  
> As long as there is a user gesture on the document either before or 
> after history.pushState, the intervention would not happen.
> User gesture are actions like click (spec 
> , 
> Chrome's 
> article about user activation 
> ). 
>
>>
>> On Tuesday, May 7, 2019 at 10:08:04 PM UTC+3, Shivani Sharma wrote:
>>>
>>> (This intervention has been reviewed and 

[blink-dev] Re: Intent to Ship: Origin Isolation By Default / Deprecate document.domain on stable

[Yaseen Khan]

Hi Daniel,

Need clarifications for the below points. 

Activation - Deprecation plan
M109: Enable "Origin Agent Cluster by Default" for 50% of page loads on 
beta, dev, and canary. 
--- As a developer, do I need to set  "Origin-Agent-Cluster: ?1" as a 
header for 50% of page visits or chromium enforcing for 50% of page visits 
from browser(Means 50% ( "Origin-Agent-Cluster: ?1")  and another 50% ( 
"Origin-Agent-Cluster: 
?0")?. 

I have installed M109 beta and I have not set orginAgentCluster in my site 
and I can see in console "*window.originAgentCluster*" always return false 
for all sites/pages. Could you clarify on this?. How do I know 
whether Origin-Agent-Cluster enabled or not in M109?


On Thursday, 27 October 2022 at 20:19:44 UTC+5:30 Daniel Vogelheim wrote:

> Hello all,
>
> The approval for the Intent To Ship for Origin Isolation By Default / 
> Deprecate document.domain 
>  
> asks for a separate intent for the actual default change 
> .
>  
> This is that separate intent.
>
> A summary of what happened so far:
>
> - Shipping Origin Isolation by Default (and thereby deprecating 
> document.domain) has security benefits, but compatibility risk.
>
> - We added warnings to the developer console and issues panel, published a 
> blog post, and engaged in direct outreach. This has resulted in 
> substantial, measurable reduction of usage. Some sites keep using 
> document.domain, but have mitigated the deprecation with other means. This 
> makes the risk difficult to measure.
>
> - Sampling of sites with document.domain usage and manual inspection 
> yields a potential breakage estimate at ~0.015% of page views.
>
> What we're asking for here is:
>
> - Enable the feature at 50% for beta (+ dev + canary) during M109, as a 
> "last call" for web site authors.
>
> - Launch on stable on M110. (~ Feb '23, so >12 weeks out from today)
>
>
> 
>
> Contact emailsva...@chromium.org, voge...@chromium.org
> SpecificationExplainer: 
> https://github.com/mikewest/deprecating-document-domainHTML Spec draft: 
> https://github.com/whatwg/html/compare/main...otherdaniel:dd
> API specYes
> Summary
>
> This is a follow-on to the Intent to Ship: Origin Isolation By Default / 
> Deprecate document.domain 
> . We'd 
> like to ship this in M110, stable.
>
> Summary (of the underlying change)Change the default behavior of the 
> Origin-Agent-Cluster: header / document.domain settability.
> Presently, pages within Chromium have site-keyed agent clusters by 
> default, unless the Origin-Agent-Cluster: header is explicitly set to true. 
> This accommodates pages or frames which want to access each other's state, 
> despite being on different origins (but within a site). This is fine for 
> any pages that wish to do so, but because a page *might* set 
> document.domain later on, Chromium currently must use site-keyed agent 
> clusters for *all* pages by default even though the overwhelming majority 
> of pages do not ever make use of this (mis-)feature. In turn, this requires 
> Chromium to use sites as the basis for renderer process isolation (via Site 
> Isolation), which exposes origins to same-site but cross-origin attacks 
> involving compromised renderer processes or the "Spectre" family of 
> side-channel attacks.
> This proposal changes the default behaviour of Origin-Agent-Cluster. From 
> a developer's point of view, the new default matches "Origin-Agent-Cluster: 
> ?1". The initial implementation will use origin-keyed agent clusters for 
> all (non-opted out) origins, without changing how many processes Chromium 
> creates. Over time, we can then adapt Chromium's isolation strategy towards 
> origin-keyed processes without further affecting web-visible behaviour.
> The developer-visible aspect of this is that for pages with origin-keyed 
> agent clusters, document.domain is no longer settable. Thus, we have marked 
> this intent as a deprecation.
> Note that this proposal is about the default. Both modes - site-keyed or 
> origin-keyed agent clusters - remain available to any site, but 
> origin-keyed agent clusters change from opt-in to opt-out. The current 
> behaviour remains available by setting "Origin-Agent-Cluster: ?0".
> Blink componentBlink>SecurityFeature
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/564
> Risks: Interoperability and Compatibility
>
> There are compatibility risks, which we have reduced with outreach and 
> warnings, and we want to mitigate further by launching at 50% of beta 
> first. An extended discussion of the risk (including attempts at 
> quantitative assessment) can be found in the original intent to ship 
> .
>
> Gecko: Standards position request 
> 

Re: [blink-dev] Intent to Experiment: Reduce Accept-Language Origin Trial

[Victor Tan]

A blog post just went out for this Origin Trial: 
https://developer.chrome.com/blog/origin-trial-for-accept-language-reduction/


On Tuesday, November 1, 2022 at 5:19:08 PM UTC-4 Victor Tan wrote:

> Hi Jeffrey,
> Thanks for your information. I updated the Chrome Status entry to 
> correctly represent current status. 
> I will work on spec and migrate the explainer to CG if needed. 
>
> Bests,
> Victor
>
> On Tue, Nov 1, 2022 at 2:26 PM Jeffrey Yasskin  
> wrote:
>
>> I see that your Chrome Status entry 
>>  says 
>> "Specification being incubated in a Community Group", but your explainer is 
>> not hosted by a CG, and the specification you cite is 1) in a WG and 2) not 
>> the specification you'll need to write for this to be a web feature. Could 
>> you work on migrating this to a CG? And now that you've started an origin 
>> trial, it's also time to start working on your web-side specification, 
>> which will probably eventually merge into Fetch 
>> . Let me or your spec 
>> mentor  
>> know if you need help with that.
>>
>> Thanks,
>> Jeffrey
>>
>> On Thu, Oct 27, 2022 at 10:57 AM Victor Tan  
>> wrote:
>>
>>> Contact emails
>>>
>>> victor...@chromium.org, miketa...@chromium.org 
>>>
>>> Explainer
>>>
>>> https://github.com/Tanych/accept-language
>>>
>>> Specification
>>>
>>> Variants header: 
>>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>>>
>>> Summary
>>>
>>> We want to reduce the amount of information the Accept-Language header 
>>> exposes in HTTP requests and JS interface navigator.languages. Instead of 
>>> sending all user’s Accept-Language, we only send the user’s most preferred 
>>> language after language negotiation in the Accept-Language header. 
>>> navigator.languages returns the same value as navigator.language during 
>>> this experiment. 
>>>
>>> We would like to run an origin trial for sites to opt into the Reduce 
>>> Accept-Language origin trial to proactively test for breakage. See below 
>>> for more details. 
>>>
>>> Implementation Doc
>>>
>>> https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY
>>>
>>> Blink component
>>>
>>> Privacy>Fingerprinting 
>>> 
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> The compatibility risk is low since we're planning to reduce the amount 
>>> of information in the Accept-Language header and navigator.languages, 
>>> rather than remove the header or change value format in the header. Most 
>>> existing Accept-Language detection code should continue to work. 
>>>
>>> As for interoperability, no signal for other vendors. For multilingual 
>>> sites to rely on the Accept-Language header, developers would need to 
>>> depend on a user's full Accept-Language list for some browsers and a 
>>> primary user's Accept-Language for others. 
>>>
>>> Another signal is that the Chrome incognito model already reduced the 
>>> Accept-Language header and JS interface navigator.languages to one 
>>> language. The Accept-Language header can potentially expand to two if the 
>>> first Accept-Language includes a region code, like en-US, the reduced 
>>> Accept-Language  header will be en-US,en;q=0.9. 
>>>
>>> Experiment Summary
>>>
>>> The experiment is going to be a little different from a normal Origin 
>>> Trial. The goal is enabling developers to test and ensure compatibility 
>>> with our proposed changes. It’s incredibly important we give developers any 
>>> chance to test systems at every level since this change represents vast 
>>> dependencies on the introduced headers. 
>>>
>>> As for enabling with the origin trial itself, there will be two 
>>> components controlled by the same origin trial:
>>>
>>>- 
>>>
>>>Reducing the information in navigator.languages if the origin trial 
>>>enabled.
>>>- 
>>>
>>>The Accept-Language HTTP request header contains the user’s primary 
>>>preferred language, this can change if we detect a more preferred 
>>> language 
>>>during the language negotiation process. 
>>>
>>> Because of the experimental nature of reducing Accept-Language, a valid 
>>> origin token must be sent in the response header by origins which opt-in 
>>> the origin trial. Also two new headers Variants 
>>> 
>>>  
>>> (indicating sites supporting languages) accept-language and 
>>> Content-Language  need 
>>> to be sent in the response header in order to make the language negotiation 
>>> to work correctly.
>>>
>>> Please see the design and implementation document 
>>> 

Re: [blink-dev] Intent to Implement and Ship: Unprefixed -webkit-image-set

[Manuel Rego Casasnovas]

Given the answer, I agree with Yoav that it'd be better to forget about
this thread and start a new one when things are ready to ship.

Thanks,
  Rego

On 02/12/2022 22:09, Traian Captan wrote:
> Hi Rego,
> 
> Thank you for your message!
> 
> > This issue has been bugging devs since 2016.
> >
> > I'm landing a patch
> >  > to
> > unprefix -webkit-image-set which will expose the current image-set
> > functionality without needing the '-webkit-' prefix.
> I don't think this is the right way to move this topic. 3 LGTMs from
> 2016 shouldn't be enough to land the change without a previous notice on
> this thread. 
> 
> Sorry about that, it was meant more as an FYI on the old thread since
> there was no follow up after the LGTMs and the issue is still open.
> I will create a new Chrome status entry and send out a brand new email
> about it.
> 
>  
> 
> > To address the compat issue, if both prefixed and standard versions are
> > defined in the right order,
> > and the standard version fails parsing, Chrome will fallback to the
> > prefixed version.
> > The `image-set-fallback` test has been added to verify this behavior.
> > Unprefixing image-set fixes 2 of the failing subtests of the
> > image-set-parsing WPT test 
> > 
>   
> >
> >
> > As a follow up, I will investigate whether we can fix the remaining
> > compat issues.
> 
> How is the interop with WebKit and Firefox implementations?
> According to MDN Firefox added support for -webkit-image-set() in
> version 90, so it'd be nice that this change is in alignment too.
> 
> WebKit and Firefox support both prefixed and unprefixed versions.
> I am not removing the prefixed version, only adding the possibility of
> using the current functionality without needing the `-webkit-` prefix.
> 
>  
> 
> What's the status of WPT tests? Why only 2 subtests are getting fixed
> with this change? Are there plans to fix the rest?
> 
> For the image-set-parsing test, Firefox is passing 46/50, Safari 37/50
> and Chrome 20/50 (22 with my patch).
> For the overall WPT tests for image-set
> ,
>  Firefox is passing 71/77, Safari 50/77 and Chrome 23/77 (25 with my patch).
> We only pass 2 more tests because we are only exposing the current
> implemented functionality not adding any new functionality with this patch.
> I will follow up with additional fixes for some of the other issues.
>  
> 
> Do we have use counters for both the prefixed and uprefixed versions to
> see if we can get rid of them in the future?
> 
> Yes, we have counters for both, but I don't think we can get rid of the
> prefixed version, as there were talks about adding the prefixed version
> to the spec: https://github.com/w3c/csswg-drafts/issues/6285
> 
> 
> I guess we should also update things at:
> https://chromestatus.com/feature/5432024223449088
> 
> 
> I'll send a brand new one.
>  
> 
> And probably notify MDN so it can get updated if the prefix is no longer
> needed in any browser.
> 
> Good idea.
> 
> Regards,
> Traian
> 
> 
> On Wed, Nov 30, 2022 at 11:57 PM Manuel Rego Casasnovas  > wrote:
> 
> Hi,
> 
> On 01/12/2022 00:59, Traian Captan wrote:
> > This issue has been bugging devs since 2016.
> >
> > I'm landing a patch
> >  > to
> > unprefix -webkit-image-set which will expose the current image-set
> > functionality without needing the '-webkit-' prefix.
> I don't think this is the right way to move this topic. 3 LGTMs from
> 2016 shouldn't be enough to land the change without a previous notice on
> this thread.
> 
> > To address the compat issue, if both prefixed and standard
> versions are
> > defined in the right order,
> > and the standard version fails parsing, Chrome will fallback to the
> > prefixed version.
> > The `image-set-fallback` test has been added to verify this behavior.
> > Unprefixing image-set fixes 2 of the failing subtests of the
> > image-set-parsing WPT test 
> >
> 
>   
>