Update: The feature is now enabled for 1% of Chrome 133 stable users (for these users, it only has an effect if Energy Saver is active and there are eligible CPU-intensive background tabs). This blog post <https://developer.chrome.com/blog/freezing-on-energy-saver> provides details for Web developers, including instructions to opt-out via an origin trial.
On Monday, December 16, 2024 at 3:35:04 PM UTC-5 Vladimir Levin wrote: > LGTM3, thank you for the detailed explanation. > > On Sat, Dec 14, 2024 at 8:46 AM Francois Pierre Doray <fdo...@chromium.org> > wrote: > >> >> >> On Wednesday, December 11, 2024 at 3:11:04 PM UTC-5 Felipe Gomes wrote: >> >> Are there plans to exempt websites running/installed as a PWA from this? >> >> There are no plans to opt-out PWA from this. If a PWA needs to use a lot >> of CPU in the background when Energy Saver is active, it can use the same >> mechanisms as background tabs, i.e. origin trial opt-out (short-term) or >> the Progress API >> <https://github.com/explainers-by-googlers/progress-notification> >> (long-term). >> >> Energy Saver is a mode that users can rely on to extend battery life. >> It's associated with UI indicating that it limits background activity and >> users can disable it. We want to provide ways for background web content to >> run CPU-intensive workloads under Energy Saver, but we don't want it to be >> the default, since that would make it too easy to inadvertently drain the >> battery with no user benefit. For example, we want to avoid scenarios in >> which web content continues unnecessary tasks in the background, like >> polling scroll position, due to missing code that stops these tasks when >> the content is hidden. >> >> >> >> On Wednesday, December 11, 2024 at 3:20:49 PM UTC-3 François Doray wrote: >> >> Hi everyone, >> >> Thanks for the feedback. Here are my responses: >> >> 1. An origin trial will allow Web developers to opt out of freezing. In >> addition to provide a quick way to prevent breakages, it will help us >> identify background use cases that might need dedicated APIs for support. >> >> 2. A blog post documenting the freezing policy and the origin trial will >> be published before the stable experiment. >> >> 3. I'm okay with adjusting the release schedule (e.g., "<10% in 133, 100% >> in 134") to help enterprise admins diagnose issues. >> >> 4. We'll track usage of the "Always keep these sites active" list in >> chrome://settings/performance. If usage increases significantly with >> freezing, we'll investigate and adjust accordingly. This list should be >> helpful to users with rare use cases, not a common solution. >> >> 5. Mail/chat/calendar apps shouldn't be affected, as the "high CPU usage" >> threshold will be significantly higher than their normal usage. If >> necessary, they can use the origin trial opt-out (short-term) or the >> Progress >> API <https://github.com/explainers-by-googlers/progress-notification> >> (long-term) >> to declare CPU intensive workloads and avoid being frozen. They can also >> use the Push API to deliver notifications even when they aren't loaded, are >> crashed or are frozen (we're interested to learn about any hurdles >> preventing apps from adopting the Push API). >> >> 6. Tabs with notification permission will be opted out of freezing >> initially. We aim to remove this opt-out eventually, as notifications >> typically don't require high CPU usage. For high CPU needs, the origin >> trial (short-term) or the Progress API >> <https://github.com/explainers-by-googlers/progress-notification> >> (long-term) are >> preferred solutions. >> >> 7. Pages with active WebRTC connections will be opted out, so >> videoconferencing apps will continue working, even if they don't capture >> from the camera/microphone/screen. No opt-out is planned for WebSockets or >> Web Transport, as they don't usually indicate CPU-intensive background >> functionality. The origin trial or Progress API can be used to avoid >> freezing despite running CPU-intensive workloads. >> >> A note on the Progress API >> <https://github.com/explainers-by-googlers/progress-notification>: We >> want the Progress API to be a good way for pages to declare their need for >> background resources (CPU/network) when other APIs (WebRTC, audio playback, >> Web USB, etc.) don't apply. It will be tied to UI (TBD) so that users >> remain in control. Besides opting out of freezing, usage of the API can >> increase CPU/network priority. We know some pages need background resources >> without having progress information (e.g., stock market dashboards, >> cryptocurrency miners). We'll ensure the Progress API (which might be >> renamed) covers these cases. >> >> Have a nice day, >> >> François >> >> On Wednesday, December 11, 2024 at 11:12:14 AM UTC-5 Alex Russell wrote: >> >> 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 < >> brat...@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+...@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+...@chromium.org. >> >> >> To view this discussion visit https://groups.google.com/a/ >> chromium.org/d/msgid/blink-dev/CADsXd2P1o1wBfdum060TnNmotmxoC >> Fr0fEqKjjzUg%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+...@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+...@chromium.org. >> > To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9c49e8db-6b7b-4dc2-8187-ff40a0bdf40en%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9c49e8db-6b7b-4dc2-8187-ff40a0bdf40en%40chromium.org?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/4f577fc0-1b97-4568-84c5-a88bd2fcf472n%40chromium.org.
