Yeah, that's unintended. We should carve out same-origin matches with matching usernames/passwords in order to ensure that we're not breaking this use case yet.

(That said, given that the number of top-level navigations to URLs with embedded credentials is hovering around 0%, we're considering removing this functionality entirely... See discussion in https://bugs.chromium.org/p/chromium/issues/detail?id=504300#c13)

https://chromium-review.googlesource.com/530308

 Issue 732334  has been merged into this issue.

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

commit 0ae6b276afc7f7fb1a5adec900717ce03cb83eaf
Author: Mike West <mkwst@chromium.org>
Date: Tue Jun 13 21:01:27 2017

Allow embedded credentials for relative URLs.

If a user visits `http://user:pass@example.com/`, we should allow
`<img src='/whatever.png'>`. Currently, we're doing the embedded
credential check on the completed URL, which ends up blocking the
request.

Bug: 731618
Change-Id: I5a15187a2a0fd39822467d64efeedaae637765a8
Reviewed-on: https://chromium-review.googlesource.com/530308
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/master@{#479147}
[modify] https://crrev.com/0ae6b276afc7f7fb1a5adec900717ce03cb83eaf/third_party/WebKit/LayoutTests/FlagExpectations/enable-blink-features=LayoutNG
[rename] https://crrev.com/0ae6b276afc7f7fb1a5adec900717ce03cb83eaf/third_party/WebKit/LayoutTests/external/wpt/fetch/security/dangling-markup-mitigation.tentative.html
[add] https://crrev.com/0ae6b276afc7f7fb1a5adec900717ce03cb83eaf/third_party/WebKit/LayoutTests/external/wpt/fetch/security/embedded-credentials.tentative.sub.html
[add] https://crrev.com/0ae6b276afc7f7fb1a5adec900717ce03cb83eaf/third_party/WebKit/LayoutTests/external/wpt/fetch/security/support/embedded-credential-window.sub.html
[modify] https://crrev.com/0ae6b276afc7f7fb1a5adec900717ce03cb83eaf/third_party/WebKit/Source/core/loader/BaseFetchContext.cpp
[modify] https://crrev.com/0ae6b276afc7f7fb1a5adec900717ce03cb83eaf/third_party/WebKit/Source/core/loader/BaseFetchContext.h
[modify] https://crrev.com/0ae6b276afc7f7fb1a5adec900717ce03cb83eaf/third_party/WebKit/Source/core/loader/BaseFetchContextTest.cpp
[modify] https://crrev.com/0ae6b276afc7f7fb1a5adec900717ce03cb83eaf/third_party/WebKit/Source/core/loader/FrameFetchContext.cpp
[modify] https://crrev.com/0ae6b276afc7f7fb1a5adec900717ce03cb83eaf/third_party/WebKit/Source/core/loader/FrameFetchContext.h
[modify] https://crrev.com/0ae6b276afc7f7fb1a5adec900717ce03cb83eaf/third_party/WebKit/Source/core/loader/WorkerFetchContext.cpp
[modify] https://crrev.com/0ae6b276afc7f7fb1a5adec900717ce03cb83eaf/third_party/WebKit/Source/core/loader/WorkerFetchContext.h
[modify] https://crrev.com/0ae6b276afc7f7fb1a5adec900717ce03cb83eaf/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.json5

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

commit a9bca94033a6d13e17d5d7dec1e9ce9625f90772
Author: Mike West <mkwst@chromium.org>
Date: Wed Jun 14 20:01:58 2017

Restore the 'BlockCredentialedSubresources' runtime flag.

There's some negative feedback flowing in as the change hits stable, so.
Let's put the flag back for the time being.

Bug: 731618
Change-Id: If37bd732e9e2b364cd1eedeedbb85838602453d3
Reviewed-on: https://chromium-review.googlesource.com/535521
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/master@{#479478}
[modify] https://crrev.com/a9bca94033a6d13e17d5d7dec1e9ce9625f90772/third_party/WebKit/Source/core/loader/FrameFetchContext.cpp
[modify] https://crrev.com/a9bca94033a6d13e17d5d7dec1e9ce9625f90772/third_party/WebKit/Source/core/loader/WorkerFetchContext.cpp
[modify] https://crrev.com/a9bca94033a6d13e17d5d7dec1e9ce9625f90772/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.json5

Will this be merged to some release (59? 60?)?

This lead to crashing all my test cases because of the broken CSS. When can we expect a fix?

Until the fix is released, you can use the switch

--disable-blink-features=BlockCredentialedSubresources

to run your tests.

Let's get it back to 60. I think the ship has sailed for 59 (and the overall numbers of top-level navigation to credentialed URLs is very low).

Hello, friendly release managers: WDYT about merging back the two patches in this bug (https://chromium.googlesource.com/chromium/src.git/+/0ae6b276afc7f7fb1a5adec900717ce03cb83eaf and https://chromium.googlesource.com/chromium/src.git/+/a9bca94033a6d13e17d5d7dec1e9ce9625f90772). They've baked on dev channel for a week, and seem safe to merge back.

The bug is marked as P3 or Feature. It should not be merged as M60 is in beta. 
Please contact the approriate milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

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

+bustamante@/amineer@: I agree with the bot's opinion in general! But I'd still like to merge this back to 60. It solves a problem that developers are seeing frequently enough in the wild to find threads related to this bug and comment on them. I'd appreciate y'all taking a slightly less automated look at this. :)

Poking at flags in the hopes of catching folks before they disappear for the holiday. :)

This bug requires manual review: M60 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

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

Since we're past M60 merge point, our bar is very high for taking in merges. Based on the description and comments, this doesn't appear to be a critical bug. Can we wait until M61? What are the downsides if we wait until then?

Our goal right now is to stabilize M60 branch and only take critical bug regressions, stable blockers, and security bugs. 

 Issue 738408  has been merged into this issue.

abdulsyed@: In short, this bug prevents folks who navigate to URLs like `https://user:pass@whatever.com/` from loading subresources with relative URLs (like `<img src="/img.png">`). I agree with your underlying suggestion that this doesn't happen terribly often, but it does seem to be more concentrated in a population of developers who rely on it for various internal usage.

There is a reasonable workaround for a developer population (the `--disable-blink-features=BlockCredentialedSubresources` flag noted above), but that's a difficult workaround to use on non-desktop platforms. Given the volume of feedback, it seems to me that this is something worth addressing.

Would y'all be more comfortable with merging a patch back that added that flag to `about:flags` to make it universally accessible?

 Issue 738917  has been merged into this issue.

Please add this as an about:flag so that it can easily be dealt with across platforms and user experience levels.

Also, couldn't have this just been a warning, instead of this outright block? 

Seems like a little more thought into how you treat your users in an error scenario and you wouldn't be ruining so many peoples day with this change. I feel like this happened recently with another recent change(https).

Prefer the use of soft errors over hard.

abdulsyed@: Ping?

 Issue 741573  has been merged into this issue.

Chatted with mkwst@ offline - since stable release is less than two weeks away, we agreed that it's best to target fix for M61. Risk of taking a large patch is higher this late, and can have negative consequences on a broader scale. Apologies for the inconvenience that this is causing and please use the current workaround, mentioned in comment 9, for desktop fix. Fix will be available soon in M61. 

 Issue 745342  has been merged into this issue.

I agree with reporter.
simply do not transfer the "user:pass" part from the main url provided in the address bar ... so sub-resources loading will be attempted and will succeed, as the "Authorization" HTTP Header is set ...

Yet, I can understand why you are "blocking" the urls when they are hard-coded "user:pass" in the html, to avoid CSRF attempts, but realistically even the "Authorization" HTTP Header could lead to a CSRF exploit

 Issue 746131  has been merged into this issue.

 Issue 746773  has been merged into this issue.

I am having issues with my tests failing due to longer being able to pass the username and pw into URL for basic authentication pop up...
I tried to add to my config.js file the following. But did not work, pop up still appears.

chromeOptions: {
 args:['--disable-blink-features=BlockCredentialedSubresources']
},

Please try suggestion in comment 9 for a workaround for desktop. 

Looks like this is working as before in Chrome Version 61.0.3163.79 (Official Build) (64-bit)

I am using it on Windows 7

I can confirm this is also fixed for me on Windows 10 with Chrome 61.

Not working for me on Windows 7 x64 with Chrome Version 61.0.3163.79 (Official Build) (64-bit)

I still have to use Chrome Portable Version 58.0.3029.110 (64-bit) for pages with basic authentication to work (all webcams in AV enabled rooms across our organization=university.)

#32 - that is weird. Though you might have a different case. I suggest filing a new issue for it with as much details as possible, a test URL that reproduces the issue would be help a great deal. You can comment here with the issue number.

Thank you guys for fixing this in 61. Eagerly waited for this update.

No longer on the Chrome team, e-mail me @google.com if any attention still required from me here, otherwise good luck!

Hello!
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Wednesday, 12/19/18 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!

Due to lack of action this bug has been Archived. If work is still being done on this issue or you are still experiencing this issue please feel free to re-open with the appropriate information.

This is still an issue for me and others in my organisation.
We use simple authentication (IP followed by username and pasword) on a private vlan to access webcams (so no security issues/implications). We do not type the IP or login details, they are automatically sent by a server we have opening an iFrame in an AV monitoring solution called Crestron Fusion.
At the moment we are forced to use and not update an old version of Firefox portable (45 ESR) which allows this connection method.

This is the syntax of the iFrame call:
<iframe id="ifrmWC" src="http://{USERNAME}:{PASSWORD}@{IP ADDRESS}" width="100%" frameborder="0" style="height: 308px;"></iframe>

The iFrame never loads (blank), no error message.
Firefox ESR45 asks if you are sure you want to login to IP ADDRESS with the credentials for USERNAME
once accepted the webcam feed loads normally