New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 787385 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Nov 2017
Cc:
Components:
EstimatedDays: ----
NextAction: 2017-12-01
OS: Linux , Windows , Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Dialog extra views are focusable even when not usefully focusable

Reported by avsha...@etouch.net, Nov 21 2017

Issue description

Chrome Version : 64.0.3274.0 (Official Build) 38c9257b930f883c3ab936b1274590c94cc08012-refs/heads/master@{#518061} 32/64-bit
OS : Mac(10.12.6) (10.13.2), Windows(7,8,10), Linux(14.04 LTS)

What steps will reproduce the problem?
1. Launch chrome and navigate to any secure web page (Ex. www.google.com)
2. Click on ‘Secure’ chip in omnibox and open ‘Cookies’ overlay (by default focus is seen on ‘Done’ button).
3. Hit ‘Up Arrow’ key from keyboard and observe the focus on ‘Done’ button.

Actual Result : Unnecessarily focus gets lost after pressing Up/Down arrow keys.

Expected Result : Focus should stay on ‘Done’ button after pressing Up/Down arrow keys.

This is a regression issue broken in ‘M-64’ and using the per-revision bisect providing the bisect results,
Good build : 64.0.3262.0 (Revision : 514704)
Bad build : 64.0.3263.0 (Revision : 515052)

You are probably looking for a change made after 514895 (known good), but no later than 514896 (first known bad).

CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/9fe2e45556eb6c4515dfa4c5267c552280bee459..3fdef810d4983e1c7640bee65fcf9591e5442fe4

Suspect : https://chromium.googlesource.com/chromium/src/+/3fdef810d4983e1c7640bee65fcf9591e5442fe4

@ellyjones : Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.
 
Actual_button_focus.mov
3.0 MB Download
Expected_button_focus.mov
2.3 MB Download
Labels: ReleaseBlock-Stable
Adding RB Label as this is a recent Regression. Please remove if not required.
Thank You.
Labels: -Pri-1 -ReleaseBlock-Stable Pri-2
Huh. I don't offhandedly know where the focus is going, but this is also not Pri-1 or a release blocker.
NextAction: 2017-12-01
Summary: Dialog extra views are focusable even when not usefully focusable (was: Regression : Unnecessarily focus gets lost after pressing Up/Down arrow keys in 'Cookies' overlay.)
Okay, so, the focus is going to the dialog's extra view, which isn't actually focusable. This is clearly the wrong behavior. The extra view is added to the same group as all of the dialog's buttons. I suspect that either:

1) The extra view shouldn't be automatically added unless it's also a button, or
2) This dialog needs to remove its extra view's group (?)

I will put up a fix this week.
Project Member

Comment 5 by bugdroid1@chromium.org, Nov 29 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8aeebb1251c0edbdf0fe7e46ead07d5cbe2bb7a3

commit 8aeebb1251c0edbdf0fe7e46ead07d5cbe2bb7a3
Author: Elly Fong-Jones <ellyjones@chromium.org>
Date: Wed Nov 29 13:23:14 2017

views: only add extra view to dialog button group when it's a button

If the extra view isn't a button, it should not go in that group.

Bug:  787385 
Change-Id: Ifd06896706f2d506069e7528f074e7675942bd64
Reviewed-on: https://chromium-review.googlesource.com/793970
Commit-Queue: Elly Fong-Jones <ellyjones@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#520091}
[modify] https://crrev.com/8aeebb1251c0edbdf0fe7e46ead07d5cbe2bb7a3/ui/views/window/dialog_client_view.cc

Status: Fixed (was: Started)
The NextAction date has arrived: 2017-12-01

Sign in to add a comment