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

Issue 610186 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: May 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression: Weird behaviour is seen on using enter for zoom options in wrench menu.

Project Member Reported by sc00335...@techmahindra.com, May 9 2016

Issue description

Version: 52.0.2729.0 dev
OS: Ubuntu 12.04,14.04,windows

What steps will reproduce the problem?
(1) Launch chrome and open wrench menu >> Using arrow keys navigate till you reach Zoom "-" or "+" sign
(2) Now hit Enter continuously and observe

Expected: On reaching Zoom "25%" or "500%" nothing should happen even on pressing enter

Actual: Instead now on hitting enter after "25%" or "500%" focus shifts to wrench menu button and again hitting enters new tab opens

This is a regression issue broken in M52. Will provide bisect info soon.
 
Actual_zoom.ogv
689 KB Download
Labels: -Needs-Bisect hasbisect
Owner: karandeepb@chromium.org
Status: Assigned (was: Unconfirmed)
CHANGELOG URL:
 https://chromium.googlesource.com/chromium/src/+log/07997eedaf5f406b931e8f3cfa837a039d0e1f0c..2ed9de59b70764210324c594634228ae882c75bd

Suspecting  https://codereview.chromium.org/1894383002 from changelog.

@karandeepb: Please help in re-assigning if it is not related to your change.
Good Build:  52.0.2725.0 dev
Bad Build:  52.0.2726.0 dev

Expected_zoom.ogv
645 KB Download
Able to reproduce the issue on windows 7 using chrome version 52.0.2729.0.
Yeah this is related to my CL. Will issue a fix soon.
Labels: ReleaseBlock-Stable
Adding the stable blocker as this is recent regression,Please feel free to remove if not required.
Status: Started (was: Assigned)
CL - https://codereview.chromium.org/1963563002/
Project Member

Comment 7 by bugdroid1@chromium.org, May 16 2016

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

commit 8c6b2ee186d786623f0e4cb6d05c08c934c0ff9b
Author: karandeepb <karandeepb@chromium.org>
Date: Mon May 16 01:14:44 2016

Views: Change View::RequestFocus to respect keyboard accessibility.

This CL fixes some regressions introduced in http://crrev.com/1894383002/. These
regression are caused due to the change in View::RequestFocus() from
IsFocusable() to IsAccessibilityFocusable().

On a mouse click on a CustomButton, CustomButton::MousePressed() requests focus
on the button, if it has request_focus_on_press_ set to true. It turns out that
most button subclasses, do not explicitly set request_focus_on_press_ to false,
which has a default value of true. These custom buttons which are accessibility
focusable, can now gain focus on a mouse press, hence the bug.

This CL changes View::RequestFocus to use IsFocusable when keyboard
accessibility is off (i.e on Non-Mac platforms), hence fixing bugs  609701 ,
610186, 610235, 610740, 610802, 610664. This is how View::RequestFocus behaved
before crrev.com/1894383002 on Non-Mac platforms. Also, on Mac, since
View::RequestFocus now respects keyboard accessibility,  bug 611280  is also
fixed.

BUG= 609701 ,  610186 ,  610235 ,  610740 ,  610802 ,  610664 ,  564912 ,  611280 

Review-Url: https://codereview.chromium.org/1973073003
Cr-Commit-Position: refs/heads/master@{#393781}

[modify] https://crrev.com/8c6b2ee186d786623f0e4cb6d05c08c934c0ff9b/chrome/browser/ui/views/tabs/tab_unittest.cc
[modify] https://crrev.com/8c6b2ee186d786623f0e4cb6d05c08c934c0ff9b/ui/views/focus/focus_manager.cc
[modify] https://crrev.com/8c6b2ee186d786623f0e4cb6d05c08c934c0ff9b/ui/views/focus/focus_manager_unittest.cc
[modify] https://crrev.com/8c6b2ee186d786623f0e4cb6d05c08c934c0ff9b/ui/views/view.cc

Status: Fixed (was: Started)

Sign in to add a comment