Views: Stray tooltip appears when when mouse quickly leaves the browser window over UI element that provides one |
|||||||||||||
Issue description
Chrome Version : 56.0.2914.3
OS Version: OS X 10.12.1
Awwww yeah - this has been bugging me for ages and I finally have a repro \o/. (and it's kinda bad)
What steps will reproduce the problem?
1. Scroll webcontents so that an element with a tooltip is at the edge of the browser window
2. Now move the mouse cursor from the inside to the outside of the window in a line that crosses over the element
What is the expected result?
No random tooltip appears
What happens instead of that?
Tooltip appears wherever the mouse happens to be shortly after it leaves the window. It doesn't seem to matter how long the mouse hovered over the element providing the tooltip. Just so long as the last mouse event over the browser window was over the tooltip provider.
To fix, I think we just need to poke some internal state on ToolTipBaseView whenever a mouseExit is seen by -[RenderWidgetHostViewMac mouseEvent:(NSEvent*)]. (That's assuming there's already a tracking area that does NSTrackingMouseEnteredAndExited -- BaseView's initializer does enableTracking, so this is probably the case). In fact maybe ToolTipBaseView can override mouseExited, clear its state, then invoke BaseView's mouseExited.. yeahhhh.
Alternatively, maybe this fragment from ToolTipBaseView can be constrained somehow to a smaller NSRect:
NSRect wideOpenRect = NSMakeRect(-100000, -100000, 200000, 200000);
lastToolTipTag_ = [self addToolTipRect:wideOpenRect
owner:self
userData:NULL];
Anyway, this also affects tooltips used for UI elements in MacViews so I wanna fix it. (It's rarer that a UI element is right at the window edge, but moving the mouse quickly so there's no event in the margin can still cause this).
UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2914.3 Safari/537.36
,
Jan 2 2017
Deprecating UI>OSIntegration in favor of the more generic Internals>PlatformIntegration
,
Feb 7 2017
There's also Issue 592085 - maybe related to this (but that bug also affects Windows)
,
Feb 28 2017
#c0 no longer repros in Canary thanks to Elly's work in Issue 592085 . But it's still possible for tooltips (and hover state it seems) to get stuck in some cases on MacViewsBrowser :/. Although you need to move your mouse "really quickly". So, there are probably still some tweaks to ToolTipBaseView that I'll want to do.
,
Mar 27 2017
I'm also getting this issue. In fact I reported it many years ago here: https://bugs.chromium.org/p/chromium/issues/detail?id=325122 It appeared to be fixed but started happening again a few months ago. It's basically an issue with moving the mouse just as a tooltip is about to appear. You can reproduce it thusly: 1. Move your mouse over a tab wth a long title 2. Wait around a second. 3. Move the mouse away again. A tooltip appears in the middle of the web page.
,
Mar 30 2017
#c5: I haven't been able to repro Issue 317731 in Version 59.0.3055.3 on macOS 10.12.3 What is your Chrome and macOS version? Also note *this* bug only affects a very specific build that isn't released. Please file a new bug if this still occurs for you and link it here.
,
Apr 12 2017
This seems like Pri-3 to me.
,
Oct 12 2017
The reason why this happens on MacViewsBrowser is this: - BaseView manages dragging_ state on mouseDown/mouseUp. - Mouse capture begins on mouseDown. - BaseView cannot get mouseUp because of the mouse capture. processCapturedMouseEvent: in BridgedContentView bypasses the mouse up event to mouseEvent: instead of mouseUp:. - BaseView skips the mouse exit event on mouseExited: when dragging_ is true. When we move mouse slowly, mouse move event handles the tooltip. When we move mouse quickly, mouse move events may not fired and the mouse exit event gets ignored with the reason above.
,
Oct 12 2017
There's Issue 659959 related to the mac_views issue as well - probably the same root cause as this. There's a partial fix there. I think we also need to clear something in BaseView -- I had some ideas in http://crbug.com/659959#c2 There's https://codereview.chromium.org/2456903003/ and https://codereview.chromium.org/2448173002/ as well (But changing BaseView is tricky since it's not just used for mac-views - also injecting all this via inheritance is a bit gross :/)
,
Jan 11 2018
I've able to reproduce this in the latest Chrome (63) on Mac OSX High Sierra. 1. Open several tabs in Chrome. 2. Switch to another app, but make sure you're able to focus Chrome again directly. A small Finder window is good for this (or have multiple monitors). 3. Click on an unselected tab in Chrome, i.e. so you focus Chrome and also switch to a different tab. Then move your mouse into the page immediately. I get the tab's title shown as a tooltip in the middle of the page. See attached.
,
Mar 26 2018
MacViews triage: tapted@, are you likely to be able to look at this for M-69, or should I assign it elsewhere?
,
Mar 27 2018
69 should be possible
,
Mar 27 2018
,
Jul 12
,
Jul 12
,
Jul 19
,
Jul 20
,
Jul 20
Glad to see this is targeted for M70 :).
,
Jul 20
To clarify, #16 broadened this bug to apply to all views platforms.
,
Jul 23
FWIW I couldn't repro the tooltip thing on Mac (Cocoa or Views windows). However, the same steps cause the Status Bar at the bottom of the window to behave as though the element at the edge of the window was still hovered over. Interestingly, it doesn't seem to affect elements with CSS hover (e.g. the `Components` list on the crbug sidebar). Feel free to move this to Available. I'm fine for this to be "in" my queue, but that queue currently has 65 things in it <= Pri-2.
,
Oct 26
Issue 898626 has been merged into this issue.
,
Oct 26
FYI: duped bug has some repro steps |
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 by tapted@chromium.org
, Dec 8 2016180 KB
180 KB View Download
657 KB
657 KB Download