I think Chrome does not send security cookies in POST request, but I'm not so sure

When i inject scripts from extension to page, all works fine, but in content scripts it doesn't work, now i doing post request on inject script and send result to content script(

Thanks for filing the issue

@Reporter:
Can you please provide the sample extension to test this issue which helps us to triage it in a better way from TE end. 

Thanks!

He dug deeper and found out that problem with "Lax" cookies they not send in content scripts, but in inject scripts its work. And in previous versions of Chrome "Lax" cookies sended from content scripts.

Attach sample extension with request to my test server. You can go for this link http://avitoadm.ru/test/cookies/test.html and in "Network" so all differents.

Here you can so screens of requests:
- GET request, inject script http://joxi.ru/5md3e3JUvMxwar
- POST request, inject script http://joxi.ru/n2YVjV3cj9YEMA
- GET request, content script http://joxi.ru/v29nVn6iGnEx5A
- POST request, content script http://joxi.ru/12MNvNqC4Y3ayA

Cookies settings from browser: http://joxi.ru/4Ak9j94fM9x6pm

Deleted: text extension.zip 29.5 KB

text extension.zip 29.5 KB Download

Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Unable to reproduce the issue on reported chrome version 63.0.3239.108 and on the latest canary 65.0.3304.0 using Ubuntu 14.04 with the below mentioned steps.
1. Launched chrome
2. Download the zip file and added the extension provided in comment#7 by reporter
3. Navigated to link http://avitoadm.ru/test/cookies/test.html
4. Inspected hte page by clicking F12
5. Dev tools>Network tab>F5
6. Clicked on test.php?from=INJECT-> Preview tab
7. Clicked on test.php?from=CONTENT-> Preview tab 
8. It says "403 Forbidden".

Attaching the screen cast of the same. 

@Reporter: Could you please check the screen cast and let us know if we have missed any steps in reproducing the issue. Along with that could you please mention whether the issue is specific to OS Mint 18.3. Any further inputs from your end helps us to triage the issue in a better way.

Thanks!

Deleted: 796480-screen-cast.mp4 2.6 MB

	796480-screen-cast.mp4 2.6 MB View Download

Oh. sorry, I have an IP limitation on the server and forgot to remove it from this path for php.

Try now, i remove restrictions on ip

Thank you for providing more feedback. Adding requester "vamshi.kommuri@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

aelsergeev@ Thanks for the feedback.

Tested this issue on Ubuntu 14.04 and Windows 10 using the latest Stable 63.0.3239.108 and Canary 65.0.3305.0 following the steps mentioned in comment #10.

In Devtools, on clicking test.php?from=INJECT / test.php?from=CONTENT and test.php, can see data in the preview tab.
Attached is the screen cast for reference.

Can you please check and confirm if this is the expected behaviour or if anything is missed from our end in reproducing the issue.

Thanks...

Deleted: 796480.webm 5.5 MB

	796480.webm 5.5 MB View Download

Yes, as you can see "Content script" for POST request not get "Lax" cookies, when send request, but in "Inject script" all fine.

It's a big problem, i can't send POST request if site have "Lax" cookies. It must be performed for both or not at all.

Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

aelsergeev@ Thanks for the feedback.

Able to reproduce this issue on Ubuntu 14.04 and Mac OS 10.12.6 using the latest Stable 63.0.3239.108.
Note: Can observe different behavior on Windows 10 for Post Content and Post Inject methods on the latest Stable 63.0.3239.108.
Attached are the screen casts for reference.

Bisect Information:
====================
Good Build : 63.0.3239.88
Bad Build  : 63.0.3239.90

As both the good and bad builds are branch builds, providing the Changelog URL from Omahaproxy.

Changelog URL:
---------------
https://chromium.googlesource.com/chromium/src/+log/63.0.3239.88..63.0.3239.90?pretty=fuller&n=10000

From the above Changelog URL, suspecting the below change for this issue.
Reviewed-on: https://chromium-review.googlesource.com/783826

creis@ Can you please check if this issue is related to your change, else help us in assigning to the right owner.

Adding ReleaseBlock-Stable as it is a recent regression. Please feel free to remove the same if it is not applicable.

Thanks..

Deleted: 796480_good version.webm 4.0 MB

	796480_good version.webm 4.0 MB View Download

Deleted: 796480_Windows_bad.webm 3.3 MB

	796480_Windows_bad.webm 3.3 MB View Download

Deleted: 796480_bad behavior.webm 5.5 MB

	796480_bad behavior.webm 5.5 MB View Download

Thanks, I'll take a look.  That CL mainly affects Site Isolation modes (--site-per-process and --isolate-origins), but it sounds like that's not part of the repro steps.  It's possible the request initiator change to ResourceFetcher.cpp might have affected this.

Updating summary to see if I understand the concern.  It sounds like samesite=Lax cookies are missing from POST requests within content scripts, correct?

The screenshots in comment 7 and screencasts in comment 17 make it look like samesite=Strict cookies might also be missing from GET and POST requests within content scripts.  Is that also a bug?

Ok, I see what's happening now.

The SameSite cookie logic in URLRequestHttpJob::AddCookieHeaderAndStart() (and possibly elsewhere) checks whether the initiator of the request is the same site as the URL being requested.  If the initiator matches, both samesite=strict and samesite=lax cookies are attached.  If the initiator does not match, then samesite=strict cookies are omitted, and samesite=lax cookies are only attached for GET/HEAD and not POST.  mkwst@ added this in r382277 in Chrome 51.

In my cross-site document blocking CL (r522016), we changed the request initiator for content scripts from the page's origin to the extension's origin.  This was an intentional change allowing the browser process to recognize and allow requests made by content scripts when a security policy would normally prevent the page from requesting it.

I've confirmed that my change made the SameSite cookie check in AddCookieHeaderAndStart fail in this case, such that SameSite cookies are not attached to requests from content scripts.  (The lax cookies are still attached for GET due to the rules above, although that's a bit surprising to me since the spec at https://tools.ietf.org/html/draft-west-first-party-cookies-07 claims that lax cookies should only be included for top-level navigations, not XHRs as in the test page.)

It seems likely we could add an exception for content scripts to the SameSite cookie check to allow this to continue to work (though there will be some fun with content vs extensions as well as the network service).  I'd like to confirm with mkwst@ that allowing SameSite cookies on content script requests the right thing to do, but it seems reasonable.  Note that he's out until January 8.

In the meantime, it does look like injecting a script into the page to make the request is a workaround.

aelsergeev@: Can you comment on whether that workaround is feasible for you?  And can you give us a sense for which extension(s) this affects?

I am tagging M64 and M65, so that any CL to fix the issue would be merged to M64.

Hi all and Happy new year)

Yes, now i use in my extension similar workaround. I use inject script, who can send request and arranged communication between content scripts and inject script, but this is not very convenient.

This is local extension inside the company. Here's the link https://chrome.google.com/webstore/detail/admin-helper/eflmggbhnglpgbhojiimmphgbabfloog, I want to note that it is only for a company domain.

I would also like to add that when I started to understand and read the specification about cookies, it was also a surprise to me that these requests worked and worked for me in general :)

With the caveat that I'm not really back until next week, and so will have only sporadic access to this bug:

> In my cross-site document blocking CL (r522016), we changed the request initiator for content scripts from the page's origin to the extension's origin.  This was an intentional change allowing the browser process to recognize and allow requests made by content scripts when a security policy would normally prevent the page from requesting it.

This sounds like a reasonable kind of restriction to make, but I agree with your analysis about it leading to surprising behavior for things like `SameSite` cookies. I wonder if we've ended up overloading the "initiator" concept with more use cases than it was meant to handle (which is probably my fault for picking a very generic name in the first place :/ )... Regardless, it does seem reasonable to treat extension requests as same-site. There's some marginal risk associated with that, but it seems like risk we've accepted tacitly by having an extension system in the first place.

> (The lax cookies are still attached for GET due to the rules above, although that's a bit surprising to me since the spec at https://tools.ietf.org/html/draft-west-first-party-cookies-07 claims that lax cookies should only be included for top-level navigations, not XHRs as in the test page.)

Would you mind filing a separate bug against that bit of the implementation? It surprises me as well.

Comments 23-24: Thanks for following up!  It sounds like we can likely get a fix in place for this, but I'd like to have mkwst@ help review the change when he gets back.  Since there's a workaround, I think we probably won't aim to get the fix into M63, but (depending on how the change looks) we can see if it's possible to merge to M64.

Comment 25: Agreed-- extensions seem like a different case than SameSite cookies were considering, so exempting them probably makes sense.  I'm tempted to only exempt content scripts and not actual extension pages if that's possible (since I bet that's how it worked before my change), but I don't know yet how that check will look.  I'll also file a bug for the XHR thing when I get a moment.

Hello, I would like to update this task and find out if there are any terms for fixing this bug. Now the version of Chrome 64, whether it will be fixed in it or transferred to 65?

I have just uploaded a CL with fix and will send it for review today - https://chromium-review.googlesource.com/c/chromium/src/+/896690. 
Whether it is fixed in M65 will depend on decision by the TPMs for that release.

I've just noticed that Service Workers don't send SameSite=lax cookies in fetch requests (cookies without SameSite=lax are working fine).

Does this likely have the same cause and fix? Or should I file a separate bug? Please let me know if there is some canary version I can test.

I would suggest filing a separate bug for ServiceWorkers, especially if it is not a recent regression. This bug is tracking content scripts requests, because they used to work before we made changes to how the request initiator is set in that context.

I've filed https://bugs.chromium.org/p/chromium/issues/detail?id=810035

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c27ca05e015a4275604c48611ef752d1ff41930d

commit c27ca05e015a4275604c48611ef752d1ff41930d
Author: Nasko Oskov <nasko@chromium.org>
Date: Wed Mar 21 19:00:46 2018

Allow content script requests to attach SameSite cookies.

When a content script is injected into a document, it can make requests
to origins in its manifest. With recent changes to allow Chrome to block
cross-site documents, the initiator of content scripts requests was
changed to reflect the extension origin. This change meant that SameSite
cookies were not attached to those requests.

This CL introduces a check for content scripts making subresource requests
and tags those requests to allow attaching SameSite cookies.

Bug:  796480 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_mojo
Change-Id: I021156e346035267d98802cfb0205fc419e970bd
Reviewed-on: https://chromium-review.googlesource.com/896690
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: Matt Menke <mmenke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#544790}
[modify] https://crrev.com/c27ca05e015a4275604c48611ef752d1ff41930d/chrome/browser/extensions/content_script_apitest.cc
[modify] https://crrev.com/c27ca05e015a4275604c48611ef752d1ff41930d/chrome/renderer/chrome_content_renderer_client.cc
[modify] https://crrev.com/c27ca05e015a4275604c48611ef752d1ff41930d/chrome/renderer/chrome_content_renderer_client.h
[modify] https://crrev.com/c27ca05e015a4275604c48611ef752d1ff41930d/chrome/renderer/chrome_content_renderer_client_browsertest.cc
[modify] https://crrev.com/c27ca05e015a4275604c48611ef752d1ff41930d/chrome/renderer/extensions/chrome_extensions_renderer_client.cc
[modify] https://crrev.com/c27ca05e015a4275604c48611ef752d1ff41930d/chrome/renderer/extensions/chrome_extensions_renderer_client.h
[add] https://crrev.com/c27ca05e015a4275604c48611ef752d1ff41930d/chrome/test/data/extensions/api_test/content_scripts/request_cookies/background.js
[add] https://crrev.com/c27ca05e015a4275604c48611ef752d1ff41930d/chrome/test/data/extensions/api_test/content_scripts/request_cookies/cookies.js
[add] https://crrev.com/c27ca05e015a4275604c48611ef752d1ff41930d/chrome/test/data/extensions/api_test/content_scripts/request_cookies/manifest.json
[modify] https://crrev.com/c27ca05e015a4275604c48611ef752d1ff41930d/content/browser/loader/resource_dispatcher_host_impl.cc
[modify] https://crrev.com/c27ca05e015a4275604c48611ef752d1ff41930d/content/public/renderer/content_renderer_client.cc
[modify] https://crrev.com/c27ca05e015a4275604c48611ef752d1ff41930d/content/public/renderer/content_renderer_client.h
[modify] https://crrev.com/c27ca05e015a4275604c48611ef752d1ff41930d/content/renderer/loader/request_extra_data.cc
[modify] https://crrev.com/c27ca05e015a4275604c48611ef752d1ff41930d/content/renderer/loader/request_extra_data.h
[modify] https://crrev.com/c27ca05e015a4275604c48611ef752d1ff41930d/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/c27ca05e015a4275604c48611ef752d1ff41930d/extensions/shell/renderer/shell_content_renderer_client.cc
[modify] https://crrev.com/c27ca05e015a4275604c48611ef752d1ff41930d/extensions/shell/renderer/shell_content_renderer_client.h
[modify] https://crrev.com/c27ca05e015a4275604c48611ef752d1ff41930d/net/test/embedded_test_server/default_handlers.cc
[modify] https://crrev.com/c27ca05e015a4275604c48611ef752d1ff41930d/net/url_request/url_request.cc
[modify] https://crrev.com/c27ca05e015a4275604c48611ef752d1ff41930d/net/url_request/url_request.h
[modify] https://crrev.com/c27ca05e015a4275604c48611ef752d1ff41930d/net/url_request/url_request_http_job.cc
[modify] https://crrev.com/c27ca05e015a4275604c48611ef752d1ff41930d/services/network/public/cpp/network_param_ipc_traits.h
[modify] https://crrev.com/c27ca05e015a4275604c48611ef752d1ff41930d/services/network/public/cpp/resource_request.h
[modify] https://crrev.com/c27ca05e015a4275604c48611ef752d1ff41930d/services/network/url_loader.cc

Now that the fix has landed, the fix should be in tomorrow's canary release. I'm going to close this one, feel free to open a new bug if there are further issues. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/faf8f15004bf40ab250cb04c958dcfa96705f8f8

commit faf8f15004bf40ab250cb04c958dcfa96705f8f8
Author: Thomas Guilbert <tguilbert@chromium.org>
Date: Thu Mar 22 00:22:33 2018

Revert "Allow content script requests to attach SameSite cookies."

This reverts commit c27ca05e015a4275604c48611ef752d1ff41930d.

Reason for revert: This change seems to have started to cause MSAN bot failures. The first build in which which it was included was this one:
https://uberchromegw.corp.google.com/i/chromium.webkit/builders/WebKit%20Linux%20Trusty%20MSAN/builds/6729

Original change's description:
> Allow content script requests to attach SameSite cookies.
> 
> When a content script is injected into a document, it can make requests
> to origins in its manifest. With recent changes to allow Chrome to block
> cross-site documents, the initiator of content scripts requests was
> changed to reflect the extension origin. This change meant that SameSite
> cookies were not attached to those requests.
> 
> This CL introduces a check for content scripts making subresource requests
> and tags those requests to allow attaching SameSite cookies.
> 
> Bug:  796480 
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_mojo
> Change-Id: I021156e346035267d98802cfb0205fc419e970bd
> Reviewed-on: https://chromium-review.googlesource.com/896690
> Commit-Queue: Nasko Oskov <nasko@chromium.org>
> Reviewed-by: Charlie Reis <creis@chromium.org>
> Reviewed-by: John Abd-El-Malek <jam@chromium.org>
> Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
> Reviewed-by: Matt Menke <mmenke@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#544790}

TBR=creis@chromium.org,nasko@chromium.org,jam@chromium.org,rdevlin.cronin@chromium.org,mmenke@chromium.org

Change-Id: I2286f5185bff189f9177bd600cb1a7ca94334cb3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  796480 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_mojo
Reviewed-on: https://chromium-review.googlesource.com/974349
Reviewed-by: Thomas Guilbert <tguilbert@chromium.org>
Commit-Queue: Thomas Guilbert <tguilbert@chromium.org>
Cr-Commit-Position: refs/heads/master@{#544919}
[modify] https://crrev.com/faf8f15004bf40ab250cb04c958dcfa96705f8f8/chrome/browser/extensions/content_script_apitest.cc
[modify] https://crrev.com/faf8f15004bf40ab250cb04c958dcfa96705f8f8/chrome/renderer/chrome_content_renderer_client.cc
[modify] https://crrev.com/faf8f15004bf40ab250cb04c958dcfa96705f8f8/chrome/renderer/chrome_content_renderer_client.h
[modify] https://crrev.com/faf8f15004bf40ab250cb04c958dcfa96705f8f8/chrome/renderer/chrome_content_renderer_client_browsertest.cc
[modify] https://crrev.com/faf8f15004bf40ab250cb04c958dcfa96705f8f8/chrome/renderer/extensions/chrome_extensions_renderer_client.cc
[modify] https://crrev.com/faf8f15004bf40ab250cb04c958dcfa96705f8f8/chrome/renderer/extensions/chrome_extensions_renderer_client.h
[delete] https://crrev.com/b808a86602ffb8b1c9e11785c7b458f1eae116d6/chrome/test/data/extensions/api_test/content_scripts/request_cookies/background.js
[delete] https://crrev.com/b808a86602ffb8b1c9e11785c7b458f1eae116d6/chrome/test/data/extensions/api_test/content_scripts/request_cookies/cookies.js
[delete] https://crrev.com/b808a86602ffb8b1c9e11785c7b458f1eae116d6/chrome/test/data/extensions/api_test/content_scripts/request_cookies/manifest.json
[modify] https://crrev.com/faf8f15004bf40ab250cb04c958dcfa96705f8f8/content/browser/loader/resource_dispatcher_host_impl.cc
[modify] https://crrev.com/faf8f15004bf40ab250cb04c958dcfa96705f8f8/content/public/renderer/content_renderer_client.cc
[modify] https://crrev.com/faf8f15004bf40ab250cb04c958dcfa96705f8f8/content/public/renderer/content_renderer_client.h
[modify] https://crrev.com/faf8f15004bf40ab250cb04c958dcfa96705f8f8/content/renderer/loader/request_extra_data.cc
[modify] https://crrev.com/faf8f15004bf40ab250cb04c958dcfa96705f8f8/content/renderer/loader/request_extra_data.h
[modify] https://crrev.com/faf8f15004bf40ab250cb04c958dcfa96705f8f8/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/faf8f15004bf40ab250cb04c958dcfa96705f8f8/extensions/shell/renderer/shell_content_renderer_client.cc
[modify] https://crrev.com/faf8f15004bf40ab250cb04c958dcfa96705f8f8/extensions/shell/renderer/shell_content_renderer_client.h
[modify] https://crrev.com/faf8f15004bf40ab250cb04c958dcfa96705f8f8/net/test/embedded_test_server/default_handlers.cc
[modify] https://crrev.com/faf8f15004bf40ab250cb04c958dcfa96705f8f8/net/url_request/url_request.cc
[modify] https://crrev.com/faf8f15004bf40ab250cb04c958dcfa96705f8f8/net/url_request/url_request.h
[modify] https://crrev.com/faf8f15004bf40ab250cb04c958dcfa96705f8f8/net/url_request/url_request_http_job.cc
[modify] https://crrev.com/faf8f15004bf40ab250cb04c958dcfa96705f8f8/services/network/public/cpp/network_param_ipc_traits.h
[modify] https://crrev.com/faf8f15004bf40ab250cb04c958dcfa96705f8f8/services/network/public/cpp/resource_request.h
[modify] https://crrev.com/faf8f15004bf40ab250cb04c958dcfa96705f8f8/services/network/url_loader.cc

And the fix was reverted due to MSan error. I have a new CL that will fix the MSan issue at https://chromium-review.googlesource.com/#/c/chromium/src/+/974882.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/13105d485c9488e47eeaf5077755e0df5fa1e4e8

commit 13105d485c9488e47eeaf5077755e0df5fa1e4e8
Author: Nasko Oskov <nasko@chromium.org>
Date: Fri Mar 23 22:02:08 2018

Allow content script requests to attach SameSite cookies.

When a content script is injected into a document, it can make requests
to origins in its manifest. With recent changes to allow Chrome to block
cross-site documents, the initiator of content scripts requests was
changed to reflect the extension origin. This change meant that SameSite
cookies were not attached to those requests.

This CL introduces a check for content scripts making subresource requests
and tags those requests to allow attaching SameSite cookies.

Reland of https://chromium-review.googlesource.com/c/chromium/src/+/896690

Bug:  796480 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_mojo
Change-Id: I8316f259f8b04c4fad406c398ba5207abef8a00e
Reviewed-on: https://chromium-review.googlesource.com/974882
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#545584}
[modify] https://crrev.com/13105d485c9488e47eeaf5077755e0df5fa1e4e8/chrome/browser/extensions/content_script_apitest.cc
[modify] https://crrev.com/13105d485c9488e47eeaf5077755e0df5fa1e4e8/chrome/renderer/chrome_content_renderer_client.cc
[modify] https://crrev.com/13105d485c9488e47eeaf5077755e0df5fa1e4e8/chrome/renderer/chrome_content_renderer_client.h
[modify] https://crrev.com/13105d485c9488e47eeaf5077755e0df5fa1e4e8/chrome/renderer/chrome_content_renderer_client_browsertest.cc
[modify] https://crrev.com/13105d485c9488e47eeaf5077755e0df5fa1e4e8/chrome/renderer/extensions/chrome_extensions_renderer_client.cc
[modify] https://crrev.com/13105d485c9488e47eeaf5077755e0df5fa1e4e8/chrome/renderer/extensions/chrome_extensions_renderer_client.h
[add] https://crrev.com/13105d485c9488e47eeaf5077755e0df5fa1e4e8/chrome/test/data/extensions/api_test/content_scripts/request_cookies/background.js
[add] https://crrev.com/13105d485c9488e47eeaf5077755e0df5fa1e4e8/chrome/test/data/extensions/api_test/content_scripts/request_cookies/cookies.js
[add] https://crrev.com/13105d485c9488e47eeaf5077755e0df5fa1e4e8/chrome/test/data/extensions/api_test/content_scripts/request_cookies/manifest.json
[modify] https://crrev.com/13105d485c9488e47eeaf5077755e0df5fa1e4e8/content/browser/loader/resource_dispatcher_host_impl.cc
[modify] https://crrev.com/13105d485c9488e47eeaf5077755e0df5fa1e4e8/content/public/renderer/content_renderer_client.cc
[modify] https://crrev.com/13105d485c9488e47eeaf5077755e0df5fa1e4e8/content/public/renderer/content_renderer_client.h
[modify] https://crrev.com/13105d485c9488e47eeaf5077755e0df5fa1e4e8/content/renderer/loader/request_extra_data.cc
[modify] https://crrev.com/13105d485c9488e47eeaf5077755e0df5fa1e4e8/content/renderer/loader/request_extra_data.h
[modify] https://crrev.com/13105d485c9488e47eeaf5077755e0df5fa1e4e8/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/13105d485c9488e47eeaf5077755e0df5fa1e4e8/extensions/shell/renderer/shell_content_renderer_client.cc
[modify] https://crrev.com/13105d485c9488e47eeaf5077755e0df5fa1e4e8/extensions/shell/renderer/shell_content_renderer_client.h
[modify] https://crrev.com/13105d485c9488e47eeaf5077755e0df5fa1e4e8/net/test/embedded_test_server/default_handlers.cc
[modify] https://crrev.com/13105d485c9488e47eeaf5077755e0df5fa1e4e8/net/url_request/url_request.cc
[modify] https://crrev.com/13105d485c9488e47eeaf5077755e0df5fa1e4e8/net/url_request/url_request.h
[modify] https://crrev.com/13105d485c9488e47eeaf5077755e0df5fa1e4e8/net/url_request/url_request_http_job.cc
[modify] https://crrev.com/13105d485c9488e47eeaf5077755e0df5fa1e4e8/services/network/public/cpp/network_param_ipc_traits.h
[modify] https://crrev.com/13105d485c9488e47eeaf5077755e0df5fa1e4e8/services/network/public/cpp/resource_request.h
[modify] https://crrev.com/13105d485c9488e47eeaf5077755e0df5fa1e4e8/services/network/url_loader.cc

The fix seems to have stuck this time around, closing as fixed.

How can I find out when this bugfix will be deployed?

It was fixed in the M67 milestone, which is currently on the Beta channel. The target date for M67 to go to the stable channel is May 29th (https://www.chromestatus.com/features/schedule).