Clicking through interstitial hangs input until navigation completes
Reported by
jleedev@gmail.com,
May 22 2018
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3437.2 Safari/537.36 Steps to reproduce the problem: 1. Open an HTTPS interstitial 2. Choose "Proceed to localhost (unsafe)" 3. Before navigation completes, try to use keyboard shortcuts What is the expected behavior? Page should be in a relatively normal loading state What went wrong? Keyboard shortcuts are all broken: Cmd-T, Ctrl-Tab, etc. The only shortcut that works is Tab (which can actually focus the browser UI to break out of the tab contents). The tab strip does not show a throbber or any icon, so the visual cue that a page is loading is missing. It just looks broken. The only indication that anything is happening (indeed, the only indication that a click was even registered on the "Proceed" link) is a small status bar appears with "Waiting for localhost…", but this is all the way in the bottom (and not animated, like the tab loading spinner should be). Did this work before? N/A Chrome version: 68.0.3437.2 Channel: canary OS Version: OS X 10.13.4 Flash Version: badssl.com is way too fast to test this (although I didn't try slowing it down with the devtools). This is the test environment I used to simulate an HTTPS site that hangs forever and also triggers an interstitial: Terminal 1: caddy 'tls self_signed' 'proxy / localhost:9001' Terminal 2: while :; do nc -l 9001; done
,
May 24 2018
Tried testing the issue on mac 10.13.3 using latest canary #68.0.3439.0. Following are the steps followed to reproduce the issue. ------------ 1. Ran command Terminal 1: caddy 'tls self_signed' 'proxy / localhost:9001' but an error got generated as -bash: caddy: command not found jleedev@ - Could you please provide any other sample file/test url to test the issue from TE-end. Thanks...!!
,
May 24 2018
I have the same set up running here temporarily: https://104.131.9.20:2015/
,
May 24 2018
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
,
May 24 2018
Also, I found this easiest to test in guest/incognito, to ensure that both the certificate warning and cached page are reliably forgotten; I think my frontend serves a 502 after 30 seconds which can then confound further testing in the same session.
,
May 24 2018
Android sees a similar UI state: The progress line does not appear underneath the URL bar, and the Stop/Refresh button does not change to the "Stop" state.
,
May 25 2018
jleedev@ Thanks for the update. As per comment #2, request you to provide a sample file/URL for proceeding further in testing this issue, as without a file/URL we won't be able to test this further. Thanks..
,
May 25 2018
Still running here: https://104.131.9.20:2015/
,
May 25 2018
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
,
May 25 2018
#8 contains the URL in question. Does this repro?
,
May 28 2018
Able to reproduce the issue on Mac 10.13.3 and Ubuntu 14.04 using chrome reported version #68.0.3437.2 and latest canary #69.0.3442.0. Unable to test the issue on OS-Win as the site was not reachable. This is a non-regression issue as it is observed from M60 old builds. Hence, marking it as untriaged to get more inputs from dev team. Thanks...!! |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by krajshree@chromium.org
, May 23 2018