While it would obviously be better for the header to only be sent once (less bytes transmitted), I don't think sending it twice should cause a problem so long as both headers are the same, e.g. they both specify "?0". If you're seeing the problem with two headers but not with one, then that's a bug. In that case filing a bug report at crbug.com, including as much information as possible, would be appreciated.
I tried this with a simple test case on my own server, and it seems to work fine. [image: GoogleAnimated.gif] ⭘ W. James MacLean ⭘ Software Engineer ⭘ Google Waterloo <http://www.google.ca/about/careers/locations/waterloo/#tab=tab-gallery>, Canada On Fri, 6 Oct 2023 at 01:41, Madanagopal Damodharan <dmadanago...@gmail.com> wrote: > Thanks James. We are able to add the header from our server's servlet > filter code. It now appends the header for each response including static > html files. It seems to be working fine so far. There are instances where > it still gets blocked when a link is opened on new window. I believe we > need to make sure the new window response contains the header as well, > right? Also, if the header gets duplicated i.e. if the response contains > the same header twice, it does not work. It looks as if the header is not > sent at all. Is this how it is supposed to behave? > > On Monday, 25 September 2023 at 20:23:51 UTC+5:30 W. James MacLean wrote: > >> No, I think you need to get the server to send the header. Once you get >> as far as the meta tags, the origin's isolation state has already been >> decided. I'm not an expert on servers, but my experience in specifying >> headers to be sent with static pages is to edit the .htaccess file in the >> directory with the content, and include >> >> HEADER add Origin-Agent-Cluster: ?0 >> >> But the exact details will depend on your setup. >> >> For Apache: https://httpd.apache.org/docs/2.4/howto/htaccess.html >> >> [image: GoogleAnimated.gif] >> >> ⭘ W. James MacLean >> >> ⭘ Software Engineer >> >> ⭘ Google Waterloo >> <http://www.google.ca/about/careers/locations/waterloo/#tab=tab-gallery>, >> Canada >> >> On Tue, 19 Sept 2023 at 23:40, Madanagopal Damodharan < >> dmadan...@gmail.com> wrote: >> >>> This helped us identify the response that did not have the header. We >>> noticed that we have a static html called signon.html as our first entry >>> into the application. Since this is a static html, our servlet changes to >>> add response header does not hit when users invoke this signon.html. I >>> think Chrome puts this origin into Origin-keyed cluster at this point and >>> hence when users login and encounter document.domain, they get the error >>> blocked frame error. >>> >>> meta tags with http-equiv does not recognize this custom response header >>> Origin-Agent-Cluster. Is there a way to add response headers in a static >>> html page response? >>> >>> On Wednesday, 13 September 2023 at 22:49:00 UTC+5:30 W. James MacLean >>> wrote: >>> >>>> Perhaps try this: >>>> 1) open a new tab page (or about:blank if you prefer) >>>> 2) right-click and select "Inspect" at the bottom of the popup menu >>>> 3) in the DevTools menu at the top, click "Network" >>>> 4) then check the "Preserve Logs" checkbox in the row under that menu >>>> 5) finally, manually type the url for your app/site in the url bar >>>> >>>> As your content loads, the DevTools window will populate with an (in >>>> order) list of all the network transactions. You can click on each element >>>> in the list and see the response headers for each request. This should help >>>> you determine which request is missing the Origin-Agent-Cluster:?0 header >>>> and causing the origin keying to be applied for the tab. >>>> >>>> Let me know if that helps. >>>> >>>> >>>> [image: GoogleAnimated.gif] >>>> >>>> ⭘ W. James MacLean >>>> >>>> ⭘ Software Engineer >>>> >>>> ⭘ Google Waterloo >>>> <http://www.google.ca/about/careers/locations/waterloo/#tab=tab-gallery>, >>>> Canada >>>> >>>> >>>> >>>> On Wed, 13 Sept 2023 at 12:44, Madanagopal Damodharan < >>>> dmadan...@gmail.com> wrote: >>>> >>>>> An update on the issue I am facing: We have a static html in web >>>>> server called signon.html. Users access this static html page first which >>>>> has a refresh directive with content=1. As soon as the user invokes this >>>>> html page first time from the origin, this redirects to a login form page. >>>>> This response contains the header too. But still chrome console says the >>>>> origin was in origin-keyed cluster. If I change the refresh directive >>>>> content=5, it takes 5 sec to redirect from signon.html to login form, this >>>>> time I don't get the console warning. Now I can login and dont see any >>>>> errors. I am not sure why the refresh directive 5 works but not 1. Is it >>>>> because Chrome could not capture request and place the origin in >>>>> appropriate cluster within its 1 second? >>>>> >>>>> Modified the CONTENT=5 from CONTENT=1 in the below line to get it >>>>> working - <meta HTTP-EQUIV='Refresh' CONTENT='5; >>>>> URL=../psp/ps/?cmd=login'> >>>>> >>>>> Any thoughts? >>>>> >>>>> On Sunday, 10 September 2023 at 20:53:42 UTC+5:30 Madanagopal >>>>> Damodharan wrote: >>>>> >>>>> Thanks for response. In my case, I am getting the error when a new tab >>>>> is opened from an existing tab. My existing tab did not throw this error >>>>> whereas the new tab shows the error on the first request itself. So based >>>>> on what you mentioned, my parent tab should have been part of Origin-Keyed >>>>> cluster, right? I am seeing console warning as follows on my new tab that >>>>> was opened from an existing tab: >>>>> >>>>> "The page did not request an Origin-Keyed agent cluster but was put in >>>>> one anyway because the origin had previously been placed in an >>>>> origin-keyed >>>>> agent cluster. Update your headers to uniformly request origin-keying for >>>>> all pages on the origin" >>>>> >>>>> I am currently trying to figure out which server response did not have >>>>> the header ""Origin-Agent-Cluster: ?0" that led my pages to get in >>>>> origin-keyed cluster. Is there a way (debug tool etc) I can check which >>>>> response decided Origin-Keying? I think this will be crucial for >>>>> applications to debug the issues. >>>>> >>>>> One other question: My parent tab has a wss (web socket) request that >>>>> does not have its response with this OAC header. Do we need the header in >>>>> wss response as well? >>>>> >>>>> >>>>> On Thursday, 7 September 2023 at 23:00:32 UTC+5:30 W. James MacLean >>>>> wrote: >>>>> >>>>> If the application is getting loaded inside a tab that has previously >>>>> loaded other pages from the same origin (i.e. pages not part of the app) >>>>> that do not have the header, then for consistency the new loads will get >>>>> OAC isolation even if the header is present. Essentially, the first time >>>>> the tab loads anything from a particular origin, that determines how it >>>>> will treat the origin for the remainder of the tab's lifetime. This >>>>> consistency will also extend to other tabs opened by the tab (as they live >>>>> in the same "BrowsingInstance"). >>>>> >>>>> Also, there may be issues where pages can be loaded from cache without >>>>> the ?0 version of the header, so two useful steps would be >>>>> >>>>> 1) Clear the cache, and >>>>> 2) open the app directly in a newly opened tab. >>>>> >>>>> I don't think the header needs to be sent on script/css/image >>>>> requests, as they're used within the context of the .html resource that >>>>> should have the header. >>>>> >>>>> [image: GoogleAnimated.gif] >>>>> >>>>> ⭘ W. James MacLean >>>>> >>>>> ⭘ Software Engineer >>>>> >>>>> ⭘ Google Waterloo >>>>> <http://www.google.ca/about/careers/locations/waterloo/#tab=tab-gallery>, >>>>> Canada >>>>> >>>>> >>>>> >>>>> On Thu, 7 Sept 2023 at 11:27, Madanagopal Damodharan < >>>>> dmadan...@gmail.com> wrote: >>>>> >>>>> Hi All, >>>>> >>>>> Is the feature launched in Chrome 115 as updated in >>>>> https://developer.chrome.com/blog/document-domain-setter-deprecation? >>>>> I have some of the customers reporting inconsistent behavior. Our >>>>> application sends "Origin-Agent-Cluster: ?0" in response headers to >>>>> opt-out of Origin Agent clusters since we rely on document.domain. Is this >>>>> header needed only on document requests or even for script, image, css >>>>> requests? For some customer, their pages get inside origin-keyed cluster >>>>> even though the responses contain the header "Origin-Agent-Cluster: >>>>> ?0". Is there a bug in the chrome behavior that puts pages in specific >>>>> cluster? How do we debug what caused the pages to get inside origin-keyed >>>>> cluster? >>>>> >>>>> On Friday, 26 May 2023 at 20:55:52 UTC+5:30 Eiji Kitamura wrote: >>>>> >>>>> @Maud Nalpas is taking over the DevRel work. >>>>> >>>>> On Sat, May 27, 2023 at 12:21 AM Rick Byers <rby...@chromium.org> >>>>> wrote: >>>>> >>>>> Thanks for the update Daniel. Still LGTM. Good luck! >>>>> >>>>> On Fri, May 26, 2023 at 10:25 AM Daniel Vogelheim <voge...@google.com> >>>>> wrote: >>>>> >>>>> Hello all, it's been a while... The bug reports should now be >>>>> resolved, and we'd like to have another go at this in the M115 milestone. >>>>> That is: Remain at 50% on beta; starting with 115 ramp up on stable to 1% >>>>> / >>>>> 10% / 50% / 100%, every 14d. Let's hope it sticks this time. >>>>> >>>>> Daniel >>>>> >>>>> On Fri, Mar 31, 2023 at 3:54 PM Daniel Vogelheim <voge...@google.com> >>>>> wrote: >>>>> >>>>> Hello all, I'm afraid I have to delay this a bit more. :( >>>>> >>>>> We have a bug report (tracked in crbug.com/1429587) that breaks >>>>> existing apps. The important thing here is that it does not break >>>>> document.domain setting and subsequent cross-origin access, but that >>>>> instead -- if the conditions are just right; or arguably just wrong -- the >>>>> app can get into a state where same-origin accesses are mistakenly >>>>> blocked. >>>>> Apparently an app can get into a state where frames within the same page >>>>> are inconsistently assigned to agent clusters (i.e., frames in the same >>>>> origin end up in different processes), and thus subsequent accesses within >>>>> that origin may fail. >>>>> >>>>> My plan right now is to leave this on at 50% beta, but to not proceed >>>>> to any stable releases at any percentage. I'll update this thread when I >>>>> have a better handle on the bug and can suggest a good way to proceed. >>>>> >>>>> On Fri, Jan 20, 2023 at 5:12 PM Eiji Kitamura <age...@google.com> >>>>> wrote: >>>>> >>>>> FYI, the enterprise bit has been added to the article. >>>>> https://developer.chrome.com/blog/immutable-document-domain/ >>>>> >>>>> On Tue, Jan 17, 2023 at 1:21 AM Brandon Heenan <bhe...@google.com> >>>>> wrote: >>>>> >>>>> We'll make the update in the enterprise release notes too. Thanks for >>>>> keeping us in the loop >>>>> >>>>> On Mon, Jan 16, 2023 at 9:46 AM Rick Byers <rby...@chromium.org> >>>>> wrote: >>>>> >>>>> Thanks so much Eiji! >>>>> >>>>> On Mon, Jan 16, 2023 at 3:06 AM Eiji Kitamura <age...@google.com> >>>>> wrote: >>>>> >>>>> I've updated the blog post >>>>> <https://developer.chrome.com/blog/immutable-document-domain/> stating >>>>> Chrome 111 is where we ship the feature, but looks like it's rolling out >>>>> through 111 and 112? >>>>> I'll update the blog post to mention >>>>> `OriginAgentClusterDefaultEnabled` enterprise policy. >>>>> >>>>> >>>>> On Sat, Jan 14, 2023 at 1:37 AM Rick Byers <rby...@chromium.org> >>>>> wrote: >>>>> >>>>> Thanks for the update Daniel, good luck! >>>>> >>>>> In case others, like me, have missed or forgotten the long history of >>>>> this difficult deprecation and what it means for web developers, this blog >>>>> post is a good summary >>>>> <https://developer.chrome.com/blog/immutable-document-domain/>. One >>>>> critical thing it doesn't mention, but probably should, is that the >>>>> OriginAgentClusterDefaultEnabled >>>>> enterprise policy >>>>> <https://chromeenterprise.google/policies/#OriginAgentClusterDefaultEnabled> >>>>> can also be used to revert the default on managed devices (though it looks >>>>> like the launching milestone needs to be updated there too). >>>>> >>>>> Rick >>>>> >>>>> On Fri, Jan 13, 2023 at 9:53 AM 'Daniel Vogelheim' via blink-dev < >>>>> blin...@chromium.org> wrote: >>>>> >>>>> Hello all, >>>>> >>>>> We've now handled the bugs we've discovered, and I would like to make >>>>> another attempt at launching. I'll follow the plan that was approved here, >>>>> but two milestones later: Launch to 50% beta in M111 (or late M110, if I >>>>> can still catch a bit of that release cycle), and then ramp on stable once >>>>> M112 is out. >>>>> >>>>> >>>>> On Wed, Dec 14, 2022 at 6:36 PM Daniel Vogelheim <voge...@google.com> >>>>> wrote: >>>>> >>>>> Hello all, >>>>> >>>>> An update: Unfortunately we have discovered a bug with this feature, >>>>> just as I was getting ready to enable it. The bug also affects pages that >>>>> have not even set document.domain. Since I have now missed a substantial >>>>> portion of the 109 beta cycle I'd like to delay the roll out once more, >>>>> and >>>>> shift it by one milestone (or two; depending on when everything is fixed). >>>>> >>>>> On the positive side: Recently the last of the previously identified >>>>> big document.domain users, that together accounted for about 50% of >>>>> remaining usage, has dropped their usage. So current usage is lower than >>>>> previously reported. See the usage dip around late November at >>>>> deprecate.it (1st graph). >>>>> >>>>> On Thu, Nov 10, 2022 at 5:42 PM Mike Taylor <mike...@chromium.org> >>>>> wrote: >>>>> >>>>> LGTM3 >>>>> >>>>> On 11/10/22 11:18 AM, Chris Harrelson wrote: >>>>> >>>>> LGTM2 >>>>> >>>>> On Thu, Nov 10, 2022, 4:19 AM Yoav Weiss <yoav...@chromium.org> wrote: >>>>> >>>>> LGTM1 to roll this out to 50% of Beta/Dev/Canary for either M108 or >>>>> M109, and carefully roll this out for M110, once it hits stable. >>>>> >>>>> On Wed, Nov 9, 2022 at 7:05 PM Daniel Vogelheim <voge...@google.com> >>>>> wrote: >>>>> >>>>> On Wed, Nov 9, 2022 at 6:10 PM Mike Taylor <mike...@chromium.org> >>>>> wrote: >>>>> >>>>> On 10/27/22 11:49 PM, 'Daniel Vogelheim' via blink-dev wrote: >>>>> >>>>> Hello all, >>>>> >>>>> The approval for the Intent To Ship for Origin Isolation By Default / >>>>> Deprecate document.domain >>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/_oRc19PjpFo/> >>>>> asks for a separate intent for the actual default change >>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/_oRc19PjpFo/m/Ybgtf3JfAQAJ>. >>>>> This is that separate intent. >>>>> >>>>> A summary of what happened so far: >>>>> >>>>> - Shipping Origin Isolation by Default (and thereby deprecating >>>>> document.domain) has security benefits, but compatibility risk. >>>>> >>>>> - We added warnings to the developer console and issues panel, >>>>> published a blog post, and engaged in direct outreach. This has resulted >>>>> in >>>>> substantial, measurable reduction of usage. Some sites keep using >>>>> document.domain, but have mitigated the deprecation with other means. This >>>>> makes the risk difficult to measure. >>>>> >>>>> - Sampling of sites with document.domain usage and manual inspection >>>>> yields a potential breakage estimate at ~0.015% of page views. >>>>> >>>>> What we're asking for here is: >>>>> >>>>> - Enable the feature at 50% for beta (+ dev + canary) during M109, as >>>>> a "last call" for web site authors. >>>>> >>>>> This sounds like a good idea. Is there any reason we couldn't go to >>>>> 50% in M108 as well (or are you trying to avoid breakage over the winter >>>>> holidays)? >>>>> >>>>> No reason. I'd be happy to go to beta as soon as I receive the lgtms. >>>>> I had conservatively budgeted that to be 109. :-) >>>>> >>>>> >>>>> Another question: do we have enterprise policies available for this >>>>> change? >>>>> >>>>> >>>>> Yes; the policy is here: OriginAgentClusterDefaultEnabled >>>>> <https://source.chromium.org/chromium/chromium/src/+/main:components/policy/resources/templates/policy_definitions/Miscellaneous/OriginAgentClusterDefaultEnabled.yaml> >>>>> >>>>> >>>>> - Launch on stable on M110. (~ Feb '23, so >12 weeks out from today) >>>>> >>>>> >>>>> ------------------------ >>>>> >>>>> Contact emails va...@chromium.org, voge...@chromium.org >>>>> Specification Explainer: >>>>> https://github.com/mikewest/deprecating-document-domain HTML Spec >>>>> draft: https://github.com/whatwg/html/compare/main...otherdaniel:dd >>>>> API spec Yes >>>>> Summary >>>>> >>>>> This is a follow-on to the Intent to Ship: Origin Isolation By >>>>> Default / Deprecate document.domain >>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/_oRc19PjpFo/>. >>>>> We'd >>>>> like to ship this in M110, stable. >>>>> >>>>> Summary (of the underlying change) Change the default behavior of the >>>>> Origin-Agent-Cluster: header / document.domain settability. >>>>> Presently, pages within Chromium have site-keyed agent clusters by >>>>> default, unless the Origin-Agent-Cluster: header is explicitly set to >>>>> true. >>>>> This accommodates pages or frames which want to access each other's state, >>>>> despite being on different origins (but within a site). This is fine for >>>>> any pages that wish to do so, but because a page *might* set >>>>> document.domain later on, Chromium currently must use site-keyed agent >>>>> clusters for *all* pages by default even though the overwhelming majority >>>>> of pages do not ever make use of this (mis-)feature. In turn, this >>>>> requires >>>>> Chromium to use sites as the basis for renderer process isolation (via >>>>> Site >>>>> Isolation), which exposes origins to same-site but cross-origin attacks >>>>> involving compromised renderer processes or the "Spectre" family of >>>>> side-channel attacks. >>>>> This proposal changes the default behaviour of Origin-Agent-Cluster. >>>>> From a developer's point of view, the new default matches >>>>> "Origin-Agent-Cluster: ?1". The initial implementation will use >>>>> origin-keyed agent clusters for all (non-opted out) origins, without >>>>> changing how many processes Chromium creates. Over time, we can then adapt >>>>> Chromium's isolation strategy towards origin-keyed processes without >>>>> further affecting web-visible behaviour. >>>>> The developer-visible aspect of this is that for pages with >>>>> origin-keyed agent clusters, document.domain is no longer settable. Thus, >>>>> we have marked this intent as a deprecation. >>>>> Note that this proposal is about the default. Both modes - site-keyed >>>>> or origin-keyed agent clusters - remain available to any site, but >>>>> origin-keyed agent clusters change from opt-in to opt-out. The current >>>>> behaviour remains available by setting "Origin-Agent-Cluster: ?0". >>>>> Blink component Blink>SecurityFeature >>>>> TAG review https://github.com/w3ctag/design-reviews/issues/564 >>>>> Risks: Interoperability and Compatibility >>>>> >>>>> There are compatibility risks, which we have reduced with outreach and >>>>> warnings, and we want to mitigate further by launching at 50% of beta >>>>> first. An extended discussion of the risk (including attempts at >>>>> quantitative assessment) can be found in the original intent to ship >>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/_oRc19PjpFo/>. >>>>> >>>>> Gecko: Standards position request >>>>> <https://github.com/mozilla/standards-positions/issues/601>. ("Worth >>>>> prototyping") >>>>> >>>>> WebKit: >>>>> https://lists.webkit.org/pipermail/webkit-dev/2021-December/032067.html >>>>> (No signals.) >>>>> >>>>> Web developers: No signals. >>>>> >>>>> Activation - Deprecation plan >>>>> M109: Enable "Origin Agent Cluster by Default" for 50% of page loads >>>>> on beta, dev, and canary. >>>>> >>>>> M110: Enable "Origin Agent Cluster by Default" on stable. >>>>> Security This change should be security-positive, since setting >>>>> document.domain will not have any impact on the origin of the document any >>>>> more. >>>>> Debuggability A deprecation warning has been added to DevTools >>>>> console and to the issues panel in M98. This warning will file a >>>>> deprecation report as well using the Reporting API, if so configured. >>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>> Mac, Linux, Chrome OS, Android, and Android WebView)? Yes >>>>> Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>> ? This is covered by Origin-keyed Agent Cluster tests >>>>> <https://wpt.live/html/browsers/origin/origin-keyed-agent-clusters/>. >>>>> Tracking bug https://crbug.com/1139851 >>>>> Launch bug https://crbug.com/1246823 >>>>> Link to entry on the Chrome Platform Status >>>>> https://chromestatus.com/feature/5428079583297536 (document.domain >>>>> setter deprecation) https://chromestatus.com/features/5683766104162304 >>>>> (Origin-keyed agent clusters) >>>>> -- >>>>> 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/CALG6KPNEMgvrOehp5%2Bf48yQ62pY3xqXqATPNxWZ6aYQ%2BXeHHAg%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPNEMgvrOehp5%2Bf48yQ62pY3xqXqATPNxWZ6aYQ%2BXeHHAg%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/CAL5BFfW0vt%2BzXxGf_f7YBF2Lq1K1y5F_VJMtK6whuSiQX9_t3g%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfW0vt%2BzXxGf_f7YBF2Lq1K1y5F_VJMtK6whuSiQX9_t3g%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/CALG6KPPFMpseckt22K5bd%2BRsctwWihiwCdSA9vvCTZw_tOtT5A%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPPFMpseckt22K5bd%2BRsctwWihiwCdSA9vvCTZw_tOtT5A%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> >>>>> >>>>> -- >>>>> Eiji Kitamura / えーじ | Developer Advocate | @agektmr >>>>> <https://twitter.com/agektmr> | Office Location: Tokyo Shibuya >>>>> >>>>> >>>>> >>>>> -- >>>>> Eiji Kitamura / えーじ | Developer Advocate | @agektmr >>>>> <https://twitter.com/agektmr> | Office Location: Tokyo Shibuya >>>>> >>>>> >>>>> >>>>> -- >>>>> Eiji Kitamura / えーじ | Developer Advocate | @agektmr >>>>> <https://twitter.com/agektmr> | Office Location: Tokyo Shibuya >>>>> >>>>> -- >>>>> 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/0aa8ac1f-6b52-425f-8e25-f09f55c9e0fdn%40chromium.org >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0aa8ac1f-6b52-425f-8e25-f09f55c9e0fdn%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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADAYvoc24scGp3XHZrC%3Dpg7zaUU5OeRLaM9NbS-hbvLRJ06XHQ%40mail.gmail.com.
