Tested on Windows 7 using chrome latest stable M49-49.0.2623.87 by following steps mentioned below.

1. Navigated to https://www.google.no/
2. Switched to console and typed window.fetch(".")
3. Observed an error saying "Request cannot be constructed from a URL that includes credentials"

hmottestad@ Is this issue used to work before? If yes, do you remember on which version? Tested the same on previous version of chrome M35-35.0.1851.0 still unable to repro. So please let us know is this is a regression or non-regression.

Thanks!

I just tested this is on v 48.0.2564.116 (64-bit) and it works fine.

I tried window.fetch(".") and window.fetch("/hello") and they both show up in the network logs (XHR) as http://test:test@www.google.no/ and http://test:test@www.google.no/hello respectively. 

If I add {credentials: 'same-origin'} it also sends the cookie. I also tested this on a site that requires http basic auth, and then it sends the correct Authorization header.

So this is a regression for me.

It is specified in https://fetch.spec.whatwg.org/#dom-request

  If parsedURL includes credentials, throw a TypeError.

and was implemented as https://chromium.googlesource.com/chromium/src/+/1c2ac08f854e4b5f668c8e8f148fcb6679d2e34e. I think it works as intended.

I found that same code. And it does look intended. 

There doesn't seem to be an explanation for why the spec doesn't allow credentials, and it is probably an omission to not handle relative urls independently of absolute urls. Credentials in absolute urls may be bad. But relative urls only have credentials because of their base url, which is already ratified by the browser.  

Have you read below threads?

- https://github.com/whatwg/fetch/issues/26
- https://bugs.chromium.org/p/chromium/issues/detail?id=474439

If you want to change a spec-conformant behavior, the spec issue tracker would be the right place to talk.

Thank you for providing more feedback. Assigning to requester "ssamanoori@chromium.org" for another review.

For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot

Tested the issue on Windows 7 using 49.0.2623.87, latest stable 49.0.2623.110 with below steps:

1.Opened URL: https://www.google.no/
2.Navigated to dev tools->console and typed 'window.fetch(".")'.
3.Observed the result as in screenshot.
4.Observed the same behavior in chrome 48.0.2564.116 version.

Please find attached screenshot and update if anything missed here in triaging the issue.

hmottestad@Could you please provide actual and expected behavior screenshots for better understanding the issue to triage it further.

Deleted: 596261.png 103 KB

	596261.png 103 KB View Download

Try: https://test:test@www.google.no/

Thank you for providing more feedback. Adding requester "ssamanoori@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot

Tested the issue on Windows 7 using 49.0.2623.87, latest stable 49.0.2623.110 with below steps:

1.Opened URL: https://test:test@www.google.no/
2.Navigated to dev tools->console and typed 'window.fetch(".")'.
3.Observed an error saying "Request cannot be constructed from a URL that includes credentials" in M-49.
4.Observed the differeny behavior in chrome 48.0.2564.116 version.
5.Observed different error in M-40 and M-30 versions of chrome.

hmottestad@Could you please provide expected behavior screenshot for better understanding the issue to triage it further.

Expected. 

Deleted: Screen Shot 2016-03-31 at 20.41.40.png 33.3 KB

	Screen Shot 2016-03-31 at 20.41.40.png 33.3 KB View Download

Current behaviour.

Deleted: Screen Shot 2016-03-31 at 20.43.05.png 69.2 KB

	Screen Shot 2016-03-31 at 20.43.05.png 69.2 KB View Download

ssamanoori@chromium.org

window.fetch("anything/goes/here") when on a page with inline basic auth worked fine in v48 but stopped working in v49. 

As pointed out by yhirano@chromium.org, this is actually spec compliant.

I very much disagree with the spec, since it breaks behaviour that works with XMLHttpRequest and breaks behaviour that is part of the http standard. I have aired by concerns on https://github.com/whatwg/fetch/issues/26. 

Thank you for providing more feedback. Adding requester "ssamanoori@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot

Unable to reproduce the issue on Windows 7 using latest stable 49.0.2623.110, canary 51.0.2701.0 as per steps in comment #9.
Please find attached screenshot.

hmottestad@Could you please check the issue on clean profile and update your observations.

Deleted: 596261.png 111 KB

	596261.png 111 KB View Download

OK, I'm taking this bug but I will not change the implementation until the standard discussion settles.

I don't have a strong opinion which is right: hiroshige@, can you express your opinion on the github issue https://github.com/whatwg/fetch/issues/26?

Close this issue as the spec issue is closed. https://github.com/whatwg/fetch/issues/26?#issuecomment-234557734