Focus doesn't stay in the Omnibox URL upon selecting the chrome menu to copy/cut |
|||||
Issue descriptionChrome Version --> Version 52.0.2730.0 canary (64-bit) OS: Windows & Cros What steps will reproduce the problem? 1. Launch Chrome and navigate to any website. 2. Place the cursor in the omnibox and select the entire URL. 3. Try clicking on Chrome menu to select Cut/Copy/Paste to cut or copy the URL from the omnibox. 4. Verify What is the expected output? The URL should be still selected allowing user to select the Cut/Copy option from the chrome menu. What do you see instead? Selected URL focus is lost from the Omnibox. User cannot either select copy or Cut from the chrome menu. Please find the attached screen shots. Please use labels and text to provide additional information.
,
May 11 2016
Please find the bisect information below: You are probably looking for a change made after 391737 (known good), but no lat er than 391748 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/8a350376c9d1d5d00fe1e8d810d0d5167f374c1d..f00e71eb761f55d65e770fcf3dec1c7a28c0ec3f Suspecting the following: https://chromium.googlesource.com/chromium/src/+/24c156252c11425af51d646cd0d405f018c70bb8 @karandeep, can you please take a look at this issue ?
,
May 11 2016
Have confirmed my CL is the cause. A fix is under review - https://codereview.chromium.org/1963563002/
,
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
,
May 16 2016
,
May 20 2016
Chrome:52.0.2739.0/OS:8350.0.0 |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by pucchakayala@chromium.org
, May 10 2016