Issue metadata
Sign in to add a comment
|
Incomplete/immature input focus after basic auth dialog
Reported by
sco...@walkermowers.com,
Jul 7 2017
|
||||||||||||||||||||||||
Issue description
Chrome Version : 59.0.3071.115 (64-bit) xubuntu 16.04 FAIL
: 59.0.3071.115 (64-bit) windows 10 FAIL
: 61.0.3141.7 (64-bit) xubuntu 16.04 FAIL
URLs (if applicable) :
(use Incognito Mode)
http://dev.walker.com/bug FAIL
http://dev.walker.com/bug/simple.html FAIL
http://dev.walker.com/bug?workaround=1 OK
http://fred:fred@dev.walker.com/bug OK
Other browsers tested:
Firefox 49.0: OK
Chrome 58.0.3029.110 (64-bit) xubuntu: 16.04 OK
What steps will reproduce the problem?
(1) Having no previous contact/cache (use incognito mode to insure) visit a basic-auth protected webpage with an input form.
example at http://dev.walker.com/bug user=fred passwd=fred
simple example at http://dev.walker.com/bug/simple.html
(2) Observe that first attempt to focus an input element (either through
code or mouse) results in an "immature" focus:
- The element displays no cursor.
- The element shows no focus styling or outline.
- The element's on focus/blur events will be ignored.
+ But you will be able to type into the input element!?
+ If you TAB, you will not then be able to type (as if blurred)
+ If you Shift-TAB, everything will work as normal
+ Can also fix immature state by clicking elsewhere, then back (ie URL bar)
+ Can also fix by switching to another application, then back.
+ Can also avoid by bypassing basic auth login dialog:
example: http://fred:fred@dev.walker.com/bug
+ Can also avoid by adding a dialog to javascript initialization.
example: http://dev.walker.com/bug?workaround=1
What is the expected result?
Clicking or code call to input.focus() should focus input element visually and functionally. Input.blur() event should trigger after leaving.
What happens instead?
While you can type in the "focused" input element, it is not visually apparent that you can do so. And since blur() is not later called, whatever validation or execution should be done as a result of input.blur fails.
This is breaking most of my business data entry and order apps where users have bookmarked pages that require auth.
The example http site was created just for this bug.
(I am aware that basic auth without https is false security.)
,
Jul 7 2017
Use a only one running (and always a fresh) incognito page to trigger bug. Bug only happens after basic auth login dialog interaction. You won't get a basic auth login dialog if any open incognito pages have previously done so.
,
Jul 10 2017
Unable to reproduce the issue on Windows 10 and Ubuntu 14.04 using chrome reported version #59.0.3071.115, latest dev #61.0.3141.7 and latest canary #61.0.3152.0. Attached a screen cast for reference. Following are the steps followed to reproduce the issue. ------------ 1. Freshly installed the chrome latest stable version #59.0.3071.115. 2. Navigated to URL: http://dev.walker.com/bug?workaround=1 3. Observed an authentication page with username and password fields with cursor and outline as expected. Reporter@ - Could you please verify the screen cast and please let us know if anything missed from our side. Thanks...!!
,
Jul 10 2017
1) The problem manifests _after_ authenticating. Use username=fred password=fred 2) Please test for failure using one of the two FAIL examples: http://dev.walker.com/bug FAIL http://dev.walker.com/bug/simple.html FAIL Comment #3 video attempts to produce failure on one of the workarounds that is not expected to produce a failure (?workaround=1 OK)
,
Jul 10 2017
Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 10 2017
When visiting FAIL urls, paste or type the urls into a the URL bar of a new/solo incognito page (or fresh no-cache browser session.) Or use a bookmark to a FAIL URL (that is the mode that causes failures for my customers; bookmarks directly to password protected order entry) Visiting links on a web page (like this one) do not produce the FAIL. Right-click, "Open in Incognito" will not produce the FAIL. Opening this page in Incognito then clicking one of the FAIL links will not produce FAIL.
,
Jul 10 2017
krajshree@ please triage further.
,
Jul 11 2017
,
Jul 11 2017
scottm@ - Thanks for your feedback....!! Able to reproduce the issue on Windows 10, mac 10.12.5 and Ubuntu 14.04 using chrome reported version #59.0.3071.115 and latest canary #61.0.3153.3. Bisect Information: ===================== Good build: 59.0.3067.0 Revision(463157) Bad Build : 59.0.3069.0 Revision(463921) Change Log URL: https://chromium.googlesource.com/chromium/src/+log/6f41f62772e6617844594d3a40e4394f1d6aa923..1453e416f1a511576ff3ee6641e6a77a651b2ef4 From the above change log suspecting below change Review url: https://codereview.chromium.org/2797473005 lfg@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Note: Adding label ReleaseBlock-Stable for M-60 as it seems to be a recent regression. Please feel free to remove the same if not appropriate. Thanks...!!
,
Jul 11 2017
,
Sep 29 2017
,
Sep 29 2017
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by tkent@chromium.org
, Jul 7 2017