Thanks for filing the issue!

@Reporter: As mentioned in steps to reproduce the problem in comment#0, to test the issue from our end we need the sample URL and valid login credentials to confirm the issue, if possible could you please provide the sample URL and valid login credentials which helps us in further triaging it.

Thanks!

We were seeing this in our internal network which I couldn't provide a working URL for here. But I created a simple reproduction on an AWS server.

Repro URL: http://ec2-54-234-175-88.compute-1.amazonaws.com
Username: test
Password: test

So it seems that it happens for any embedded resource that requires authentication when the parent page does not require authentication. For this repro I created 2 websites on this server. One website is just serving the static html file, and this website has authentication disabled. The second website is just serving a static image file. That website has authentication enabled. The static html on the first website has an img tag for the image on the second website. 

When I navigate to that page, it displays a dialog to enter credentials, which is expected since the image is protected by Windows Authentication, but it also changes the URL in the address bar to the URL of the image itself: http://ec2-54-234-175-88.compute-1.amazonaws.com:20000/test.png

Once entering the credentials, it just remains on an empty white page with that URL in the address bar. I have to hit the Back button on the browser to get back to the HTML page that displays the image.

Thank you for providing more feedback. Adding the requester to the cc list.

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

Seems like a navigation issue to me, rather than a network issue.

Assigning to meacer@ for triage, as this seems similar to  issue 839724 . The interesting angle is M65 vs M66 difference in behavior.

Able to reproduce the issue on reported chrome version 66.0.3359.139, beta# 67.0.3396.30 and latest chrome#68.0.3423.0 using Windows-10, Mac 10.12.6 & Ubuntu 17.10  hence providing Bisect Info
Bisect Info:
================
Good build: 66.0.3357.0
Bad build: 66.0.3358.0

You are probably looking for a change made after 539902 (known good), but no later than 539903 (first known bad).
https://chromium.googlesource.com/chromium/src/+log/ead4271f098dd2038ec8514f1bf9b59f83b0774b..bc561f417634ce7326816b5167476003386e947b
Reviewed-on: https://chromium-review.googlesource.com/938960

@Jun Cai: Please confirm the issue and help in re-assigning if it is not related to your change.
Adding ReleaseBlock-Stable as it is seems a receent break, feel free to remove it if not applicable.

Thanks!

Some update: I can reproduce this issue using the repro URL on Comment 3.

It looks like the |is_main_frame| value is different for old code path and new code path. For the old path, it was using:
bool is_main_frame =
      (request->load_flags() & net::LOAD_MAIN_FRAME_DEPRECATED) != 0;
at line 664 and 665:
https://chromium-review.googlesource.com/c/chromium/src/+/938960/7/chrome/browser/ui/login/login_handler.cc
Using the above repro URL, its value is false.

The new code path uses:
https://cs.chromium.org/chromium/src/content/browser/loader/resource_dispatcher_host_impl.cc?l=549
And using the above repro URL, its value is true.

Changing code using net::LOAD_MAIN_FRAME_DEPRECATED can fix this issue, but since the net::LOAD_MAIN_FRAME_DEPRECATED is marked as deprecated, not sure if it is ok to keep using this flag. Any suggestions? Thanks!

 Issue 838814  has been merged into this issue.

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

commit a95bed30479b9701ac3ccaf28b25550bd419a4cb
Author: Jun Cai <juncai@chromium.org>
Date: Wed May 09 23:26:55 2018

Network Service: Change back how the |is_main_frame| value is obtained

This CL fixes the regression caused by the CL:
https://chromium-review.googlesource.com/c/chromium/src/+/938960
which changed the code to obtain the value for |is_main_frame|,
this CL changes it back to avoid the regression.

Bug:  840176 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_mojo
Change-Id: If1919dd34cfc3f26de84c902356f60bd5f4b0751
Reviewed-on: https://chromium-review.googlesource.com/1050935
Reviewed-by: Matt Menke <mmenke@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: Jun Cai <juncai@chromium.org>
Cr-Commit-Position: refs/heads/master@{#557374}
[modify] https://crrev.com/a95bed30479b9701ac3ccaf28b25550bd419a4cb/content/browser/loader/resource_dispatcher_host_impl.cc
[modify] https://crrev.com/a95bed30479b9701ac3ccaf28b25550bd419a4cb/content/browser/network_service_client.cc

Able to reproduce the issue on chrome reported version 66.0.3359.139
Verified the fix on Mac 10.13.3, Windows-10 & Ubuntu 17.10 on Chrome version #68.0.3426.0 as per the comment#0 & 3
Attaching screen cast for reference.
Observed "Browser stayed on the same page and asked for credentials, after providing credentials it resume normally"
Hence, the fix is working as expected.
Adding the verified label.

Thanks!

Deleted: 840176.mp4 1.3 MB

	840176.mp4 1.3 MB View Download

FYI I have also verified that 68.0.3426.0 fixes the original SignalR issue that we were experiencing. Thanks guys.

 Issue 841609  has been merged into this issue.

juncai@, pls request a merge to M67 if you think it is good to merge, also pls provide little more details to justify the merge as well (how safe it is and why it is needed...etc?). Thank you.

codecandy2k:  Thanks for testing!

I'm going to go ahead and request merges to Chrome 66 and Chrome 67.  This is sufficiently bad that I think a merge to 66 is definitely warranted.

This breaks HTTP authentication dialogs when an auth challenge (proxy or server) is received on a subresource request of the main frame.  The user goes to a page, sees the challenge, enters credentials, and the page fails to load, and the omnibox (Which is supposed to the The Source Of Truth) displays the wrong URL (In the 3 examples I've seen, the page is blank - I haven't tested manuallym to see if that's always the case).  Going back and then forward to the page again should result in a successful reload - I'm not sure about pressing the reload button.

The fix is low risk (Just two lines of code, switching from checking if the resource was requested by the main frame to testing if the resource was for the main frame).  The main expected impact here is on Enterprise users.

Approving merge to M67 branch 3396 based on comment #13, #14 and #17. Please merge ASAP and mark the bug as fixed after the merge.  Thank you.

+ abdulsyed@ (Chrome Desktop M66 Release TPM) for M66 merge review.

+ robertshield FYI as this is Enterprise bug (PTAL comment #17).

Also requesting a postmortem for this as this is broken on M66 which is currently in stable. Please see go/chrome-postmortems for the process to follow. Thank you.

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

commit 7d0f75aee8f7e6f77c3725dde5d95d3e774d2d2c
Author: Jun Cai <juncai@chromium.org>
Date: Thu May 10 18:16:57 2018

Merge to release branch M67: Network Service: Change back how the |is_main_frame| value is obtained

This CL merges the following CL to M67 branch:
https://chromium-review.googlesource.com/c/chromium/src/+/1050935

TBR=jam@chromium.org, mmenke@chromium.org

Bug:  840176 
Change-Id: Ic5342dbbc560e569761434030134fef41086d8a8
Reviewed-on: https://chromium-review.googlesource.com/1054171
Reviewed-by: Jun Cai <juncai@chromium.org>
Cr-Commit-Position: refs/branch-heads/3396@{#548}
Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}
[modify] https://crrev.com/7d0f75aee8f7e6f77c3725dde5d95d3e774d2d2c/content/browser/loader/resource_dispatcher_host_impl.cc
[modify] https://crrev.com/7d0f75aee8f7e6f77c3725dde5d95d3e774d2d2c/content/browser/network_service_client.cc

Marking fixed (Though should still be merged to M66)

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

commit 89d546525a7abba60923fc0bb5800154e0c8d013
Author: Jun Cai <juncai@chromium.org>
Date: Thu May 10 19:05:07 2018

Revert "Merge to release branch M67: Network Service: Change back how the |is_main_frame| value is obtained"

This reverts commit 7d0f75aee8f7e6f77c3725dde5d95d3e774d2d2c.

Reason for revert: The merge fails to compile.

Original change's description:
> Merge to release branch M67: Network Service: Change back how the |is_main_frame| value is obtained
> 
> This CL merges the following CL to M67 branch:
> https://chromium-review.googlesource.com/c/chromium/src/+/1050935
> 
> TBR=jam@chromium.org, mmenke@chromium.org
> 
> Bug:  840176 
> Change-Id: Ic5342dbbc560e569761434030134fef41086d8a8
> Reviewed-on: https://chromium-review.googlesource.com/1054171
> Reviewed-by: Jun Cai <juncai@chromium.org>
> Cr-Commit-Position: refs/branch-heads/3396@{#548}
> Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}

TBR=juncai@chromium.org,juncai@google.com

Change-Id: Id9cc68a628ec12db6f0c1819a54e726acccd35cf
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  840176 
Reviewed-on: https://chromium-review.googlesource.com/1054347
Reviewed-by: Jun Cai <juncai@chromium.org>
Cr-Commit-Position: refs/branch-heads/3396@{#552}
Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}
[modify] https://crrev.com/89d546525a7abba60923fc0bb5800154e0c8d013/content/browser/loader/resource_dispatcher_host_impl.cc
[modify] https://crrev.com/89d546525a7abba60923fc0bb5800154e0c8d013/content/browser/network_service_client.cc

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

commit ce4ddb7fd29eae2b9a0b27a2c7a4fc1adb0a9afb
Author: Jun Cai <juncai@chromium.org>
Date: Thu May 10 21:09:18 2018

Merge to release branch M67: Network Service: Change back how the |is_main_frame| value is obtained

This CL merges the following CL to M67 branch:
https://chromium-review.googlesource.com/c/chromium/src/+/1050935

The previous merge CL:
https://chromium-review.googlesource.com/c/chromium/src/+/1054171
was reverted due to compile failure:
https://chromium-review.googlesource.com/c/chromium/src/+/1054347

This CL fixed the compile failure by adding |resource_type| parameter to the
NetworkServiceClient::OnAuthRequired() mojo interface.

TBR=jam@chromium.org, mmenke@chromium.org, tsepez@chromium.org

Bug:  840176 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_mojo
Change-Id: I07d246aac10af5c99838a80aea09a67d661977f0
Reviewed-on: https://chromium-review.googlesource.com/1054498
Reviewed-by: Jun Cai <juncai@chromium.org>
Cr-Commit-Position: refs/branch-heads/3396@{#559}
Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}
[modify] https://crrev.com/ce4ddb7fd29eae2b9a0b27a2c7a4fc1adb0a9afb/content/browser/loader/resource_dispatcher_host_impl.cc
[modify] https://crrev.com/ce4ddb7fd29eae2b9a0b27a2c7a4fc1adb0a9afb/content/browser/network_service_client.cc
[modify] https://crrev.com/ce4ddb7fd29eae2b9a0b27a2c7a4fc1adb0a9afb/content/browser/network_service_client.h
[modify] https://crrev.com/ce4ddb7fd29eae2b9a0b27a2c7a4fc1adb0a9afb/services/network/public/mojom/network_service.mojom
[modify] https://crrev.com/ce4ddb7fd29eae2b9a0b27a2c7a4fc1adb0a9afb/services/network/url_loader.cc

ping abdulsyed@chromium.org for Merge-Request-66 based on comment #13, #14 and #17.

Sorry, I should have posted here - I talked to abdulsyed.  Given the relatively low number of reports about this, and that we're already have way from M66 to M67, and there are no current plans to spin another Chrome 66, the thinking is not to merge / not to re-spin Chrome 66 just for this.

 Issue 842269  has been merged into this issue.

Is this issue also linked to https://bugs.chromium.org/p/chromium/issues/detail?id=839724 ?

laurent.mignon@acsone.eu, thanks for the reminder, I commented on  issue 839724  to see if the issue can still be reproduced.

Able to reproduce the issue on chrome reported version 66.0.3359.139
Verified the fix on Mac 10.13.3, Windows-10 & Ubuntu 17.10 on Chrome version #67.0.3396.48 as per the comment#0 & 3
Attaching screen cast for reference.
Observed "Browser stayed on the same page and asked for credentials, after providing credentials it resume normally"
Hence, the fix is working as expected.
Adding the verified label.

Thanks!

Deleted: 840176 - 67.0.3396.48.mp4 2.0 MB

	840176 - 67.0.3396.48.mp4 2.0 MB View Download

 Issue 836824  has been merged into this issue.

Do you guys want me to leave this repro url active, or can I shut it down now?

codecandy2k:  Thanks for asking!  Since you've verified our fix works for you, I think it's safe to go ahead and shut it down.

Okay, thanks. I've deleted the VM, if it's needed again I can put it back up.

 Issue 839724  has been merged into this issue.

 Issue 843861  has been merged into this issue.