Re: [blink-dev] Re: Ready for Trial: Quick intensive timer throttling of loaded background pages

[François Doray]

Hi Mike,

With 1 week of ramped up data of stable, we know that this intervention
reduces overall CPU usage from Chrome by a few (single-digit) percents on
all desktop platforms. On ChromeOS, this reduces jank (it's typical for
CPU-reduction experiments to reduce jank on ChromeOS, due to tight resource
constraints). On Mac, it extends battery life. There is no regression for
any guiding metric.

We're hoping to experiment on 50% Stable to get more clarity on the battery
life impact. It's important to get this data to prioritize future
investments. Confidence intervals for battery discharge rate are wide with
7-days of 1% stable experiment. For other CPU reduction experiments,
ramping up to 50% Stable was the fastest way to obtain smaller confidence
intervals.

Do you recommend sending an "Intent to Ship" asking to ramp up gradually:
1% -> 50% -> 100%?

François

On Thu, Nov 3, 2022 at 8:32 AM Mike West  wrote:

> Hey Jiahe,
>
> Can you summarize what you've learned from the 1% experiment? The design
> doc isn't exactly clear on what y'all would consider "success" from an
> experimental perspective, so I'd like to understand what you're evaluating.
>
> I'm also curious about the hop from 1% to 50%. What do you expect to learn
> from the 50:50 experiment that you're not learning from the 1%? We often do
> incremental rollouts, ramping from 1% to 5% to 10% and so on, but I think
> you could do that as part of an Intent to Ship, rather than extending this
> experiment.
>
> -mike
>
>
> On Thu, Nov 3, 2022 at 11:57 AM Jiahe Zhang  wrote:
>
>> We've been experimenting this on 1% Stable on M107 for weeks , and the
>> results are quite encouraging.
>> So I'd like to request a larger scope of experiments to 50% Stable.
>> Please review.
>>
>> Best Regards,
>> Jiahe
>>
>> On Tuesday, October 4, 2022 at 4:45:42 AM UTC+8 François Doray wrote:
>>
>>> Update: We ended up experimenting with M106+, because there was a bug in
>>> the code in prior versions. The M106 Beta experiment has good results.
>>> We'll start the 1% Stable experiment this week.
>>>
>>> On Tue, Aug 9, 2022 at 9:47 AM François Doray  wrote:
>>>
 Thanks! I started the 1% Stable experiment. I will share an overview of
 the results in ~3 weeks.

 On Tue, Aug 9, 2022 at 4:21 AM Mike West  wrote:

> IMO, this is somewhere on the border between a web-visible experiment
> and a pure expression of user agent preference regarding flexibility
> explicitly carved out in a standard.
>
> Rather than debating the feature's philosophical state, I'd simply
> treat this email as an Intent to Experiment from M104 (current stable) to
> M107, and give you an explicit LGTM.
>
> Additionally: it would be ideal for the experience you gather in this
> experiment to fold back into the spec as an "Implementation Consideration"
> that might help other implementers determine how to use the flexibility 
> the
> spec provides.
>
> -mike
>
>
> On Fri, Aug 5, 2022 at 9:24 PM 'François Doray' via blink-dev <
> blin...@chromium.org> wrote:
>
>> +Scott Haseley as an expert in this field.
>>
>> We would like to start experimenting with this intervention on 1%
>> Stable very soon. We've been experimenting on 50% of Beta for almost 2
>> months. The results are encouraging and we aren't aware of negative Web
>> developer feedback. Do we need your LGTM to proceed?
>>
>> On Mon, Aug 1, 2022 at 3:45 AM Zhang, Jiahe 
>> wrote:
>>
>>> Contact emails
>>>
>>> jiahe...@intel.com, fdo...@chromium.org
>>>
>>>
>>> Specification
>>>
>>> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html
>>>
>>>
>>> Design docs
>>>
>>>
>>>
>>> https://docs.google.com/document/d/1WFyfKUUxqM7uKxKOGhLiOjyY6T7QRduVcuHN0f6vJkk/edit
>>>
>>>
>>> Summary
>>>
>>> Enter Intensive Wake Up throttling after 10 seconds if the page is
>>> fully loaded when it becomes hidden. Currently, wake ups from JS timers
>>> with a nesting level >= 5 are throttled to 1 per minute after the page 
>>> has
>>> spent 5 minutes in the background [1], which is very conservative and 
>>> was
>>> chosen to allow a launch of Intensive Wake Up Throttling with minimal
>>> regression risk. We're now planning to reduce this timeout to 10 
>>> seconds if
>>> the page is fully loaded when hidden. [1]
>>> https://chromestatus.com/feature/4718288976216064
>>>
>>>
>>>
>>> Blink component
>>>
>>> Blink>Scheduling
>>> 
>>>
>>>
>>> TAG review
>>>
>>> Not applicable. This feature changes the behavior of an existing
>>> API, while remaining spec-compliant ("Optionally, wait a further
>>> implementation-defined length of time.
>>> 

Re: [blink-dev] Re: FYI Privacy Sandbox Ads APIs origin trial

[Josh Karlin]

We are continuing to increase the Privacy Sandbox Relevance and Measurement
origin trial population:

   - Attribution Reporting and Topics API's availability has increased to
   5% of Chrome Stable users.
   - FLEDGE and Fenced Frames are on schedule to increase to 5% starting on
   the 9th of November.
   - Shared Storage’s selectURL API will also begin ramping up to 1% of
   Chrome Stable users on the 9th of November.

We will continue to post updates as we progress and, as always, you can
find overall developer guidance on
https://developer.chrome.com/docs/privacy-sandbox/unified-origin-trial/.
You can sign up to the origin trial on
https://developer.chrome.com/origintrials/#/view_trial/771241436187197441.

Josh

On Mon, Oct 24, 2022 at 12:08 PM Josh Karlin  wrote:

> This week, no sooner than October 26, we will begin increasing the Privacy
> Sandbox Relevance and Measurement origin trial population towards 5% of
> Chrome Stable users for Attribution Reporting and Topics APIs. You can
> expect to see traffic levels increase over a period of a few days.
> Pre-stable channels, Canary and Beta, will continue as is with a 50/50
> split for origin trial eligibility.
>
> FLEDGE and Fenced Frames will increase to 5% starting on the 9th of
> November.
>
> We will continue updating this thread as we proceed with these changes and
> there will be a matching blog post live shortly. You can also find more
> information on managing your participation in the origin trial in our
> developer documentation.
>
> Josh
>
> https://developer.chrome.com/docs/privacy-sandbox/unified-origin-trial/
> https://developer.chrome.com/blog/
>
>
> On Tue, Oct 18, 2022 at 4:19 PM Josh Karlin  wrote:
>
>> Correction, the Private Aggregation API is available in canary/dev.
>>
>> Josh
>>
>> On Tue, Oct 18, 2022 at 4:15 PM Josh Karlin  wrote:
>>
>>> Hey folks. The Private Aggregation API
>>>  is
>>> now available within Shared Storage and FLEDGE worklets on canary/dev/beta
>>> at 50%.
>>>
>>> Best,
>>>
>>> Josh
>>>
>>> On Wed, Sep 21, 2022 at 11:59 AM Paul Jensen 
>>> wrote:
>>>
 Hi folks. In regards to the FLEDGE bug and subsequent ramp down of
 FLEDGE for Chrome Stable, I wanted to bring your attention to a post
 from the FLEDGE API Announce list yesterday
 
  that
 impacts experimenters:

 "We fixed the bug and are ramping the origin trial back up on desktop
 and Android, to make FLEDGE available for 1% of Stable users, on pages that
 provide a valid trial token, as the Topics and Attribution Reporting APIs
 are now."

 Paul

 On Friday, September 9, 2022 at 3:01:55 PM UTC-4 Josh Karlin wrote:

> Topics, Fenced Frames, and Attribution Reporting are now ramping up to
> 1% on Android stable.
>
> Josh
>
> On Thu, Sep 1, 2022 at 2:01 PM Josh Karlin 
> wrote:
>
>> Hi folks. I wanted to bring your attention to a post from FLEDGE API
>> Announce
>> 
>> list today that impacts experimenters:
>>
>> "We've discovered a bug in FLEDGE, so we are ramping down FLEDGE for
>> Chrome Stable in the Privacy Sandbox Relevance and Measurement
>> origin trial
>> .
>> Other APIs in the trial are unaffected.
>>
>> We've identified a fix for the bug and are working to validate it and
>> re-enable the origin trial for FLEDGE with the fix soon (roughly two 
>> weeks
>> from now if all goes well)."
>>
>> Best,
>>
>> Josh
>>
>> On Wed, Aug 24, 2022 at 8:29 AM Josh Karlin 
>> wrote:
>>
>>> Hey folks. Shared Storage's
>>>  
>>> selectURL()
>>> operation will begin to ramp up on canary/dev/beta in the next 24 hours 
>>> at
>>> 50%. Aggregate reporting is forthcoming.
>>>
>>> Best,
>>>
>>> Josh
>>>
>>> On Thu, Aug 11, 2022 at 11:39 AM Josh Karlin 
>>> wrote:
>>>
 We've been asked if canary/dev/beta will continue to hold at 50%
 while stable is at 1%. Yes, the pre-stable channels will continue at 
 50%.

 On Wed, Aug 10, 2022 at 5:45 PM Josh Karlin 
 wrote:

> I should clarify that this stable push to m104 is for desktop
> only. Mobile is coming later.
>
> On Wed, Aug 10, 2022, 1:35 PM Josh Karlin 
> wrote:
>
>> The unified origin trial will start ramping up to 1% of M104
>> Stable traffic tomorrow, August 11th.
>>
>> On Fri, Jun 3, 2022 at 1:22 PM Josh Karlin 
>> wrote:
>>
>>> 

Re: [blink-dev] Intent to Prototype: scheduler.yield()

[Rick Byers]

Thanks Scott! I'm excited to see this moving forward and hopeful that
providing more modern scheduling primitives to sophisticated websites and
frameworks will help some of them create a more consistently good user
experience.

Rick

On Fri, Oct 28, 2022 at 5:57 PM Scott Haseley  wrote:

> Contact emailsshase...@chromium.org
>
> Explainer
> https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md
>
> Specification
>
> Summary
>
> Provides a method for yielding control to the browser, which can be used
> to break up long tasks. Awaiting the promise returned by scheduler.yield()
> causes the current task to yield, continuing in a new browser task. This
> can be used to improve responsiveness issues caused by long tasks.
> Continuations are prioritized to mitigate performance problems of existing
> alternatives.
>
>
> Blink componentBlink>Scheduling>APIs
> 
>
> Motivation
>
> Long tasks (JavaScript) can lead to poor responsiveness by blocking the
> main thread from handling inputs or delaying the resulting UI update.
> Developers can mitigate this by decreasing task lengths, either by doing
> less work or by breaking up long tasks. Scheduling a continuation using
> current APIs typically has poor ergonomics because intuitively one wants to
> pause/resume the current task, not schedule a new task. It can also incur a
> performance penalty if arbitrary JavaScript runs between yield and
> continuation. scheduler.yield() is an ergonomic API for breaking up long
> tasks that mitigates performance issues of existing methods. Developers can
> await scheduler.yield() to break up long tasks, giving the UA an
> opportunity to run higher priority work, e.g. input. scheduler.yield()
> continuations are prioritized over tasks of the same priority or similar
> task sources, which helps mitigate the performance penalty of yielding.
>
>
> Initial public proposal
>
> TAG review
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> *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?
>
>
>
> Debuggability
>
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> Flag name
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=979020
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/6266249336586240
>
> 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/CAKXGoJ1SBQP-ABM3%2BsDtKzUZiPoSCWqW2mLOjMrUfFBx4TomSw%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/CAFUtAY8PifiWnfMSuTy19NL7EkZqfGwxy-%2Bq0-fp%3DDnsLY5Gbw%40mail.gmail.com.

Re: [blink-dev] Intent to Experiment: Dark mode support for web apps v2

[Rick Byers]

Sorry, I missed that Chris already approved this in a duplicate thread:
https://groups.google.com/a/chromium.org/g/blink-dev/c/WqIBRabU3C0

On Fri, Nov 4, 2022 at 10:46 AM Rick Byers  wrote:

>
> On Fri, Nov 4, 2022 at 2:24 AM 'Louise Brett' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emailsloubr...@google.com, glen...@chromium.org,
>> mgi...@chromium.org
>>
>> Explainer
>> V1:
>> https://github.com/WICG/manifest-incubations/blob/gh-pages/user-preferences-explainer.md
>> V2: https://github.com/w3c/manifest/issues/1045
>>
>> Specification
>>
>> Summary
>>
>> Add a field to the web app manifest which allows apps to specify a
>> different theme color and background color for dark mode.
>>
>>
>> Blink componentBlink>AppManifest
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/696
>>
>> TAG review statusPending
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>>
>> *Gecko*: No signal (
>> https://github.com/mozilla/standards-positions/issues/630)
>>
>> *WebKit*: Positive (https://github.com/w3c/manifest/issues/1045)
>>
>
> Note that to minimize risk of misunderstandings, only official WebKit
> standards position entries count as positive signals
> .
> It's not necessary for OT, but probably a good idea to get a position
> request filed  ahead of a
> future I2S.
>
> *Web developers*: No signals - Positive signals from v1 but no signals on
>> the new format
>>
>> *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?
>>
>>
>>
>> Goals for experimentation
>>
>> Allow web developers to use this field and provide feedback on the new
>> format.
>>
>>
>> Reason this experiment is being extended
>>
>> The manifest format has significantly changed per
>> https://github.com/w3c/manifest/issues/1045 to use CSS media queries. We
>> would like to run a new OT to get feedback from web developers about this
>> new format.
>>
>
> Switching to CSS MQ syntax is indeed a pretty significant change. LGTM to
> experiment M109-M114
>
> Ongoing technical constraints
>>
>>
>>
>> Debuggability
>>
>> chrome://web-app-internals can be used for debugging, and this has been
>> added to the DevTools Application pane.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?No
>>
>> Not supported on Android
>>
>
> Has there been discussion with Android folks? Eg. +Glenn Hartmann
> ? Ideally we'd ship support for all OSes at the
> same time, but at a minimum we'll want to make sure the design we ship for
> desktop is also reasonable for mobile in the future.
>
> Is this feature fully tested by web-platform-tests
>> 
>> ?No - the v2 format does not have web platform tests yet.
>>
>> Flag namechrome://flags/#enable-experimental-web-platform-features
>>
>> Requires code in //chrome?True
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1318305
>>
>> Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1279284
>>
>> Estimated milestones
>> OriginTrial desktop last 114
>> OriginTrial desktop first 109
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5714780426862592
>>
>> Links to previous Intent discussionsIntent to prototype:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/Y6zNtG0f-6A
>> Intent to Experiment v1:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/ftoKq32Baz4
>> Intent to Extend Experiment v1:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/2c8msRrrcF0
>>
>>
>> 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/CABeVxY1nHwDDrShzu4m-RM%2B6UhM7Lp%2BB-TywkUfBrGEO3WPkSg%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 Deprecate and Remove: Private Network Access requests for subresources without proper preflight response

[Rick Byers]

On Wed, Nov 2, 2022 at 12:05 PM 'Titouan Rigoudy' via blink-dev <
blink-dev@chromium.org> wrote:

> Hi all,
>
> Thanks for your patience, I was travelling last week, then out for a
> couple days, and was unable to spend much time on this until now.
>
> On Wed, Oct 12, 2022 at 6:35 PM Titouan Rigoudy 
> wrote:
>
>> Thanks for getting back to us!
>>
>> On Wed, Oct 12, 2022 at 6:11 PM Daniel Bratell 
>> wrote:
>>
>>> We (Yoav, Philip, MikeT and I) discussed this at the API OWNERS meeting
>>> today and we are still not certain about the compatibility situation. The
>>> use counters are lower after compensating for likely malicious usage but
>>> they are still not quite as low as we'd like them to be.
>>>
>>> One thing we considered was whether the data you analyzed is
>>> representative for all platforms or whether Android is different in some
>>> way. We don't know. Do you know? If not, could you take a look at the
>>> Desktop data and check that it's the same pattern as for Android?
>>>
>> It's a good question! I'll take a look and see what I can tell from the
>> data.
>>
>
> The data on Desktop suggests that most usage is legitimate. ChromeOS usage
> is dominated by educational websites: school districts and the like. This
> could be driven by large providers like Clever or VPN usage. On Windows and
> Mac we mostly see intranet-looking websites (CRMs, portals). On Linux, we
> see some of the former and mostly the latter.
>
> On desktop platforms in general, the UseCounter indicates ~0.1% (Linux,
> ChromeOS) to ~0.2% (Windows, MacOS) of page visits are affected.
>
> If that's too much, we could consider shipping on Android first, where our
> previous analysis suggests the impact is an order of magnitude lower. We
> could also ship on desktop to beta only for a few milestones, in order to
> give websites more time to notice the change.
>

Yikes, that sure sounds like a huge amount of breakage, and so not
something likely to survive a launch (partner escalations, negative press,
etc.).  In fact that seems suspiciously high to me. You're saying that one
in 500 public Internet pages loaded on Windows has a legitimate need to
load a sub-resource from a private IP space? That's a HUGE
amount, hopefully it's over-counting somehow by a few orders of magnitude
:-)

In terms of risk reduction, launching first on Android is one option, but
that sounds like it still has a non-trivial level of risk too. Here's a few
other ideas to possibly help form a pragmatic launch strategy (mostly drawn
from experience captured in bit.ly/blink-compat).

   - Survey some of the legitimate looking cases in the data and see if you
   can reproduce the breakage. How severe is it in practice?
   - Pick a random set of impacted sites and work with partnerships / gtech
   teams to do targeted outreach. Is it easy to get sites to fix issues? Can
   we learn anything about how to help make it easier for them, and/or how to
   filter out hits from our data that aren't actually a problem in practice?
   - Do a test deployment to beta channel and see what level of feedback we
   get. Plan for a finch trial on stable of <1% of users (but IMHO current
   data suggests we're not ready even for a small stable trial).
   - Ensure failures are hooked up to NEL (Network Error Logging
   ) and work with some bigger
   enterprises (eg. Google) to monitor, classify and debug breakage in their
   environment

Cheers,
> Titouan
>
>> Another question is the likely impact of a failed request. That is a
>>> question that is much harder to answer, but maybe you have an idea?
>>>
>> In the case of malicious usage, a failed request is a win for user
>> security and privacy! :) Seriously though, typically it means one of two
>> things: a) the core functionality of the page does not work, because its
>> whole purpose was to talk to a private network server, or b) some
>> subresources on the page fail to load because of weirdness around servers
>> with multiple IP addresses (some private, some public) or VPN usage (site
>> used to be public, now is on a private IP). In the case of b), a reload
>> usually fixes the issue.
>>
>>> A third question is whether the situation is likely to improve or worsen
>>> over time. Do you have any insights about that?
>>>
>> Optimistically, the situation should improve as a result of developers
>> noticing the warnings we've been flashing in DevTools for a while.
>>
>
FWIW, past experiences for major breaking changes suggest that this is not
particularly effective. "hopeful deprecations" have pretty much never
worked out :-).


> Pessimistically (and unfortunately this has been more our experience so
>> far), the situation will stagnate and/or get worse until the deprecation
>> starts, and people sign up for the deprecation trial. We can always invest
>> some more in classifying uses and reaching out to many small websites, it's
>> simply a tradeoff of time and effort spent trying to get ahead 

[blink-dev] PSA: Ignore .ini files next to web platform tests

['Jonathan Lee' via blink-dev]

If you do not write or review web platform tests, you can skip this email.

Hello blink-dev,

TL;DR: There are .ini files under web_tests/external/wpt/ and
web_tests/wpt_internal/ you can ignore for now.

What are these files?

These files were added as part of an ongoing project to run web platform
tests in Chromium CQ/CI with wptrunner, the harness that ships with
web-platform-tests/wpt
.

Like baselines and TestExpectations, each .ini file corresponds to a test
and contains expectation data in the structured format wptrunner natively
understands. web-platform-tests.org
 and
the Chromium wptrunner user guide

document the file format (named “WPT metadata”).

Do I need to update metadata files when making a change?

No, although these files are safe to add, modify, or remove. The WPT
importer

will use try build results to keep these files up-to-date automatically.
These files are not upstreamed to the GitHub repository.

Do I still need to rebaseline or add TestExpectations for web platform
tests?

Yes. Because CQ and sheriffed CI still use run_web_tests.py, not wptrunner,
the workflow for landing web platform tests in chromium/src has not changed.

Thanks,

Jonathan (on behalf of Blink EngProd)

-- 
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/CALBDgnEZ%3Drcdfv8TE3vbtXWPPK%3Dqxpe3fsB-8%2BkY%3DrBVs6Op5w%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Clear window name for cross-site navigations that switches browsing context group

[Shane Hird]

I have run into this issue with Firefox, angular-js and protractor:
 
https://docs.angularjs.org/guide/bootstrap
"If window.name contains prefix NG_DEFER_BOOTSTRAP! when angular.bootstrap 
 is called, 
the bootstrap process will be paused until angular.resumeBootstrap() is 
called."

It makes use of the ability to pass window.name and broke with Firefox's 
implementation of clearing this. I had to set 
'privacy.window.name.update.enabled=false' to restore functionality.
Hopefully the feature can continue to be disabled for testing purposes.

On Tuesday, 15 June 2021 at 12:53:42 am UTC+10 shu...@chromium.org wrote:

> Thanks for the review. I will proceed with Mike's suggestion.
>
> On Thu, Jun 10, 2021 at 3:49 PM Yoav Weiss  wrote:
>
>> LGTM3
>>
>> On Thu, Jun 10, 2021 at 9:16 PM Chris Harrelson  
>> wrote:
>>
>>> LGTM2
>>>
>>> On Thu, Jun 10, 2021 at 12:15 PM Mike West  wrote:
>>>
 LGTM1. This is the right direction for the platform, and following 
 Firefox's and Safari's good example gives me confidence that the 0.6% 
 number above is more benign than it looks.

 That said, two things seem prudent:

 1.  Given the usage, it's probably a good idea to roll this out via 
 Finch, as you suggest. I'm comfortable leaving the rollout schedule to 
 y'all, as long as we have the ability to turn it off if our hopes about 
 compatibility turn out to be unfounded.

 2.  Likewise, we often discover that our enterprise users are 
 unexpectedly exercising portions of the platform we'd like to remove. It 
 would be ideal to add a policy that allows them to carve themselves out 
 from this change for a limited time while they adjust their applications.

 Thanks!

 -mike

 On Friday, June 4, 2021 at 12:24:54 AM UTC+2 Shuran Huang wrote:

> Tried to calculate feature hit rate with origin matching "*.google.*", 
> which contributes ~27% of all the feature hits (other sites are below 
> 3%). 
> Note that the GAPI script could be loaded on other sites that do not set 
> the window.name field, which can contribute to the feature hit but 
> does not have compatibility issues if we enable the feature.
>
> I also checked the latest data from Chrome Status Platform, the 
> feature popularity drops to 0.4%. Could it be a reaction to the Firefox 
> change? According to the response received from Firefox, they haven't 
> observed any breakage so far. If enabling this feature for the binary is 
> considered risky, we can also go for a Finch rollout.
>
> On Wed, May 19, 2021 at 5:20 AM Yoav Weiss  
> wrote:
>
>>
>>
>> On Tue, May 18, 2021 at 6:58 PM Shuran Huang  
>> wrote:
>>
>>> Based on the UKM collected from beta M91, this feature is triggered 
>>> the most on https://www.google.com, way higher than other origins.
>>>
>>
>> Fun!
>>
>> If we exclude google.com, what is the %age of visits that are 
>> hitting this?
>>  
>>
>>>
>>> To figure out its compatibility impact for google, I've reached out 
>>> to GAPI team (GAPI is Google’s client library for browser-side 
>>> JavaScript, 
>>> which calls the window.name property, and is loaded when browsing 
>>> www.google.com) , as well as Web Testing team to find whether 
>>> enabling this feature would cause issues for GAPI or any google3 web 
>>> test 
>>> to fail (on chrome-linux). The test results showed that this feature 
>>> shouldn't be a problem for GAPI, and does not have any impact for 
>>> google3 
>>> web tests.
>>>
>>> I also haven't heard back from Firefox for any compatibility issues 
>>> after shipping this feature. So I wonder if we can enable the feature 
>>> for 
>>> the binary and be prepared to revert it back if it causes any breakage 
>>> in 
>>> beta. Also want to mention that this feature can be disabled in 
>>> Chrome://flags with 
>>> clear-cross-browsing-context-group-main-frame-name.
>>>
>>> On Fri, May 7, 2021 at 2:05 PM Shuran Huang  
>>> wrote:
>>>
 Hi Mike, 

 The UKM UseCounter was released in beta yesterday. I am waiting to 
 collect data from it. 

 Thanks,
 Shuran

 On Thu, May 6, 2021 at 2:20 PM Mike West  
 wrote:

> Ping. Were you able to make progress with regard to tracking down 
> usage anecdotes to better understand possible compat issues?
>
> -mike
>
>
> On Fri, Apr 23, 2021 at 8:39 PM Shuran Huang  
> wrote:
>
>> Hi Mike,
>>
>> I am still trying to collect data to clarify the impact. 
>> Unfortunately HTTP Archive does not have the data, so UKM was 
>> recently 
>> added 

Re: [blink-dev] Intent to Experiment: Dark mode support for web apps v2

[Rick Byers]

On Fri, Nov 4, 2022 at 2:24 AM 'Louise Brett' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emailsloubr...@google.com, glen...@chromium.org,
> mgi...@chromium.org
>
> Explainer
> V1:
> https://github.com/WICG/manifest-incubations/blob/gh-pages/user-preferences-explainer.md
> V2: https://github.com/w3c/manifest/issues/1045
>
> Specification
>
> Summary
>
> Add a field to the web app manifest which allows apps to specify a
> different theme color and background color for dark mode.
>
>
> Blink componentBlink>AppManifest
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/696
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> *Gecko*: No signal (
> https://github.com/mozilla/standards-positions/issues/630)
>
> *WebKit*: Positive (https://github.com/w3c/manifest/issues/1045)
>

Note that to minimize risk of misunderstandings, only official WebKit
standards position entries count as positive signals
.
It's not necessary for OT, but probably a good idea to get a position
request filed  ahead of a
future I2S.

*Web developers*: No signals - Positive signals from v1 but no signals on
> the new format
>
> *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?
>
>
>
> Goals for experimentation
>
> Allow web developers to use this field and provide feedback on the new
> format.
>
>
> Reason this experiment is being extended
>
> The manifest format has significantly changed per
> https://github.com/w3c/manifest/issues/1045 to use CSS media queries. We
> would like to run a new OT to get feedback from web developers about this
> new format.
>

Switching to CSS MQ syntax is indeed a pretty significant change. LGTM to
experiment M109-M114

Ongoing technical constraints
>
>
>
> Debuggability
>
> chrome://web-app-internals can be used for debugging, and this has been
> added to the DevTools Application pane.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?No
>
> Not supported on Android
>

Has there been discussion with Android folks? Eg. +Glenn Hartmann
? Ideally we'd ship support for all OSes at the
same time, but at a minimum we'll want to make sure the design we ship for
desktop is also reasonable for mobile in the future.

Is this feature fully tested by web-platform-tests
> 
> ?No - the v2 format does not have web platform tests yet.
>
> Flag namechrome://flags/#enable-experimental-web-platform-features
>
> Requires code in //chrome?True
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1318305
>
> Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1279284
>
> Estimated milestones
> OriginTrial desktop last 114
> OriginTrial desktop first 109
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5714780426862592
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/Y6zNtG0f-6A
> Intent to Experiment v1:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/ftoKq32Baz4
> Intent to Extend Experiment v1:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/2c8msRrrcF0
>
>
> 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/CABeVxY1nHwDDrShzu4m-RM%2B6UhM7Lp%2BB-TywkUfBrGEO3WPkSg%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/CAFUtAY9mX2%3Dk59xnAGVw1hRspCn8J8H%3D30najtQmkJoz6eSeuA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Anonymous iframes

['Arthur Sonzogni' via blink-dev]

Sorry for the delay, I was Travelling, OOO, then Covid.

Sorry, one more question: the tests seem to be mostly failing on wpt.fyi
> 
>  even
> with --enable-experimental-web-platform-features. Do you know why that is?
> What's the status of the test suite?
>

Thanks for noticing. That was about how the feature is declared. Let's fix
 it.

A few questions, is there any plan to move the spec code into HTML or
> other relevant specs? Do we have PRs for that?
>

Yes & Yes.
The anonymous iframe spec  is a
set of small patches against the HTML, Fetch, Storage, and Cookie
specification.

A link to described patch is given before each section:
[image: image.png]

There's another feature called "Fenced frames"
> (https://chromestatus.com/feature/5699388062040064) that is currently
> being worked on. Wouldn't be nice to explain how anonymous iframes vs
> fencedrames are? And if they interact in some way or not? Would
> fencedrames need an anonymous attribute at some point? Maybe we could
> add some of this information into the explainer.
>

There are 2 WPT

and a doc
.
I agree adding a section direction in the explainer would be useful. I will
do it.

TLDR: FencedFrame and anonymous iframe are totally different/unrelated.
Since  must not learn about its embedder, if you embed inside
an  a , it has no effect and the FencedFrame
is still subject to COEP. The other way around works the way


> About the explainer, the one used in the TAG review is:
> https://github.com/camillelamy/explainers/blob/main/anonymous_iframes.md
> But now it seems to be integrated into the spec
> https://wicg.github.io/anonymous-iframe/ which is not very common.


I agree. The first explainer was added inside camillelamy/explainer
 repo. That's not great, because
it contains several unrelated explainers. I had to create a new one so that
it can be transferred under the WICG: WICG/anonymous-iframe
. Having said that, we can't go
back into the past.


> Also
> the explainer usually includes the problem, alternatives discussed and
> the like, and now they're like separated sections in the spec. Maybe
> some reformatting could be useful.
>

They are all in the same doc today. Are you suggesting splitting it into a
separate markdown file?
I am not sure what the benefits would be. For those used to github, there
are links  to each
section.

I guess it'd be also nice to ensure we have proper documentation about
> this, "anonymous" attribute is not mentioned at MDN:
> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe


That would be lovely. I guess a PR against this file

in Mozilla repository is the proper way to make this happen. I will try.

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

[blink-dev] Intent to Experiment: Dark mode support for web apps v2

['Louise Brett' via blink-dev]

Contact emailsloubr...@google.com, glen...@chromium.org, mgi...@chromium.org

Explainer
V1:
https://github.com/WICG/manifest-incubations/blob/gh-pages/user-preferences-explainer.md
V2: https://github.com/w3c/manifest/issues/1045

Specification

Summary

Add a field to the web app manifest which allows apps to specify a
different theme color and background color for dark mode.


Blink componentBlink>AppManifest


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

TAG review statusPending

Risks


Interoperability and Compatibility



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

*WebKit*: Positive (https://github.com/w3c/manifest/issues/1045)

*Web developers*: No signals - Positive signals from v1 but no signals on
the new format

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



Goals for experimentation

Allow web developers to use this field and provide feedback on the new
format.


Reason this experiment is being extended

The manifest format has significantly changed per
https://github.com/w3c/manifest/issues/1045 to use CSS media queries. We
would like to run a new OT to get feedback from web developers about this
new format.


Ongoing technical constraints



Debuggability

chrome://web-app-internals can be used for debugging, and this has been
added to the DevTools Application pane.


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

Not supported on Android


Is this feature fully tested by web-platform-tests

?No - the v2 format does not have web platform tests yet.

Flag namechrome://flags/#enable-experimental-web-platform-features

Requires code in //chrome?True

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

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

Estimated milestones
OriginTrial desktop last 114
OriginTrial desktop first 109

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/Y6zNtG0f-6A
Intent to Experiment v1:
https://groups.google.com/a/chromium.org/g/blink-dev/c/ftoKq32Baz4
Intent to Extend Experiment v1:
https://groups.google.com/a/chromium.org/g/blink-dev/c/2c8msRrrcF0


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/CABeVxY1nHwDDrShzu4m-RM%2B6UhM7Lp%2BB-TywkUfBrGEO3WPkSg%40mail.gmail.com.