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

Issue 633041 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner:
Not on Chrome
Closed: Jan 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , Mac
Pri: 3
Type: Bug-Regression



Sign in to add a comment

Regression: Focus state is not transferred between drawer side bar and content side bar

Reported by dmascare...@etouch.net, Aug 1 2016

Issue description

Chrome Version:54.0.2814.0 (Official Build) e0d4e8e3266cc2a7b8dcecfeff30ce101eac9a8b-refs/heads/master@{#408878} (32/64-bit)
OS: Window (7,8,10), Mac (10.10.4, 10.11.5)

Pre-condition: Window should be restored down.

What steps will reproduce the problem?
1. Launch chrome and navigate to chrome://history
2. Click on ‘Menu’ icon and press ‘Tab’ such that grey highlight/focus is seen on ’Synced tabs’
3. ‘Maximize’ window and again ‘Restore’ it, such that menu overlay is opened.
4. Observe the focus, press ‘enter’ key and then press ‘Tab’ key.

Actual: Focus/grey highlight is not seen on ‘Synced tabs’ option and after pressing ‘enter’ key it does not navigate to chrome://history/syncedTabs
            
Expected: Focus/grey highlight should be seen on ‘Synced tabs’ option and after pressing ‘enter’ key it should navigate to chrome://history/syncedTabs

This is regression issue, broken in ‘M 54’ and below is narrow bisect:
https://chromium.googlesource.com/chromium/src/+log/4dab74137593abb0888e415294aeb80da27362e3..0adaed21be3234480594612cae9dc3e4d8c3c0c6?pretty=fuller&n=1000

Suspecting: r408572

Good build:54.0.2811.0
Bad build:54.0.2812.0

Note: Will soon update the Linux OS info.

 
Actual_history.mov
3.6 MB Download
Labels: -Pri-1 Proj-MaterialDesign-WebUI Pri-3
Summary: Regression: Focus state is not transferred between drawer side bar and content side bar (was: Regression: Focus issue is observed on chrome://history page.)
Labels: ReleaseBlock-Stable
Regressed in M54, tagging in RBS, so that the bug will be in our triaging queue.
Able to reproduce the issue on Mac 10.11.6 using chrome version 54.0.2823.0.

tsergeant@ Could you please look into this issue if it is related to your change,else please route this to an appropriate dev person.

Thanks,
This minor issue does not need to block release.
Cc: kkaluri@chromium.org
Labels: -hasbisect hasbisect-per-revision
Bisect Info:
===========

Good build : 54.0.2811.0,  Revision Range 	408553
Bad build  : 54.0.2812.0,  Revision Range 	408751

After executing the per-revision-bisect script, i got the following CL's between good and bad build versions
===========================================
https://chromium.googlesource.com/chromium/src/+log/4dab74137593abb0888e415294aeb80da27362e3..5844d81e3382eaabda8f366eafb424050a47ec52

The suspecting Change Log is :
-----------
https://chromium.googlesource.com/chromium/src/+/5844d81e3382eaabda8f366eafb424050a47ec52

From the above CL suspecting the below change
---------------------------
Review-Url: https://codereview.chromium.org/2165903003

tsergeant@- Could you please look into this issue, if it's related to your change?  if not could you please help us to reassign this issue to the right owner.


Status: WontFix (was: Assigned)
I'm marking this as WontFix.

This is a really edge-case focus issue. It's not really expected that focus should work like this after resizing the window enough that UI elements move around.

Sign in to add a comment