Issue metadata
Sign in to add a comment
|
Regression:Highlight effect stays on original tab even after duplicate tab is opened. |
||||||||||||||||||||
Issue descriptionChrome Version: 73.0.3673.0 (Official Build) Revision e5cdf80fb8b493b3be23fc5b7bfac5278aa83225-refs/branch-heads/3673@{#1}(64 bit) OS: Mac(10.13.1 , 10.13.6 , 10.14.3) Steps to reproduce: 1. Launch chrome, open a tab. 2. Right click on the tab and choose 'Duplicate' option from the context menu. 3. And observe the highlight effect stays on the original tab(till next mouse movement). Actual Result : Highlight effect(same as mouse hover highlight effect) stays on original tab even after duplicate tab is opened. Expected Result : Highlight effect should leave original tab as soon as This is a regression issue broken in M-70 and below is the chromium bisect information: Good Build : 70.0.3503.0 (Revision : 578160) Bad Build : 70.0.3504.0 (Revision : 578510) You are probably looking for a change made after 578316 (known good), but no later than 578340 (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/7eb1a6cc55d29d9709e7799529996e9902d769d1..8e95eafa315bdf27b8f52c2eb64c939e618ac6d0 Suspect: r578334 ? @ellyjones: 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: 1. Unable to provide 'per-revision' bisect as it shows "We don't have enough builds to bisect" error message for above range, hence providing chromium bisect. 2. Issue is not reproducible on Linux(14.04 LTS) and Windows(7,8,10) OS. 3. Issue is also seen on Stable #71.0.3578.98, Beta #72.0.3626.64. Kindly refer the attached screen cast.
,
Jan 17
(5 days ago)
I'm not sure this is going to be good effort/reward to fix. We would need to plumb some way for the tab to know that the context menu exited, where it would check for mouse position.
,
Jan 17
(5 days ago)
Huh, ew. Yeah, okay - I'm happy to kick this to Pri-3 M-X.
,
Jan 17
(5 days ago)
Leaving it assigned, but if anyone wants to work on it, feel free to take it :)
,
Jan 17
(5 days ago)
On Windows, the highlight disappears as soon as the context menu opens, because the mouse is captured by that menu and thus the tab is not (and cannot become) "hovered". You might be able to do something similar given that Mac is now on Views and thus hopefully using the same codepaths...
,
Today
(15 hours ago)
Most Mac native apps keep the hover state when the context menu is up, which matches my intuition (it's still the "selected" thing). IMO, keeping this is better than fixing this edge case (since it fixes itself as soon as you move the mouse, and is pretty subtle in general with the default theme). OTOH, we are now inconsistent about this, since the bookmark bar uses views menus and behaves like pkasting@ describes. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by ellyjo...@chromium.org
, Jan 17 (5 days ago)Owner: lgrey@chromium.org