Issue metadata
Sign in to add a comment
|
Regression: Hover effect is seen on background overlay even when wrench menu is opened.
Reported by
sanyam.g...@etouch.net,
Oct 22
|
||||||||||||||||||||
Issue descriptionChrome Version: 72.0.3588.0 (Official Build) Revision 56533f367ba451d6545ab0045e8e11f288b36326-refs/branch-heads/3588@{#1} (64-bit). OS:Mac(10.13.1, 10.13.6, 10.14.1) Pre-condition: Enable "Enable using the Google local NTP" ,"New Tab Page Background Selection" and "New Tab Page Custom Links" flags under chrome://flags What steps will reproduce the problem? 1. Launch chrome, navigate to NTP and click on Gear icon to open the overlay. 2. Now click on wrench menu so that it overlaps on 'customize this page' overlay (if required resize the browser window). 3. Hover the focus on last option of wrench menu, then on 'customize this page' overlay and observe. Actual Result : Hover effect is seen on background 'customize this page' overlay even when wrench menu is opened. Expected Result: Hover effect should not be seen on background 'customize this page' overlay when wrench menu is opened. This is a regression issue broken in ‘M-69’ and below is the bisect info : Good Build : 69.0.3569.0(Revision : 569383) Bad Build : 69.0.3472.0(Revision : 569948) You are probably looking for a change made after 569536 (known good), but no later than 569537 (first known bad). CHANGE-LOG URL: The script might not always return single CL as suspect as some perf builds might get missing due to failure. https://chromium.googlesource.com/chromium/src/+log/993562724eacc4a7c90e925b888640f93e088b51..67221b27f38f964cf0d5b8fa8389c12a2bf79a5a Suspect : https://chromium.googlesource.com/chromium/src/+/67221b27f38f964cf0d5b8fa8389c12a2bf79a5a @tapted: Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Note:Issue is not reproducible on Linux(14.04), Windows(7,8,10). Thank You!
,
Oct 23
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by tapted@chromium.org
, Oct 23Labels: -Pri-1 Hotlist-Polish Pri-3
Owner: ----
Status: Available (was: Assigned)
This is a minor issue. The quirk probably comes about because of some code in web_input_event_builders_mac.mm: case NSMouseExited: event_type = blink::WebInputEvent::kMouseLeave; break; case NSMouseMoved: case NSMouseEntered: event_type = blink::WebInputEvent::kMouseMove; button = ButtonFromPressedMouseButtons(); break; NSMouseEntered is treated identically to NSMouseMoved, and sends a mouse move to the webcontents. There's no "NSMouseEntered" equivalent on Windows. Prior to r569537, NSMouseEntered on the webcontents was funnelled to the menu widget. The problem is base_view.mm has overrides of -mouseEntered: and -mouseExited: . If they don't get events, the much worse issue in Issue 854856 results. I'm not sure what the best fix for this is. Or even if there's a robust way to keep all WebContentses happy. Perhaps the best way forwards is to scrap base_view.mm :/.