More info:
- The bug still occurs if I manually disable all extensions and relaunch the browser.
- HOWEVER, the bug goes away if I launch Chrome with the --disable-extensions flag.

This suggests it's an extension issue, but I'm not sure how a disabled extension could still be affecting browser behavior.

More interesting results:
- The bug only occurs in Incognito mode.
- The bug still affects a newly-created Chrome user profile with no extensions aside from the defaults (Google Docs Offline, and Docs/Sheets/Slides Chrome apps).
- Android still works correctly in Incognito mode.
- The latest continuous build still works correctly in Incognito mode.

- Using a different Windows account on the same computer (with Chrome Beta installed at system level for all users), the bug did not appear on the first try, but then appeared on every subsequent try.  Weird.
  > The Chrome profile had no extensions installed, not even the Google Docs stuff.
  > But again, when launched with --disable-extensions, the bug disappeared.
- On a different computer, the bug did not reproduce.  (Stable channel, but same build as current Beta, 70.0.3538.67.)

I'm wondering if the problem is Incognito per se, or the fact that Incognito has a separate cookie jar and thus you don't have a cookie which the router wants to see. I'm not going to tell you to try to delete cookies, because you may lock yourself out completely. But could you please try to reproduce in the Guest mode or a separate profile?

- The bug does not occur in Guest mode.
- In a separate profile, the bug occurs only in Incognito mode.

Can we grab a net-internals log (instructions here: https://www.chromium.org/for-testers/providing-network-details )?

That way we can see what happened on the wire.

I've attached a log.

Deleted: chrome-net-export-log.json 121 KB

chrome-net-export-log.json 121 KB View Download

The relevant bit is below. Looks like from the network's POV it invoked the network delegate and then didn't attempt to authenticate at all. The READ_BODY line indicates that the browser is attempting to show the error page. Nothing is odd on the wire.

t=3765 [st= 0] +REQUEST_ALIVE  [dt=35]
                --> priority = "HIGHEST"
                --> url = "http://192.168.1.1/"
t=3765 [st= 0]    NETWORK_DELEGATE_BEFORE_URL_REQUEST  [dt=0]
t=3765 [st= 0]   +URL_REQUEST_START_JOB  [dt=34]
                  --> load_flags = 2048 (MAIN_FRAME_DEPRECATED)
                  --> method = "GET"
                  --> url = "http://192.168.1.1/"
t=3765 [st= 0]      NETWORK_DELEGATE_BEFORE_START_TRANSACTION  [dt=0]
t=3765 [st= 0]      HTTP_CACHE_GET_BACKEND  [dt=0]
t=3765 [st= 0]      HTTP_CACHE_OPEN_ENTRY  [dt=0]
                    --> net_error = -2 (ERR_FAILED)
t=3765 [st= 0]      HTTP_CACHE_CREATE_ENTRY  [dt=0]
t=3765 [st= 0]      HTTP_CACHE_ADD_TO_ENTRY  [dt=1]
t=3766 [st= 1]     +HTTP_STREAM_REQUEST  [dt=24]
t=3766 [st= 1]        HTTP_STREAM_JOB_CONTROLLER_BOUND
                      --> source_dependency = 76 (HTTP_STREAM_JOB_CONTROLLER)
t=3790 [st=25]        HTTP_STREAM_REQUEST_BOUND_TO_JOB
                      --> source_dependency = 77 (HTTP_STREAM_JOB)
t=3790 [st=25]     -HTTP_STREAM_REQUEST
t=3790 [st=25]     +HTTP_TRANSACTION_SEND_REQUEST  [dt=1]
t=3790 [st=25]        HTTP_TRANSACTION_SEND_REQUEST_HEADERS
                      --> GET / HTTP/1.1
                          Host: 192.168.1.1
                          Connection: keep-alive
                          Upgrade-Insecure-Requests: 1
                          User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.67 Safari/537.36
                          Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
                          Accept-Encoding: gzip, deflate
                          Accept-Language: en-US,en;q=0.9
t=3791 [st=26]     -HTTP_TRANSACTION_SEND_REQUEST
t=3791 [st=26]     +HTTP_TRANSACTION_READ_HEADERS  [dt=6]
t=3791 [st=26]        HTTP_STREAM_PARSER_READ_HEADERS  [dt=6]
t=3797 [st=32]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                      --> HTTP/1.0 401 Unauthorized
                          Server: uhttpd/1.0.0
                          Date: Tue, 23 Oct 2018 18:29:14 GMT
                          WWW-Authenticate: Basic realm="--- elided ---"
                          Content-Type: text/html; charset="UTF-8"
                          Connection: close
t=3797 [st=32]     -HTTP_TRANSACTION_READ_HEADERS
t=3797 [st=32]      NETWORK_DELEGATE_HEADERS_RECEIVED  [dt=0]
t=3797 [st=32]      NETWORK_DELEGATE_AUTH_REQUIRED  [dt=1]
t=3799 [st=34]      NETWORK_DELEGATE_HEADERS_RECEIVED  [dt=0]
t=3799 [st=34]   -URL_REQUEST_START_JOB
t=3799 [st=34]    URL_REQUEST_DELEGATE_RESPONSE_STARTED  [dt=0]
t=3800 [st=35]    HTTP_TRANSACTION_READ_BODY  [dt=0]
t=3800 [st=35]    URL_REQUEST_JOB_FILTERED_BYTES_READ
                  --> byte_count = 308
t=3800 [st=35]    HTTP_TRANSACTION_READ_BODY  [dt=0]
t=3800 [st=35] -REQUEST_ALIVE

Bug still occurs on the new 71 beta, Chrome 71.0.3578.20 (Official Build) beta (64-bit) (cohort: Beta).

I can confirm this is an ongoing issue, tested with beta and unstable releases for Linux amd64, currently still issue with latest unstable (Version 72.0.3590.0 (Official Build) dev (64-bit)), however i've met the same issue several times, possibly up from unstable v70.0.x versions

Reproducible with public Basic Auth endpoints, such as https://jigsaw.w3.org/HTTP/Basic/

Also the proposed solution works (using --disable-extensions cmd switch), manually disabling all extensions did not help.

However in clean-profile google-chrome-beta (Version 71.0.3578.20 (Official Build) beta (64-bit)) basic auth behaves as expected.
Clean profile has only Google extensions enabled (Docs, Sheets, Slides, Google Docs Offline).

I've tested that re-installing all the extensions missing in beta from unstable, does not change the behavior. It does not, after installing all missing extensions (exact same versions), beta login dialog still pops-up in incognito.

I've also tested, that using clean profile for the unstable (dev) version, does not fix the issue. (using the --profile-directory cmdline switch)

Comparing the requests in incognito and normal window, does not bring up any differences at all, i don't suspect this is issue of network-flow handling.

Ok, i've managed to do clean-test-reproduce.

I've used google-chrome-unstable with switch "--user-data-dir=", tested that the behavior is expected on first run, did an backup, restarted browser several times and got the browser to reproduce the issue.

Now you can test reproduce the issue, folder within attachment "gcudatawork" is working clean copy of data-dir, "gcudatanotworking" is broken one, which in 100% cases, does not show authorization pop-up in incognito mode.

Deleted: working_and_not_working_data_dir.zip 6.2 MB

working_and_not_working_data_dir.zip 6.2 MB Download

Last one i'm giving this issue today, deleting JSON file "Local State" from "gcudatanotworking" directory fixes the issue.

Workaround, tested with unstable chrome (and possibly working for all versions) is to close the browser, delete "Local State" file, reopen and the issue is gone.

Thanks for reproducing the bug!  Interestingly, it seems to have been fixed in today's beta (71.0.3578.30).  This commit was in the changelog:

https://chromium.googlesource.com/chromium/src/+/a86e02b5ff551cf508cf8a28c315cdaf8e1b738d