Hello everybody, are there any updates on this? I've found this feature https://chromestatus.com/feature/5279664766713856 but it seems it has not been recently updated.
I'm asking because we stopped some ongoing work to fully support partitioned cookies in our platform (Moodle LMS) as it was having a severe impact on our mobile app users. At this point, what we'd like to know if the current partitioned cookies implementation will be deprecated or not. Regards, Juan On Monday, July 22, 2024 at 8:23:40 PM UTC+2 Ben Wiser wrote: > Little late to the thread but I had a chat with Torne and we both agree > from the WebView side that deleting the cookies is the preferred option for > disabling the feature from our perspective. > > The alternative of migrating partitioned cookies to 3PCs has these cons: > > - Also not gated via finch which introduces a bit of risk > - Up levels data that was intended to be per website > > As Vlad said, sites can deal with no cookies - and given that these use > cases will be more slim, this option is preferable. > > On Thu, Jul 18, 2024 at 6:43 PM Mike Taylor <mike...@chromium.org> wrote: > >> LGTM3 >> On 7/18/24 11:24 AM, Chris Harrelson wrote: >> >> LGTM2 >> >> On Thu, Jul 18, 2024 at 6:49 AM Vladimir Levin <vmp...@chromium.org> >> wrote: >> >>> >>> >>> On Wed, Jul 17, 2024 at 3:13 PM 'Dylan Cutler' via blink-dev < >>> blin...@chromium.org> wrote: >>> >>>> Hey Vlad, >>>> >>>> I agree that deleting the affected cookies seems to be the least risky >>>>> behavior here. Is this plan to roll out via Finch and monitor for bad >>>>> breakages? >>>>> >>>> Unfortunately it is not possible to roll out network feature changes >>>> via Finch to WebView, since WebView may sometimes use the cookie store >>>> before the feature list has been fully initialized. We have implemented >>>> this change as a command line switch for the process running the network >>>> service. >>>> >>> >>> That makes sense. It does increase the risk of this removal, but I can't >>> think of any other approach. As someone pointed out: "having no cookies is >>> better than having corrupted cookies", and apps/sites should be able to >>> deal gracefully with cookies being deleted. >>> >>> LGTM1 >>> >>> >>>> Also, could you start the various reviews on the chromestatus entry? >>>> >>>> Done! >>>> >>>> Dylan >>>> >>>> On Wed, Jul 17, 2024 at 2:03 PM Vladimir Levin <vmp...@chromium.org> >>>> wrote: >>>> >>>>> Thank you for all of the context. >>>>> >>>>> I agree that deleting the affected cookies seems to be the least risky >>>>> behavior here. Is this plan to roll out via Finch and monitor for bad >>>>> breakages? >>>>> >>>>> Also, could you start the various reviews on the chromestatus entry? >>>>> [image: chipsna.png] >>>>> >>>>> Thanks, >>>>> Vlad >>>>> >>>>> On Thu, Jul 11, 2024 at 1:17 PM Torne (Richard Coles) < >>>>> to...@chromium.org> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Tue, 9 Jul 2024 at 10:20, Vladimir Levin <vmp...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Jun 28, 2024, 16:28 'Dylan Cutler' via blink-dev < >>>>>>> blin...@chromium.org> wrote: >>>>>>> >>>>>>>> Hey Vlad, >>>>>>>> >>>>>>>> Thanks for your response. I have completed the analysis and have >>>>>>>> some results to report. I also have created the Chromestatus >>>>>>>> <https://chromestatus.com/feature/5279664766713856> entry as >>>>>>>> requested. >>>>>>>> >>>>>>>> Here are some stats that give a picture of CHIPS usage on WebView >>>>>>>> >>>>>>>> - Global percentage of requests from WebView clients that >>>>>>>> contain partitioned cookies: 33% >>>>>>>> - Global percentage of requests from WebView that contain a >>>>>>>> single partitioned cookie: 29% >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> - Average percentage of requests from a single WebView app that >>>>>>>> contain partitioned cookies: 10% >>>>>>>> - Average percentage of requests from a single WebView app that >>>>>>>> contain a single partitioned cookie: 7% >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> - Global percentage of CHIPS we estimate to be the >>>>>>>> receive-cookie-deprecation >>>>>>>> >>>>>>>> <https://developers.google.com/privacy-sandbox/relevance/setup/web/chrome-facilitated-testing> >>>>>>>> >>>>>>>> opt-in cookie: 54% >>>>>>>> - Average percentage of CHIPS that each app has stored that we >>>>>>>> estimate to be the receive-cookie-deprecation opt-in cookie: 55% >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> - The percentage of apps using CHIPS: 73% >>>>>>>> - The percentage of apps using the receive-cookie-deprecation >>>>>>>> opt in cookie: 66% >>>>>>>> >>>>>>>> The majority of usage of CHIPS is for the 3PCD facilitated testing >>>>>>>> opt-in cookie, which will not be impacted by this change since this >>>>>>>> cookie >>>>>>>> merely serves to opt into browser behavior that is not available on >>>>>>>> WebView >>>>>>>> regardless. >>>>>>>> >>>>>>>> That being said, we do see usage of CHIPS is significant on >>>>>>>> WebView, so we have to weigh our options. Is it more disruptive to >>>>>>>> delete >>>>>>>> the cookies, silently change their behavior to unpartitioned, or to do >>>>>>>> nothing until shouldInterceptRequest supports the Cookie header. I am >>>>>>>> also >>>>>>>> curious to hear your take. >>>>>>>> >>>>>>> >>>>>>> Thank you for the analysis. Can you help me understand what >>>>>>> percentage of webview apps do you expect would experience a breakage if >>>>>>> delete the cookies? My understanding is that it's around 33% assuming >>>>>>> that >>>>>>> global requests are distributed evenly across apps? Although that >>>>>>> doesn't >>>>>>> seem to be a valid assumption to make. >>>>>>> >>>>>> >>>>>> Right, it won't be distributed evenly because apps load different >>>>>> sites, and whether partitioned cookies are used is primarily down to the >>>>>> site. It's not entirely straightforward to figure out how this is >>>>>> distributed across apps. >>>>>> >>>>>> >>>>>>> It does sound like it's not going to be a small number. I'm also >>>>>>> assuming that a single cookie case is interesting because these are the >>>>>>> cases that can be moved to be unpartitioned with no collisions, is that >>>>>>> right? If so the remainder of breakages seems large as well. >>>>>>> >>>>>>> The type of breakage would be temporary but noticeable, like a need >>>>>>> to sign in again. However, it can also be as bad as losing arbitrary >>>>>>> data >>>>>>> that would have been stored in that cookie. Is that correct? >>>>>>> >>>>>> >>>>>> Yes, though for many apps the breakage would be nothing - lots of >>>>>> apps use WebView in a way where there is *no* meaningful data stored via >>>>>> web mechanisms. >>>>>> >>>>>> >>>>>>> You noted that the current behavior is a mismatch between what >>>>>>> webview sees and what the cookie manager can access in java. Do we know >>>>>>> how >>>>>>> frequently cookie manager is used in these cases? I'm trying to >>>>>>> estimate >>>>>>> actual inconsistent behavior that this is trying to fix and if that >>>>>>> worth >>>>>>> the risk of breakage for all partitioned cookies >>>>>>> >>>>>> >>>>>> This is not the only issue; there's a bigger problem with apps that >>>>>> intercept network requests from WebView - because the interception >>>>>> happens >>>>>> extremely early in the request lifecycle, the request information that >>>>>> gets >>>>>> passed to the app does not include any cookie headers at all (regardless >>>>>> of >>>>>> partitioning), and if the app does choose to intercept the request and >>>>>> return a response, any Set-Cookie headers in the response are *also* not >>>>>> processed. This means that when apps are doing this kind of interception >>>>>> they need to use the CookieManager APIs to get the cookies for the >>>>>> request >>>>>> and attach them themselves, and likewise need to set cookies manually >>>>>> using >>>>>> CookieManager for responses. >>>>>> >>>>>> It's impossible for apps to do this correctly for partitioned >>>>>> cookies, and extending the CookieManager APIs to allow getting/setting >>>>>> partitioned cookies is not sufficient to fix it: the request >>>>>> interception >>>>>> API doesn't provide any 1P/3P context information and so the app has no >>>>>> way >>>>>> to know which partition key to pass to the API to get/set the cookies >>>>>> correctly. This also means that any future changes to cookie behavior >>>>>> are >>>>>> likely to cause similar problems. >>>>>> >>>>>> bewise@ is working on changes to the request interception behavior to >>>>>> handle the cookie headers automatically to fix this (e.g. >>>>>> https://chromium-review.googlesource.com/c/chromium/src/+/5616051) >>>>>> but this is significantly more difficult than just extending the >>>>>> CookieManager API, as this requires changing the behavior of existing >>>>>> APIs >>>>>> in a backward-incompatible way. >>>>>> >>>>>> >>>>>>> Also, what's the timeline for shipping the cookie manager fix that >>>>>>> would be able to deal with partitioned cookies properly? >>>>>>> >>>>>> >>>>>> I'm not sure what the current plan to ship the changes here is, but >>>>>> it may take some time due to the changes being more involved and a >>>>>> bigger >>>>>> compat risk than initially thought. >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vlad >>>>>>> >>>>>>>> >>>>>>>> Best, >>>>>>>> Dylan >>>>>>>> On Wed, Jun 5, 2024 at 11:55 AM Vladimir Levin <vmp...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hey, >>>>>>>>> >>>>>>>>> The first item looks like a good starting point. We can discuss >>>>>>>>> possible solutions when we know how much usage there is. >>>>>>>>> >>>>>>>>> For visibility, can you please file a chromestatus entry for this >>>>>>>>> intent? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vlad >>>>>>>>> >>>>>>>>> On Wed, Jun 5, 2024 at 10:36 AM 'Dylan Cutler' via blink-dev < >>>>>>>>> blin...@chromium.org> wrote: >>>>>>>>> >>>>>>>>>> Hey Vlad, >>>>>>>>>> >>>>>>>>>> Thanks for your response and interest in the intent. I can see >>>>>>>>>> two paths going forward. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 1. We query UMA to determine just what percentage of WebView >>>>>>>>>> apps embed content using CHIPS (and in how many partitions). We >>>>>>>>>> can also >>>>>>>>>> use these metrics to identify the top apps who embed users of >>>>>>>>>> CHIPS and >>>>>>>>>> make sure this change would not lead to disruptions. If that >>>>>>>>>> proves to be >>>>>>>>>> enough so that you are no longer concerned about breakage then we >>>>>>>>>> could move forward. Otherwise, we move on to approach (2). >>>>>>>>>> 2. We refactor our code so that if CHIPS is disabled in >>>>>>>>>> WebView, rather than deleting partitioned cookies we could >>>>>>>>>> convert them to >>>>>>>>>> unpartitioned. If the user has an unpartitioned cookie with the >>>>>>>>>> same >>>>>>>>>> name/domain/path, then we would delete the partitioned cookie in >>>>>>>>>> favor of >>>>>>>>>> the unpartitioned one. If multiple cookies exist in different >>>>>>>>>> partitions >>>>>>>>>> and no such unpartitioned cookie exists, we would fall back on >>>>>>>>>> the most >>>>>>>>>> recently used cookie. It is worth noting, this technique is >>>>>>>>>> complex and >>>>>>>>>> could have its own risks, so we'd like to leave it as a last >>>>>>>>>> resort. >>>>>>>>>> >>>>>>>>>> Let me know what you think, and if this sounds acceptable, I can >>>>>>>>>> get that data from UMA to start to inform if we want to pursue the >>>>>>>>>> algorithm in (2). >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Dylan >>>>>>>>>> >>>>>>>>>> On Fri, May 31, 2024 at 5:11 AM Vladimir Levin < >>>>>>>>>> vmp...@chromium.org> wrote: >>>>>>>>>> >>>>>>>>>>> On Wed, May 29, 2024 at 5:02 PM 'Dylan Cutler' via blink-dev < >>>>>>>>>>> blin...@chromium.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hello Blink API Owners, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> We’re seeking approval to unship and relaunch CHIPS (a.k.a. >>>>>>>>>>>> partitioned cookies) in Android WebView only. >>>>>>>>>>>> >>>>>>>>>>>> Rationale >>>>>>>>>>>> >>>>>>>>>>>> The WebViewClient supports a method, shouldInterceptRequest >>>>>>>>>>>> <https://developer.android.com/reference/android/webkit/WebViewClient#shouldInterceptRequest(android.webkit.WebView,%20android.webkit.WebResourceRequest)>, >>>>>>>>>>>> >>>>>>>>>>>> which allows developers to intercept network activity and modify >>>>>>>>>>>> HTTP >>>>>>>>>>>> headers, etc. This API does not have access to the Cookie header >>>>>>>>>>>> and relies >>>>>>>>>>>> on the Android CookieManager API >>>>>>>>>>>> <https://developer.android.com/reference/android/webkit/CookieManager> >>>>>>>>>>>> >>>>>>>>>>>> in order to query what cookies are available for a particular >>>>>>>>>>>> request URL. >>>>>>>>>>>> This is because the request is intercepted before it is sent >>>>>>>>>>>> to the network service >>>>>>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:android_webview/browser/aw_contents_io_thread_client.cc;l=316;drc=59ac8227c5dd59754331b3f7f9f85e1a947f1242>, >>>>>>>>>>>> >>>>>>>>>>>> where the Cookie header is added. However, partitioned cookies are >>>>>>>>>>>> double-keyed on the top-level site and the site of the URL using >>>>>>>>>>>> the >>>>>>>>>>>> cookies. >>>>>>>>>>>> >>>>>>>>>>>> Currently, the CookieManager API provides no way for developers >>>>>>>>>>>> to query partitioned cookies correctly, and this will cause a >>>>>>>>>>>> mismatch >>>>>>>>>>>> between what the Java API returns and what frames in WebView will >>>>>>>>>>>> actually >>>>>>>>>>>> be in their Cookie header. In hindsight, this seems risky and >>>>>>>>>>>> prone to >>>>>>>>>>>> bugs, and not something the CHIPS team had considered while >>>>>>>>>>>> designing the >>>>>>>>>>>> API. >>>>>>>>>>>> >>>>>>>>>>>> After discussing this with the WebView team, we believe that >>>>>>>>>>>> the option that will minimize potential app breakage is to disable >>>>>>>>>>>> CHIPS on >>>>>>>>>>>> WebView until we are able to ship support for the Cookie header to >>>>>>>>>>>> shouldInterceptRequest. We will release the changes to >>>>>>>>>>>> shouldInterceptRequest in the next target SDK version (API level >>>>>>>>>>>> 36). >>>>>>>>>>>> >>>>>>>>>>>> We will reconsider our decision to unlaunch CHIPS in WebView if >>>>>>>>>>>> we get feedback from the community that this would cause >>>>>>>>>>>> significant >>>>>>>>>>>> disruption. >>>>>>>>>>>> >>>>>>>>>>>> Behavior after deprecation: >>>>>>>>>>>> >>>>>>>>>>>> Cookies set with the Partitioned attribute on WebView will have >>>>>>>>>>>> the attribute ignored, and the cookie will be treated as >>>>>>>>>>>> unpartitioned. Any >>>>>>>>>>>> existing partitioned cookies created in WebView will be deleted to >>>>>>>>>>>> avoid >>>>>>>>>>>> conflicts across different partitions and the unpartitioned cookie >>>>>>>>>>>> jar. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This sounds like a pretty noticeable breakage. Are there any >>>>>>>>>>> estimates on how many apps/users/developers would be impacted by >>>>>>>>>>> this >>>>>>>>>>> change? >>>>>>>>>>> >>>>>>>>>>> Also, as a point of process, I think this may require an intent >>>>>>>>>>> to deprecate and remove in the chromestatus, although because this >>>>>>>>>>> is only >>>>>>>>>>> for WebView, I'm not entirely sure if there's a precedent. >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> Vlad >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> All other platforms besides WebView will still have the >>>>>>>>>>>> Partitioned attribute enabled. >>>>>>>>>>>> >>>>>>>>>>>> Timeline: >>>>>>>>>>>> >>>>>>>>>>>> We plan to turn down CHIPS on WebView in M127. >>>>>>>>>>>> >>>>>>>>>>>> We will relaunch CHIPS along with Android W, which will include >>>>>>>>>>>> changes to the Android CookieManager API, in 2025. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Dylan Cutler >>>>>>>>>>>> -- >>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>> Google Groups "blink-dev" group. >>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>>> it, send an email to blink-dev+...@chromium.org. >>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMCNMFQOPkYjRxrs68q%2BHxebt-JWCopZ6Rq9r0O80dQF8PWwRg%40mail.gmail.com >>>>>>>>>>>> >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMCNMFQOPkYjRxrs68q%2BHxebt-JWCopZ6Rq9r0O80dQF8PWwRg%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 on the web visit >>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMCNMFQ0N4hu_TF%2BBVC4MgRJgYoqmodqP%3Dg7L1dmE_GYqb1v3w%40mail.gmail.com >>>>>>>>>> >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMCNMFQ0N4hu_TF%2BBVC4MgRJgYoqmodqP%3Dg7L1dmE_GYqb1v3w%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 on the web visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMCNMFQObcMXRVrxrq%3DhHSWV8L9uxDpWhrSJ3xQDNb53RH6DVA%40mail.gmail.com >>>>>>>> >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMCNMFQObcMXRVrxrq%3DhHSWV8L9uxDpWhrSJ3xQDNb53RH6DVA%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 on the web visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2P-k%2B6fnpYDP8G0T%3DhQFfETKV7DedYb%3DohYpTKNMiOSzQ%40mail.gmail.com >>>>>>> >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2P-k%2B6fnpYDP8G0T%3DhQFfETKV7DedYb%3DohYpTKNMiOSzQ%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 on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEV-rjeO4FDkD8g%3D0hKbmUCd_%2BAfDBpAq3ydB98Tm8eDJfSBug%40mail.gmail.com >>>>>> >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEV-rjeO4FDkD8g%3D0hKbmUCd_%2BAfDBpAq3ydB98Tm8eDJfSBug%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 on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2N1H7XfZdmSWednDD8u0607ZE275HJf1-7ouJpOiLsMwg%40mail.gmail.com >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2N1H7XfZdmSWednDD8u0607ZE275HJf1-7ouJpOiLsMwg%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 on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMCNMFRwF4AjE6foyriSasv83dSQ6Gq_H%2BjKgoad1Dh2iNiEgw%40mail.gmail.com >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMCNMFRwF4AjE6foyriSasv83dSQ6Gq_H%2BjKgoad1Dh2iNiEgw%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 on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2Ne3Y5G%2BjYTFDwFEnkTwZfuwM%2BCZW4TWYJacNj1UA0oXg%40mail.gmail.com >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2Ne3Y5G%2BjYTFDwFEnkTwZfuwM%2BCZW4TWYJacNj1UA0oXg%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 on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_%3DQEHpPB0jSrWCtkMGG2b6VTvpsRFzSAoeWq1hjVgEUw%40mail.gmail.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_%3DQEHpPB0jSrWCtkMGG2b6VTvpsRFzSAoeWq1hjVgEUw%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 on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/30771590-489f-4e3a-8232-ce1077c5a9ef%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/30771590-489f-4e3a-8232-ce1077c5a9ef%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/32c66404-b1b2-4b6d-b303-b21486346c15n%40chromium.org.
