Issue metadata
Sign in to add a comment
|
Regression:Focus re-appears on wrench menu while opening and closing the wrench menu. |
||||||||||||||||||||||
Issue descriptionChrome Version:59.0.3071.39/9460.27.0 beta channel Peppy,Paine,Minnie,Jerry OS:Chrome What steps will reproduce the problem? (1)Sign in to chrome >> open NTP >>Go to Wrench menu >>Click on Downloads (2)Now observe the icon of wrench menu(kindly refer video) Expected:Focus shouldn't re-appears on wrench menu after wrench menu is closed. Actual:Focus re-appears on wrench menu after wrench menu is closed. This is regression issue as it is working fine in 55.0.2883.105/8872.76.0 stable channel peppy. Note: 1.Issue is not seen in Windows and Linux OS,checked with latest version #60.0.3089.0 dev 2.Able to reproduce issue in 56.0.2924.112/9000.92.0 stable and latest M60 #60.0.3089.0/9531.0.0 dev channel Peppy. 3.Issue is almost seen for all wrench menu options. Attaching screen shots for reference.
,
May 8 2017
Hey Scott, who owns the wrench menu in Chrome? Could you assign this to them? CC'ing a few folks other folks also who have been working on the wrench menu.
,
May 8 2017
,
May 8 2017
Ben, can you take a look? Seems like it could be an issue with MD ripple logic.
,
May 11 2017
The issue is the AppMenuButton is not receiving a MOUSE_EXIT event until the mouse moves over the native Chrome UI. See attached video. sky@ / sadrul@ / anyone, can you shed any insight here and/or point me at some code I can update? Is it possible to be 'better' at dispatching MOUSE_EXIT events...
,
May 11 2017
I wouldn't normally expect an exit to be dispatched when the menu the mouse was over closes. I would think menu closure would need to explicitly reset this state.
,
May 11 2017
In other words you feel like every button that shows a menu (or anything that takes over event capture) needs to explicitly update the mouse over state of the button? That doesn't seem like a very scale-able solution... It would be a lot easier to work with if we guaranteed a MOUSE_EXIT for every MOUSE_ENTER.
,
May 11 2017
Sorry, I was thinking in terms of Windows native WM_MOUSELEAVE and similar not sending you this automatically. It might make sense for the menu controller to send ET_MOUSE_EXITED to something in this case, which is more what I had in mind by "explicitly reset".
,
May 11 2017
,
May 12 2017
I suspect this is happening because of the call to SetMouseHandler(null) here https://chromium.googlesource.com/chromium/src/+/master/ui/views/controls/menu/menu_runner.cc#40
,
May 18 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0a2a69a314c707ddfb83387690242dc86b088eed commit 0a2a69a314c707ddfb83387690242dc86b088eed Author: bruthig <bruthig@chromium.org> Date: Thu May 18 06:58:02 2017 [ash-md] Fixed MenuButton focus appearing after dismissing menus. The InkDrop hover was not properly being set when menus were being shown/dismissed and the event handler target was changing. BUG= 719399 TEST=views_unittests --gtest_filter=*MenuButtonTest* Review-Url: https://codereview.chromium.org/2880623002 Cr-Commit-Position: refs/heads/master@{#472716} [modify] https://crrev.com/0a2a69a314c707ddfb83387690242dc86b088eed/ui/views/controls/button/menu_button.cc [modify] https://crrev.com/0a2a69a314c707ddfb83387690242dc86b088eed/ui/views/controls/button/menu_button_unittest.cc
,
May 23 2017
,
May 23 2017
Verified on Version: 60.0.3107.0 canary Platform: 9579.0.0 veyron_minnie
,
Jun 15 2017
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by rkalavakuntla@chromium.org
, May 8 2017