FWIW, this is already possible in an extension using the devtools protocol support. Fetch.continueRequest <https://chromedevtools.github.io/devtools-protocol/tot/Fetch/#method-continueRequest> lets you rewrite outbound requests to go to different destinations, modify headers, etc. It is what WebPageTest uses to allow you to point a production site to a dev instance (while keeping the origin the same as production). Extensions can have access to the devtools protocol so the existing extension should be able to be modified to do what you need it to do.
On Tue, Apr 16, 2024 at 2:48 PM David Benjamin <[email protected]> wrote: > Keep in mind also that cross-origin and same-origin requests generally > behave very differently on the web, not just in this specific way. So if > you're redirecting a portion of your origin in your dev environment, other > things will also behave differently. I recognize that's not how your > current dev environment works, and I gather none of the other differences > had impacted you thus far. But if we could enable a setup where they appear > at the same origin in the browser, your dev environment would more > accurately reflect production. > > For example, perhaps your backend server could proxy the frontend portions > from the real frontend, so that it would all appear at the same origin. I > think you wouldn't need any browser help to achieve that one. Or perhaps (I > don't work on DevTools, so I'm just spitballing) there could be some > DevTools features to configure some kind of transparent redirection of URL > patterns on the browser side. > > On Tue, Apr 16, 2024 at 2:28 PM Mike Taylor <[email protected]> > wrote: > >> It's possible that DevTools could support this use case, so I'd encourage >> you to a feature request at crbug.com/new. Thx >> On 4/16/24 6:29 AM, Tom Komarnicki wrote: >> >> Hi there, >> >> Here's the scenario I'm dealing with: >> >> I'm a backend developer working on a system with two distinct parts that >> typically don't intersect during development. The frontend is hosted >> online, and that's the only place I can access it. When something goes >> wrong on the backend I'm developing, I usually relied on chrome extensions >> re-routing my traffic to my localhost using a Chrome extension. This used >> to work fine, but recently, I've been encountering a 401 error due to the >> authorization header missing from the redirected request. >> >> Now, I'm left with two options: either manually extract data from the >> developer console or use tools like Fiddler and send requests via Postman >> to a locally hosted server. Both methods are quite time-consuming compared >> to the previous setup. >> >> I'm wondering if there's a way to configure Chrome to retain all headers >> on redirect, as it used to function before. This would streamline the >> debugging process significantly. >> >> Thanks! >> >> On Tuesday 16 April 2024 at 05:15:30 UTC+3 Yoav Weiss (@Shopify) wrote: >> >>> On Mon, Apr 15, 2024 at 2:18 PM Tom Komarnicki <[email protected]> >>> wrote: >>> >>>> Hey, >>>> >>>> Sorry for necro'ing this thread, I'm aware that this has been on the >>>> "done" pile for a while - and maybe it should've been brought up earlier, >>>> but how do you "disable" this feature ? It's making the BE dev exhaustingly >>>> painful, not being able to intercept requests and re-forward them to the >>>> local BE. >>>> Is there a flag, or whatnot, to re-enable the old flow ? >>>> >>> >>> Can you expand on the issue you're hitting? By "BE" do you mean backend? >>> Or something else? >>> >>> >>>> Thanks >>>> >>>> On Tuesday 5 September 2023 at 18:29:10 UTC+3 Chris Harrelson wrote: >>>> >>>>> LGTM3 >>>>> >>>>> On Tue, Sep 5, 2023 at 8:27 AM Mike Taylor <[email protected]> >>>>> wrote: >>>>> >>>>>> LGTM2 >>>>>> On 9/3/23 8:12 PM, Yoav Weiss wrote: >>>>>> >>>>>> LGTM1 >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Sep 4, 2023 at 2:24 AM Kenichi Ishibashi <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi, sorry for the long delay. >>>>>>> >>>>>>> The feature page >>>>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4470> >>>>>>> now shows sites that use Authorization header for cross-origin >>>>>>> redirects. I >>>>>>> randomly picked some of them and examined to see if they could work when >>>>>>> Chrome removes Authorization header up on cross-origin redirects. As >>>>>>> far as >>>>>>> I can tell, none of them are broken. We would like to ship this behind a >>>>>>> feature flag. >>>>>>> >>>>>> >>>>>> Thanks for the analysis! >>>>>> As you pointed out elsewhere, since our previous discussions on this >>>>>> thread, this was shipped >>>>>> <https://wpt.fyi/results/fetch/api/credentials/authentication-redirection.any.html?label=stable&label=master&aligned> >>>>>> by Firefox and Safari. >>>>>> I think that changes the risk calculus (from compat to interop) and >>>>>> makes shipping this (with a base feature just in case) the right choice. >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> On Fri, Sep 1, 2023 at 1:39 AM Ioan-Cristian Linte < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Any updates on this? >>>>>>>> Other browser have already made the change for some time so it's >>>>>>>> surprising that Chrome is so worried about breaking change. >>>>>>>> >>>>>>>> The Authorization propagating in cross origin redirects is causing >>>>>>>> a performance issue for us. Our server redirects to AWS S3 with >>>>>>>> pre-signed >>>>>>>> url and this will return 400 error as AWS S3 disallows specifying >>>>>>>> multiple >>>>>>>> authorizations (e.g. signature in url and Authorization header) in a >>>>>>>> request. Also the 400 error response includes a close connection >>>>>>>> header. To >>>>>>>> make this work, the web client checks for the 400 error and uses the >>>>>>>> response.url to make a new fetch request without the Authorization >>>>>>>> header. >>>>>>>> Because the previous connection was closed this incurs the cost of >>>>>>>> initiating a new connection. >>>>>>>> >>>>>>>> On Wednesday, June 28, 2023 at 6:34:42 PM UTC+3 Yoav Weiss wrote: >>>>>>>> >>>>>>>>> Friendly ping! :) Any news on UKM data here? >>>>>>>>> >>>>>>>>> On Wednesday, April 5, 2023 at 10:53:41 AM UTC+2 Yoav Weiss wrote: >>>>>>>>> >>>>>>>>>> Sounds great, thanks!! :) >>>>>>>>>> >>>>>>>>>> On Wed, Apr 5, 2023 at 10:44 AM Kenichi Ishibashi < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Yoav, >>>>>>>>>>> >>>>>>>>>>> Sorry I haven't sent an update in this thread. (1) sounds >>>>>>>>>>> reasonable. I added the usercounters to UKM a few weeks ago and I'm >>>>>>>>>>> waiting >>>>>>>>>>> for data. I will report back after manual inspections are done. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Apr 5, 2023 at 5:14 PM Yoav Weiss <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Friendly ping on the above :) Does (1) sound reasonable from >>>>>>>>>>>> your perspective? >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Mar 15, 2023 at 7:16 PM Yoav Weiss < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> The way I see this, given that the usecounter is an order of >>>>>>>>>>>>> magnitude higher than what we can consider trivial, we have 3 >>>>>>>>>>>>> options: >>>>>>>>>>>>> 1) Add the usecounters to UKM >>>>>>>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:components/page_load_metrics/browser/observers/use_counter/ukm_features.cc;l=32?q=usecounters%20ukm&ss=chromium>, >>>>>>>>>>>>> run an analysis on early data to extract URLs that use this, and >>>>>>>>>>>>> randomly >>>>>>>>>>>>> sample those for manual inspection. >>>>>>>>>>>>> 2) Wait for the HTTPArchive crawl to run with this usecounter, >>>>>>>>>>>>> assuming that unauthed landing pages will trigger it. >>>>>>>>>>>>> 3) Run an HA query that tries to find cross-origin redirects >>>>>>>>>>>>> with Auth headers. I'm not sure how easy (or feasible) that would >>>>>>>>>>>>> be, but >>>>>>>>>>>>> Rick and Pat would know >>>>>>>>>>>>> >>>>>>>>>>>>> To me, (1) seems to be the easiest, and with the least amount >>>>>>>>>>>>> of potential bias (all pages vs. unauthed landing pages). >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Mar 14, 2023 at 9:45 PM Patrick Meenan < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Do we expect the Authorization header to be something that >>>>>>>>>>>>>> the HTTP Archive triggers in a way that the feature will >>>>>>>>>>>>>> trigger? Since >>>>>>>>>>>>>> they are all unauthenticated single page loads, it feels like >>>>>>>>>>>>>> it's unlikely >>>>>>>>>>>>>> to be something that we hit. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Mar 14, 2023 at 4:37 PM Patrick Meenan < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Looks like the feature flag was added Feb 16 >>>>>>>>>>>>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/4235597> >>>>>>>>>>>>>>> which >>>>>>>>>>>>>>> looks like it should have made the 112 branch point >>>>>>>>>>>>>>> <https://chromiumdash.appspot.com/schedule>. If we hold >>>>>>>>>>>>>>> the April crawl back a couple of days and start it on the 4th >>>>>>>>>>>>>>> after stable >>>>>>>>>>>>>>> is released then we can pick it up in April, otherwise it would >>>>>>>>>>>>>>> show up >>>>>>>>>>>>>>> mid-crawl. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Mar 14, 2023 at 4:24 PM Rick Viscomi < >>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Am I reading the feature page >>>>>>>>>>>>>>>> <https://chromestatus.com/feature/5195900413018112> correctly >>>>>>>>>>>>>>>> that it'll land in stable version 113? If so, HTTP Archive >>>>>>>>>>>>>>>> wouldn't pick >>>>>>>>>>>>>>>> that up until the May crawl. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> cc @Patrick Meenan to keep me honest >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mon, Mar 13, 2023 at 12:19 AM Yoav Weiss < >>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> It's possible that we need to wait for the next HA run to >>>>>>>>>>>>>>>>> get actual examples. >>>>>>>>>>>>>>>>> +Rick Viscomi would know.. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mon, Mar 13, 2023 at 12:28 AM Kenichi Ishibashi < >>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thank you Yoav for the suggestion. I couldn't find sample >>>>>>>>>>>>>>>>>> URLs from the HTTPArchive data (feature usage >>>>>>>>>>>>>>>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4470>). >>>>>>>>>>>>>>>>>> I'll add a feature flag to prepare for reverting this change >>>>>>>>>>>>>>>>>> if breakage is >>>>>>>>>>>>>>>>>> problematic. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Fri, Mar 10, 2023 at 7:06 PM Yoav Weiss < >>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> One option to tighten the potential for breakage would >>>>>>>>>>>>>>>>>>> be to e.g. sample 10 URLs that are hitting that usecounter >>>>>>>>>>>>>>>>>>> (e.g. from the >>>>>>>>>>>>>>>>>>> HTTPArchive data), and test them manually to see how many >>>>>>>>>>>>>>>>>>> of them would >>>>>>>>>>>>>>>>>>> break once this change is applied. Based on the number >>>>>>>>>>>>>>>>>>> you'd get, we can >>>>>>>>>>>>>>>>>>> estimate the magnitude of breakage we can expect to see in >>>>>>>>>>>>>>>>>>> the wild. >>>>>>>>>>>>>>>>>>> Another option would be to roll this out with a base >>>>>>>>>>>>>>>>>>> feature flag (that we'd want anyway) and be ready to revert >>>>>>>>>>>>>>>>>>> if breakage is >>>>>>>>>>>>>>>>>>> more than we'd like. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Combining those two options is probably safest. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Fri, Mar 10, 2023 at 8:51 AM Kenichi Ishibashi < >>>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Use counter reports 0.022%. My guess is that most usage >>>>>>>>>>>>>>>>>>>> happens accidentally but we are not sure. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> API owners, should we do a reverse OT? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Fri, Feb 17, 2023 at 9:38 AM Kenichi Ishibashi < >>>>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Quick update, we added a use counter to see how often >>>>>>>>>>>>>>>>>>>>> this could happen. I'll get back once we have data. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Wed, Feb 8, 2023 at 11:51 PM Yoav Weiss < >>>>>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Any use counters on how often this happens? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Thursday, February 2, 2023 at 8:58:35 AM UTC+1 >>>>>>>>>>>>>>>>>>>>>> Kenichi Ishibashi wrote: >>>>>>>>>>>>>>>>>>>>>> Contact [email protected] >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Specificationhttps://fetch.spec.whatwg.org/ >>>>>>>>>>>>>>>>>>>>>> #http-redirect-fetch >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Summary >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Remove Authorization header on cross origin redirects >>>>>>>>>>>>>>>>>>>>>> to scope a developer-controlled Authorization header to >>>>>>>>>>>>>>>>>>>>>> the origin of the >>>>>>>>>>>>>>>>>>>>>> initial request. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Blink componentBlink>Loader >>>>>>>>>>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELoader> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> TAG review >>>>>>>>>>>>>>>>>>>>>> Not applicable, the spec has been already updated. >>>>>>>>>>>>>>>>>>>>>> https://github.com/whatwg/fetch/pull/1544 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> TAG review statusNot applicable >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Risks >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Low. All browser vendors agreed with this change. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> *Gecko*: Shipping (https://bugzilla.mozilla.org/ >>>>>>>>>>>>>>>>>>>>>> show_bug.cgi?id=1802086) >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Do we know if they ran into any compat issues when >>>>>>>>>>>>>>>>>>>>>> shipping this? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> None I'm aware of. I checked the bug and related >>>>>>>>>>>>>>>>>>>>> issues in GitHub but I didn't find anything. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> *WebKit*: Shipped/Shipping ( >>>>>>>>>>>>>>>>>>>>>> https://bugs.webkit.org/show_bug.cgi?id=230935) >>>>>>>>>>>>>>>>>>>>>> Historically Safari always removed Authorization headers >>>>>>>>>>>>>>>>>>>>>> even for the same >>>>>>>>>>>>>>>>>>>>>> origin redirects. Recently the behavior has changed to >>>>>>>>>>>>>>>>>>>>>> preserve them on >>>>>>>>>>>>>>>>>>>>>> same origin redirects. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> That's encouraging in terms of lack of potential >>>>>>>>>>>>>>>>>>>>>> reliance on these headers. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> *Web developers*: No signals >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> *Other signals*: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> WebView application risks >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> N/A >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Debuggability >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Web Developers can use DevTools network panel to see >>>>>>>>>>>>>>>>>>>>>> the actual request headers. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 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/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>>>>>>>>>>>>>> ?Yes >>>>>>>>>>>>>>>>>>>>>> https://wpt.fyi/results/xhr/ >>>>>>>>>>>>>>>>>>>>>> xhr-authorization-redirect. >>>>>>>>>>>>>>>>>>>>>> any.html?label=master&label=experimental >>>>>>>>>>>>>>>>>>>>>> https://wpt.fyi/results/fetch/api/credentials/ >>>>>>>>>>>>>>>>>>>>>> authentication-redirection. >>>>>>>>>>>>>>>>>>>>>> any.html?label=experimental >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Flag nameNot applicable >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Requires code in //chrome?False >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Tracking bughttps://bugs.chromium.org/p/ >>>>>>>>>>>>>>>>>>>>>> chromium/issues/detail?id=1393520 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Estimated milestones >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> M112 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Anticipated spec changes >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> The spec has been already updated. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> https://github.com/whatwg/fetch/issues/944 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>>>>>>>>>>>> https://chromestatus.com/feature/5195900413018112 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 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 [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWf-jyg-N2Y%2BuGXp6aWAHZA%2BifqOw_Cki7M3UaV1QV9Cg%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWf-jyg-N2Y%2BuGXp6aWAHZA%2BifqOw_Cki7M3UaV1QV9Cg%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 [email protected]. >>>>>> >>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/01f78357-99e8-4233-8125-1233bd8bc786%40chromium.org >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/01f78357-99e8-4233-8125-1233bd8bc786%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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f208e74a-4f78-48c4-bdff-f4a847d08447%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f208e74a-4f78-48c4-bdff-f4a847d08447%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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w7js9v-67G%2BVp%3DB8dpi%3DFMP7Ac%2BFRWZ2snDwsOHcZrhJA%40mail.gmail.com.
