Tested on windows 10 using latest stable M55 #55.0.2883.87 and latest canary M57 #57.0.2957.0 and didnt see any error on console page when given command "history.pushState({}, '', location.href + 'index.html')" is run.

Attached screencast for reference.

@kalpakas.g-- Could you please check the attached screencast and confirm us if we have followed the correct process and please help us with expected result screenshot.

Thanks!

Deleted: 675884.mp4 2.3 MB

	675884.mp4 2.3 MB View Download

On the screencast, it is not visible whether you followed step 1 from the repro steps:

1. Navigate to: `http://user:pass@example.com/`

The critical thing here, is that user credentials must be embeded into the URL. I.e. the `user:pass@` prefix must be there for the bug to appear.

I assume you navigated to `http://www.iana.org/domains/reserved`.
In order to see the bug, you have to navigate to `http://user:pass@www.iana.org/domains/reserved`.

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

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

Adding Mike and Justin who worked on this according to git blame.

Justin/Mike, is there any feedback required from the reporter or TE, or can one of you help triage and find an owner for this?

Able to reproduce this issue on Windows 10, Ubuntu 14.04  with chrome version 55.0.2883.87 and Mac 10.12.2 on chrome stable version 55.0.2883.95 and also in current canary version #57.0.2986.0
Issue is broken in M49.

Bisect Info:
===========
Good build : 49.0.2586.0,  Revision Range -363935
Bad build  : 49.0.2587.0,  Revision Range -364237

After executing the bisect(old) script , i got the following CL's between good and bad build versions
===========================================
https://chromium.googlesource.com/chromium/src/+log/adb00336092bc581c5204118f22f827740b4a220..63d814aa438e153919893ebe86e3c2901d3dd76d

The suspecting Change Log is :
-----------
https://chromium.googlesource.com/chromium/src/+/587195f6886817f7b634bf58eafa7f900a9b6532

From the above CL suspecting the below change
---------------------------
Review URL: https://codereview.chromium.org/1495013002


rob@- Could you please look into this issue, if it's related to your change?  if not could you please help us to reassign this issue to the right owner.

Until this is resolved, use the following:
  history.pushState({}, '', '/index.html')
instead of
  history.pushState({}, '', location.href + 'index.html')

Since the username and password components are effectively hidden from the DOM APIs, I guess that it makes sense to extend the urlForState [1] method such that if the document's username/password is not empty and that the rest of the origin matches, that the username and password are copied to the specified URL (since the JS code has no way of generating the expected URL).
Or, even copy the username+password unconditionally (provided that the rest of the origin matches), to prevent brute-forcing of the username+password combo.


About the error message: If it is undesirable that the username/passwords get printed to the console, then KURL::elidedString [2] should be modified to internally use KURL::strippedForUseAsHref instead of KURL::getString.

Mike, any opinion on this?

[1] https://chromium.googlesource.com/chromium/src/+/d5231cdb20da617c9625996b6e552c0f498d1889/third_party/WebKit/Source/core/frame/History.cpp#164
[2] https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/platform[/weborigin/KURL.cpp#193

> Until this is resolved, use the following:
>   history.pushState({}, '', '/index.html')
> instead of
>   history.pushState({}, '', location.href + 'index.html')

Sorry, but how is `'/index.html'` equivalent to `location.href + 'index.html'` (if for example `location.href === 'http://foo.com/bar/'`)?

> Sorry, but how is `'/index.html'` equivalent to `location.href + 'index.html'` (if for example `location.href === 'http://foo.com/bar/'`)?

They are not equivalent, but in the given example the path component was '/', so I assumed that one wanted to rewrite the path component.

If you really want equivalent behavior (location.href + 'index.html'), use
location.pathname + location.search + location.hash + 'index.html'
... but that does not make much sense: e.g. I can't imagine much use in turning "http://example.com/search?q=something#ref" into "http://example.com/search?q=something#refindex.html".

Reproduced the same issue. It is a major issue for me at the moment because it prevents automating UI tests.

Just to add some details:

Issue has been reproduced in Chrome Version 67.0.3396.99 (Official Build) (64-bit) on macOS 10.13.5

Any update on this issue. I am automating some test cases using selenium and chrome and facing same issue.

The only workaround I have found so far is just to add two OPEN statements at the top of the script:

1) open https://user@pass:yourdomain.com/
2) open https://yourdomain.com/
3) any other step

The first will apply credentials for Basic Auth.
The second will open URL without user:pass@ section but it will still load because credentials are accepted already.