New issue
Advanced search Search tips

Issue 908059 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner:
Closed: Nov 28
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression: Cursor is not seen in search text field after navigating on 'chrome://settings/people' page

Reported by pranjali...@etouch.net, Nov 23

Issue description

Chrome Version:72.0.3619.0 (Official Build) c1cb2d33f1513aa3900c3fce0470cf76faad4458-refs/branch-heads/3619@{#1} (32/64 bit)

OS: Win(7,8,8.1,10) ,Mac(10.13.1 , 10.13.6 , 10.14.2)and Linux(14.04 LTS).

Precondition: Sign into chrome with valid credentials.

Steps to reproduce:
1. Launch chrome and click on avatar icon.
2. Now click on 'Syncing to' which will navigate to 'chrome://settings/people' page.
3. Observe.

Actual  : Cursor is not seen in search textfield after navigating on 'chrome://settings/people' page 
Expected: Cursor should be seen in search textfield after navigating on 'chrome://settings/people' page

This is regression issue broken in ‘M-72’,
Good build: 72.0.3592.0
Bad build : 72.0.3593.0

Unable to provide 'per-revision' bisect as it shows "RuntimeError : We don't have enough builds to bisect..." error message for above range. 
Hence provided suspect through 'Chromium bisect'.

Narrow Bisect info : 

https://chromium.googlesource.com/chromium/src/+log/85cc4f5af681946600167ace009f5712b64f0143..5ffb1bbb3e68099dc0643fc502191b009d4f93df	

Suspect: https://chromium.googlesource.com/chromium/src/+/b2106573e7a67ccb2a51fe4178450e28ea770c43

@weiliangc: 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!
 
Actual Result.mp4
170 KB View Download
Expected Result.mp4
177 KB View Download
Cc: ma...@igalia.com blundell@chromium.org dpa...@chromium.org
Owner: aee@chromium.org
Looking at the range of CLs between two revisions: https://chromium.googlesource.com/chromium/src/+log/72.0.3592.0..72.0.3593.0?pretty=fuller&n=10000

Suspect either: https://chromium-review.googlesource.com/c/chromium/src/+/1284064
 or https://chromium-review.googlesource.com/c/chromium/src/+/1261637

From looking at those two CLs, it seems *much* more likely to be https://chromium-review.googlesource.com/c/chromium/src/+/1284064 than https://chromium-review.googlesource.com/c/chromium/src/+/1261637. The latter is a straightforward API migration; I double-checked it and all looks correct.
Status: WontFix (was: Assigned)
This is not a regression. The work that changed this functionality was addressing the issue https://bugs.chromium.org/p/chromium/issues/detail?id=870732.

When loading a section URL like "chrome://settings/people", the focus is on the section instead of the search box. I think it is reasonable that the focus is not on the search since the search would reset the URL to the base "chrome://settings" URL.

In order to have the focus remain on the search box when navigating directly to the section URL, we could conditionally skip to the section in the URL when pressing tab. For instance, if the user did not scroll or interact with the page in any way, tab would jump to the first visible section.

The section URL loses some meaning when scrolling especially when the section is no longer on the screen. Possible options include removing the section portion of the URL or updating the URL when scrolling to a different section.

In order to improve settings navigation, we need to consider keyboard only, mouse/keyboard, and touch only interactions. It is also important to consider what is encoded in the URL and what will be stored in the history page state.

Sign in to add a comment