Regression:Cursor does not stay on Passphrase text field
Reported by
vineetha...@etouch.net,
Jun 6 2018
|
||||
Issue descriptionChrome Version: 69.0.3451.0 (Official Build)730eb2a66728e72acca3a4e3a661505f8e5574c0-refs/branch-heads/3451@{#1} (32/64-bit) OS: Mac(10.12.6,10.13.1,10.13.6), Windows(7,8,8.1,10) and Linux(14.04) OS Pre-condition: Set a passphrase for Chrome Sign in account. What steps will reproduce the problem? (1) Launch Chrome and sign in to chrome with valid credentials, Click on 'Ok, Got It' button. (2) Now navigate to chrome://settings/syncSetup, enter an invalid input in Passphrase textfield and click 'Submit' button. (3) Click on the back arrow besides 'Advanced Sync Settings' to navigate to chrome://settings/people. (4) Click on 'Sync' option to navigate back to chrome://settings/syncSetup and observe the cursor. Actual Result: Cursor does not stay on Passphrase text field. Expected Result: Cursor should stay on Passphrase text field. This is regression issue broken in ‘M-68’ and providing the bisect using per-revision bisect, Good build: 68.0.3425.0(Revision: 557063) Bad build : 68.0.3427.0(Revision: 557428) You are probably looking for a change made after 557076 (known good), but no later than 557077 (first known bad). CHANGELOG URL: The script might not always return single CL as suspect as some perf builds might get missing due to failure. https://chromium.googlesource.com/chromium/src/+log/93e0c457e3eaa198899e7498526c24f1e1260ac0..ba0669a2a785eabe7b86248605579c7a2a66b96d Suspect: https://chromium.googlesource.com/chromium/src/+/ba0669a2a785eabe7b86248605579c7a2a66b96d @hcarmona: 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. Thank You!
,
Jun 7 2018
,
Jun 7 2018
If the user entered this page by pressing the passphrase-incorrect message, then the user intent is clearly to provide the correct passphrase, versus entering via another route where the intent is unknown. In this case the page is more like a modal dialog, and thus the issue is akin to a modal dialog not being focused on the first writeable field. For the specific case where the user entered in response to the passphrase-incorrect message, this behavior is a step backward in usability, especially after so many years of intuitive behavior. Is there a specific reason why we believe the user is better served by pressing back after acting on the browser's request to correct the incorrect passphrase?
,
Jun 7 2018
Re-opening this issue to address #3. > Is there a specific reason why we believe the user is better served by pressing back after acting on the browser's request to correct the incorrect passphrase? The motivation behind this was to increase a11y of subpages, but it does not take into account any specific subpage needs (treats them all the same). @hector: Any thoughts on whether an exception can be made for the passphrase case?
,
Jun 7 2018
When navigating from the "Enter Passphrase" button in the profile (non-webui), I'm seeing the passphrase field focused (this is the use case comment #3 mentions) When navigating only through webui (chrome://settings/people, click on "Sync"), then the passphrase field isn't focused b/c this matches how the other sub pages navigate. I would prefer to avoid adding a special case when navigating to this one webui sub page. I think Issue 831030 is different than this one because while the passphrase field is focused (blue underline), the overall focus is outside the webui in the omnibox. Marking this issue as 'WontFix' and reopening Issue 831030 because it's about overall focus, not focus within the webui.
,
Oct 10
Issue 859044 has been merged into this issue. |
||||
►
Sign in to add a comment |
||||
Comment 1 by hcarmona@chromium.org
, Jun 6 2018