Presumably we would want to treat Web Transport the same way as Web Sockets here, whatever we decide?
On Sunday, December 8, 2024 at 12:20:50 PM UTC-8 philipp...@googlemail.com wrote: > what about WebSockets? Wondering about video conferencing websites that > use Websockets as signaling transport to establish a WebRTC connection but > do not open camera/microphone or the underlying connection until that is > necessary. > (I do not expect such applications to use a lot of CPU in that state so > might be fine) > > Am Mi., 4. Dez. 2024 um 06:34 Uhr schrieb Daniel Bratell < > bratel...@gmail.com>: > >> Before "notifications" have been used as a signal of a page that wants to >> run in the background. I didn't see it listed here. The other use case that >> has been mentioned in similar threads is stock market applications which >> seem to both want to run in the background and do non-trivial work of some >> kind. >> >> As for possible pitfalls I do wonder what happens on very slow or >> throttled computers where any work at all will be interpreted as "high cpu >> usage". >> >> But I think this overall is a very reasonable feature for a browser. >> There will be challenges in, tuning, UI and user communication, but nothing >> that I consider a feature blocker. >> >> LGTM2 >> >> /Daniel >> On 2024-12-04 03:45, Vladimir Levin wrote: >> >> You've mentioned things like mail/calendar should still work. Is this >> because the expected background CPU usage is low or is it that it's using >> some API that directly opts it out of the freezing behavior? I'm >> particularly worried about things like calendar that don't _typically_ need >> to do any work, but _occasionally_ want to show a notification that you >> have an upcoming meeting. If there happens to be some background work >> happening in those that causes it to be frozen, that seems like it could be >> a hard to discover problem (due to the fact that it maybe only occasionally >> uses too much CPU) and quite painful for the user. In general, any site >> that can do background work and notifies the user via notifications seems >> like it could be problematic >> >> Thanks, >> Vlad >> >> On Fri, Nov 29, 2024 at 7:38 PM Rick Byers <rby...@chromium.org> wrote: >> >>> LGTM1 to ship including a deprecation trial >>> >>> On Fri, Nov 29, 2024, 5:00 p.m. François Doray <fdo...@google.com> >>> wrote: >>> >>>> >>>> >>>> On Friday, November 29, 2024 at 3:13:39 PM UTC-5 Rick Byers wrote: >>>> >>>> tl;dr: Just one remaining question about providing a developer opt-out >>>> (like a deprecation trial). >>>> >>>> On Fri, Nov 29, 2024 at 12:25 PM Francois Pierre Doray < >>>> fdo...@chromium.org> wrote: >>>> >>>> Hi Rick, >>>> >>>> Thanks for raising your concerns regarding troubleshooting issues >>>> caused by Tab Freezing on Energy Saver. >>>> >>>> > Does Chrome have any visual indication that a tab has been frozen? >>>> There is no indication that a tab is frozen. However, the feature only >>>> operates when Energy Saver is active, signaled by a leaf icon next to the >>>> omnibox. When Energy Saver is first activated or when the leaf icon is >>>> clicked, a bubble indicates that "Background activity and some visual >>>> effects may be limited". >>>> >>>> >>>> Ah cool, I had never noticed that before myself. I see there's also a >>>> prominent "turn off now" button: >>>> >>>> [image: image.png] >>>> >>>> That seems like a significant mitigation to me. If someone is having >>>> trouble with some site it seems like there's a decent chance that they (or >>>> their IT support people) would notice this indicator, click it, then click >>>> "turn off now" and confirm that fixes the issue. From there I'd imagine >>>> troubleshooting would be pretty easy (google searches for "chrome energy >>>> saver" would point to the per-site opt-out etc.) >>>> >>>> We avoided a frozen tab indicator because in the long term (2-3 years), >>>> we plan to freeze most background tabs, to ensure that they don't steal >>>> resources from the foreground tab. At that point, there will be a visual >>>> indication for tabs that are *not* frozen (e.g. playing audio = >>>> speaker icon, using the progress notification API >>>> <https://github.com/explainers-by-googlers/progress-notification> to >>>> do arbitrary work = UI TBD). >>>> >>>> >>>> I love that long-term plan, thanks! Personally I'd love to have a mode >>>> where pages get to run in the background only if they show such an icon or >>>> in response to me granting their origin that permission. That's not behind >>>> a flag or anything yet, right? >>>> >>>> >>>> "Pages get to run in the background only if [they show some UI]" : In >>>> 2-3 years, we'd like this to be the default behavior, due to the expected >>>> foreground tab speed up and battery savings. It's not yet behind a flag. >>>> >>>> >>>> > How discoverable is it for users that they can add a site to an >>>> exclusion list? >>>> >>>> Users can add sites to the exclusion list via the "Performance" tab in >>>> Chrome settings (direct link: chrome://settings/performance), under >>>> "Always keep these sites active." This is also mentioned in the help >>>> article <https://support.google.com/chrome/answer/12929150> (will be >>>> updated for this launch). >>>> >>>> >>>> Yeah I saw that, and I like that the UI contains a "current sites" list >>>> rather than requiring copying URLs. But that alone certainly is not >>>> discoverable for a user who simply has a broken web page and doesn't know >>>> why. But given that disabling energy saver is very discoverable, that's >>>> good enough for me as long as this is coupled just to energy saver. I >>>> guess >>>> you won't really have a way to measure how much site compat issues lead >>>> users to disable energy saver, eh? I imagine most users disabling it will >>>> do so for the performance / visual quality concerns, not site compat >>>> reasons. >>>> >>>> >>>> We could run a HaTS survey to understand what leads users to add sites >>>> to the exclusion list. Let me know what you think and I can prioritize >>>> this. >>>> >>> >>> It's not important for the launch process, so up to you. Not needed from >>> my perspective. >>> >>> While discoverability is limited, most users won't need this feature. >>>> Typical mail/chat/calendar/phone/drive/music >>>> streaming/videoconferencing/... apps will either not exceed the CPU >>>> threshold for freezing or be opted out via API usage. Sites requiring high >>>> background CPU usage under Energy Saver (outside of audio/video calls, >>>> device control...) can direct users to the Chrome settings page or >>>> recommend using this policy >>>> <https://chromeenterprise.google/intl/en_ca/policies/#TabDiscardingExceptions> >>>> to >>>> enterprise admins (policy doc will be updated for this launch). >>>> >>>> >>>> Yes I'm definitely convinced that "most" (probably even >99.99%) of >>>> users won't have a problem - your design is great for that, thank you! But >>>> what I've learned from my incident post-mortem responsibilities is that >>>> it's the ~0.0001% of users that we have to really focus on to reduce the >>>> risk of most OMGs. Ask Robert about why I'm afraid of his wrath around >>>> this >>>> next time you see him in the office :-). >>>> >>>> Realistically I'd expect most such sites to just hack in some API usage >>>> that tickles your heuristic (like take an IndexedDB lock just for the >>>> purposes of being kept alive). That 's going to be much more effective for >>>> them than trying to direct users to take some manual steps, right? That >>>> seems unfortunate to me, as it will make your life harder in driving down >>>> the exceptions. Experience with this sort of thing is a big part of the >>>> motivation behind our guidance >>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?tab=t.0#heading=h.glc7fyugcipe> >>>> >>>> for providing explicit developer opt-outs for breaking changes (especially >>>> interventions like this). Sure, there is some risk of an explicit opt-out >>>> being abused but that risk isn't necessarily any greater than abuse of >>>> your >>>> heuristic, and at least you can more easily measure and track it and >>>> update >>>> behavior as necessary for any "arms race" with abusive sites. Have you >>>> considered offering developers a deprecation trial >>>> <https://www.chromium.org/blink/launching-features/#deprecation-trial> to >>>> reduce the risk of them abusing your heuristics and get you contact info >>>> for the developers who feel they must opt-out? >>>> >>>> >>>> I hadn't considered a deprecation trial, but I think it's a good idea >>>> to reduce the risk of Web developers abusing our heuristics. In terms of >>>> process, should I create a "Feature removal" entry at chromestatus.com >>>> or can we handle this as part of this intent? >>>> >>> >>> Great! Yeah we can just use this intent, no need for extra overhead. And >>> of course it's important to document how to use the trial in the blog post. >>> >>> >>>> We think that requiring some effort to allow high background CPU usage >>>> under Energy Saver is reasonable, as it can significantly impact battery >>>> life and contradicts Energy Saver's purpose (note: Energy Saver is only >>>> available on battery power, activates when battery level is below 20% by >>>> default). >>>> >>>> >>>> I suspect that most impacted users would simply disable energy saver >>>> completely rather than make the extra effort to discover and use the >>>> site-specific opt-out. But that's fine - both settings aren't hard to >>>> find, >>>> and if you see a lot of users disabling energy saver then you can do some >>>> research to see if better per-site controls might help reduce that (though >>>> we might be stuck for the users who have already opted out completely). >>>> >>>> >>>> "though we might be stuck for the users who have already opted out >>>> completely": If we observe any significant difference in the number of >>>> Energy Saver activations between the Control/Enabled groups, or if we >>>> observe an upward trend of users without Energy Saver after the launch, >>>> we'll investigate why and make adjustments. >>>> >>> >>> Oh of course, that makes sense - thanks! >>> >>> >>>> > Is the plan for Chrome 133 to be fully at 100%, with 132 still well >>>> below that? >>>> The plan is to experiment on 1% of stable users in Chrome 133 and then >>>> ramp up gradually as we gain confidence that the feature is well tuned. >>>> The >>>> feature is already under experimentation in Canary/Dev. We intend to >>>> expand Tab Freezing beyond Energy Saver in the future, taking into account >>>> lessons learned from this limited scope launch, but that will be handled >>>> under new Intents. >>>> >>>> >>>> Ok, we've come to appreciate that that pattern increases the risk >>>> somewhat because it makes it even harder for IT admins and support >>>> personnel to reproduce and action site compat issues their users are >>>> complaining about. I don't think we've yet come up with some well-informed >>>> guidance for mitigating this risk, so I won't ask for something different >>>> (eg. could keep to <10% in 133 and then go 100% in 134). But it's >>>> something >>>> to keep an eye out for in customer reports and perhaps inform our future >>>> guidance, so please let me know (here or privately) if it ends up showing >>>> up as an issue in customer reports or not. >>>> >>>> >>>> Sounds good. >>>> >>>> >>>> >>>> > Will the blog post you mentioned be published prior to 133 beta (Jan >>>> 15)? >>>> That's the goal, though DevRel hasn't confirmed a date. I'll check in >>>> with them. >>>> >>>> >>>> Ok, thanks. If the blog post gets delayed, please hold off on extending >>>> the experiment to stable until the blog post is live. >>>> >>>> >>>> Sounds good. >>>> >>>> >>>> >>>> Have a nice day, >>>> >>>> François >>>> >>>> On Wednesday, November 27, 2024 at 10:20:09 AM UTC-5 Rick Byers wrote: >>>> >>>> I evaluated this intent relative to our compat principles >>>> <https://bit.ly/blink-compat> and overall think you've done an >>>> excellent job mitigating the compat risks. In particular the user >>>> controls, >>>> developer-influencable heuristics and enterprise opt-out seem likely to be >>>> significant mitigations. I'm also confident that you will be proactive in >>>> monitoring for issues and being responsive to feedback. >>>> >>>> Heuristics like the energy saver and CPU threshold seem great to me on >>>> balance, but I'm also nervous that they will make troubleshooting rare but >>>> severe issues harder (especially since these signals can't really be >>>> monitored via web page telemetry). We've learned from one recent incident >>>> that sometimes the rarest incidents can be extremely bad - eg. causing a >>>> serious business disruption for one single organization but not more >>>> widely >>>> (making support for that organization much harder). In such cases, >>>> discoverability and understandability of the issue (including by skilled >>>> IT >>>> support personnel) is key to avoiding extended outages. With that in mind, >>>> I have a couple questions: >>>> >>>> Does Chrome have any visual indication that a tab has been frozen? How >>>> discoverable is it for users that they can add a site to an exclusion list? >>>> >>>> Is the plan for Chrome 133 to be fully at 100%, with 132 still well >>>> below that? I'm just wondering to what extent someone looking into website >>>> logs for an issue will be able to detect a clear correlation with Chrome >>>> 133 (increasing the chance that they reach out to us or find this >>>> mentioned >>>> in the chrome 133 blog post)? >>>> >>>> Will the blog post you mentioned be published prior to 133 beta (Jan >>>> 15)? I see it's mentioned >>>> <https://support.google.com/chrome/a/answer/7679408?hl=en&co=CHROME_ENTERPRISE._Product%3DChromeBrowser#top:~:text=131%20on%20Android-,Tab%20freezing%20on%20Energy%20saver,-When%20Energy%20saver> >>>> >>>> in Chrome 131 enterprise release notes already, thank you! >>>> >>>> Thanks, >>>> Rick >>>> >>>> On Tue, Nov 26, 2024 at 3:11 PM Chromestatus < >>>> ad...@cr-status.appspotmail.com> wrote: >>>> >>>> Contact emails fdo...@chromium.org, shas...@chromium.org >>>> >>>> Explainer None >>>> >>>> Specification https://wicg.github.io/page-lifecycle >>>> >>>> Design docs >>>> >>>> https://docs.google.com/document/d/1uTJifh_erMX4_CTKgKljlj9O4SAmGam5W61FBHeasGI/edit?usp=sharing >>>> >>>> >>>> Summary >>>> >>>> When Energy Saver is active, Chrome will freeze a "browsing context >>>> group" that has been hidden and silent for >5 minutes if any subgroup of >>>> same-origin frames within it exceeds a CPU usage threshold, unless it: - >>>> Provides audio- or video-conferencing functionality (detected via >>>> microphone, camera or screen/window/tab capture or an RTCPeerConnection >>>> with an 'open' RTCDataChannel or a 'live' MediaStreamTrack). - Controls an >>>> external device (detected via usage of Web USB, Web Bluetooth, Web HID or >>>> Web Serial). - Holds a Web Lock or an IndexedDB connection that blocks a >>>> version update or a transaction on a different connection. Freezing >>>> consists of pausing execution. It is formally defined in the Page >>>> Lifecycle >>>> API. The CPU usage threshold will be calibrated to freeze approximately >>>> 10% >>>> of background tabs when Energy Saver is active. >>>> >>>> >>>> Blink component Blink>Scheduling >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScheduling> >>>> >>>> >>>> TAG review None >>>> >>>> TAG review status Not applicable >>>> >>>> Risks >>>> >>>> >>>> Interoperability and Compatibility >>>> >>>> Interoperability: This feature does not expose new capabilities to the >>>> Web, so it has low chances of creating situations in which the same >>>> HTML/CSS/Js/... behaves differently in different browsers. That being >>>> said, >>>> we invite other browsers vendors that already shipped "tab freezing" to >>>> share and discuss their opt-out rules, which will help offer consistent >>>> behavior for web developers across browsers, avoiding situations where a >>>> site's background functionality works correctly in some browsers but not >>>> others. Compatibility: This feature may affect existing sites with >>>> background functionality. However, breaking some functionality to extend >>>> battery life is in line with user expectations when "Energy Saver" is >>>> active. We're interested in Web developer feedback to adjust our opt-outs >>>> and minimize avoidable breakages. "Energy Saver" can be disabled via the >>>> the "BatterySaverModeAvailability" enterprise policy. >>>> >>>> >>>> *Gecko*: Under consideration ( >>>> https://github.com/mozilla/standards-positions/issues/87) >>>> >>>> *WebKit*: No signal >>>> >>>> *Web developers*: No signals In the past, Web developers expressed >>>> concerns about freezing, because it made it difficult to implement >>>> background functionality that users care about in a reliable way (e.g. >>>> notification for calendar event). By freezing only pages that use a lot of >>>> CPU and only when Energy Saver is active, breakages that were reported in >>>> the past are mitigated. Additionally, we will listen to Web developers >>>> feedback on multiple channels (crbug, blink-dev, stack overflow, twitter, >>>> github) and make adjustments to heuristics if we find that background >>>> functionality that users care about is broken. Users may deactivate Energy >>>> Saver or manually opt-out sites at chrome://settings/performance >>>> >>>> *Other signals*: Chrome on Android freezes background tabs after 5 >>>> minutes ( >>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/NKtuFxLsKgo/m/brL3bfS5CAAJ). >>>> >>>> Chrome on desktop and Android freezes pages before putting them in the >>>> BFCache. Chrome on desktop freezes tabs in collapsed tab groups. Edge >>>> freezes background tabs after a configurable timeout ( >>>> https://www.microsoft.com/en-us/edge/features/sleeping-tabs-at-work?form=MT00D8). >>>> >>>> >>>> >>>> Ergonomics >>>> >>>> No Ergonomics Risks identified. >>>> >>>> >>>> Activation >>>> >>>> No action is required to support browsers that don't freeze pages. >>>> >>>> >>>> Security >>>> >>>> A frame can observe when it is frozen, either directly (via the >>>> “freeze” event) or indirectly (timer runs later than expected, server >>>> doesn’t receive a ping…). When the decision to freeze a frame depends on >>>> observations made on other cross-origin frames (crossing CPU usage >>>> threshold, using Web API that opt-outs from freezing) there is a risk of >>>> leaking information across origins. Multiple solutions were considered to >>>> balance security and ergonomy requirements. We finally landed on "freezing >>>> a browsing context group based on independent observations made on groups >>>> of same-origin/same-page frames in that browsing context group". Pros & >>>> cons + All frames on a page are in the same “frozen” state (does not break >>>> Web devs assumptions). + All frames that can synchronously script each >>>> other are in the same “frozen” state (does not break Web devs >>>> assumptions). >>>> + Not aggregating CPU usage across origins minimizes leaks, because an >>>> attacker can’t vary its own CPU usage to precisely measure the CPU usage >>>> of >>>> another origin. - Leaks Web API usage across cross-origin frames (a frame >>>> can learn that a cross-origin frame in the "browsing context group" uses >>>> or >>>> doesn't use one of the APIs that prevents freezing depending on whether it >>>> itself gets frozen). >>>> >>>> >>>> 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? >>>> >>>> This is a desktop-only feature which does not affect Webview. >>>> >>>> >>>> Debuggability >>>> >>>> The frozen state of a tab is displayed in the "Lifecycle state" column >>>> of chrome://discards. Whether a page can be frozen and why (e.g. usage >>>> of WebRTC) is displayed in the "Is freezable" column of >>>> chrome://discards. The #freezing-on-energy-saver and >>>> #freezing-on-energy-saver-testing features at about:flags can be used >>>> to test this intervention. It is also possible to manually freeze a tab >>>> via >>>> chrome://discards to verify how it reacts. >>>> >>>> >>>> Will this feature be supported on all six Blink platforms (Windows, >>>> Mac, Linux, ChromeOS, Android, and Android WebView)? Yes >>>> >>>> Chrome for Android already freezes pages in the background (not tied to >>>> Energy Saver). This proposal brings freezing to desktop. >>>> >>>> >>>> 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 about://flags freezing-on-energy-saver >>>> >>>> Finch feature name FreezingOnBatterySaver >>>> >>>> Requires code in //chrome? False >>>> >>>> Tracking bug https://crbug.com/325954772 >>>> >>>> Launch bug https://launch.corp.google.com/launch/4282880 >>>> >>>> Measurement This feature doesn't introduce new APIs that web pages >>>> need to adopt. >>>> >>>> Availability expectation This feature doesn't introduce new APIs that >>>> other browsers need to make available. It expands the sets of conditions >>>> under which Chrome may freeze tabs (previously, only tabs in collapsed tab >>>> groups could be frozen). >>>> >>>> Adoption expectation This feature doesn't introduce new APIs that web >>>> pages need to adopt. Web pages may listen to the freeze/resume events to >>>> react to freezing, but it's not an issue if a web page doesn't. These >>>> events are already dispatched when a tab in a collapsed tab group is >>>> frozen. >>>> >>>> Adoption plan In collaboration with DevRel, we will publish an article >>>> covering the conditions under which freezing is triggered and possible >>>> remediations for broken background use cases. >>>> >>>> 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? >>>> No >>>> >>>> Estimated milestones Shipping on desktop 133 DevTrial on desktop 132 >>>> >>>> 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). >>>> This feature does not modify the spec. It changes the conditions under >>>> which tabs are frozen in Chrome. Those conditions are expected to evolve >>>> over time. >>>> >>>> Link to entry on the Chrome Platform Status >>>> https://chromestatus.com/feature/5158599457767424?gate=5076873410772992 >>>> >>>> Links to previous Intent discussions Intent to Prototype: >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG9b2qVcRLRWXUz61AkRWi%2BkaOJwgUK8bNCRBG6LOpqgOd%2BvSw%40mail.gmail.com >>>> >>>> Ready for Trial: >>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/Xu1C7WhoGm4/m/_9U_kLHDAwAJ >>>> >>>> >>>> >>>> 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+...@chromium.org. >>>> >>>> >>>> To view this discussion visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67462b62.2b0a0220.19a388.0546.GAE%40google.com >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67462b62.2b0a0220.19a388.0546.GAE%40google.com?utm_medium=email&utm_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 visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9fhohUewpp%3D_eeMcWEbQtZvBvLDNnnPT6eSAbdwxq8uA%40mail.gmail.com >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9fhohUewpp%3D_eeMcWEbQtZvBvLDNnnPT6eSAbdwxq8uA%40mail.gmail.com?utm_medium=email&utm_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 visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2P1o1wBfdum060TnNmotmxoCFr0fEqKjjzUg%2BaepNijkw%40mail.gmail.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2P1o1wBfdum060TnNmotmxoCFr0fEqKjjzUg%2BaepNijkw%40mail.gmail.com?utm_medium=email&utm_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 visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4086d432-7397-4bc5-9ba8-40f783428cf8%40gmail.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4086d432-7397-4bc5-9ba8-40f783428cf8%40gmail.com?utm_medium=email&utm_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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/dbeb8448-256a-4527-a325-bd6ba3778b36n%40chromium.org.
