I also had a tab open with my G+ stream which contained a link to that tweet, but mousing over that post doesn't produce this tooltip.

I can't reproduce this. For that matter, I can't even imagine how this could happen.

Here's what I tried to reproduce it:

1) Open a hangout in Tab 1
2) Open a single tweet in Tab 2
3) Switch back to Tab 1
4) Mouse over the video controls

I wonder if this is a race condition with tab visibility, or a visibility change event is getting lost somewhere. CCing ccameron, who might know.

I wonder if the bug is server-side (considering that G+ and Hangouts had the shared content).

rpop: Have you seen this again? Not really sure there's anything we can do about this right now without more information or a reproduction.

It sounds like the UI that your seeing is not just part of another window showing through (which would be really worrying), but rather, content you would have expected from another window, being displayed in a tooltip-like dialog in your current window?

I have seen this many times, but don't have steps to reproduce. I will watch for it to happen again and try to piece together the cause.

rpop@, imagining the hangouts tab content and the tweet-tab content placed one of top of the other, do you think the tweet was directly under the hangouts controls (where you were mousing) or somewhere else entirely on the other page?

#4: I haven't seen this again since filing the bug, and the UI I saw is in a screenshot in the original report. It wasn't something showing through from another tab - it was content from another tab shown in a different format in the current window.

#5: The tweet was open in another tab in "single tweet view", so it was much lower on the page than the spot where the tooltip appeared. 

It looked to me like Hangouts was trying to show a tooltip related to the control I moused over, and the wrong text was displayed.

I am able to reproduce this problem (or at least a variant of it) with the following steps:

1. Open a hangout chat using the Hangouts extension. This presents a small rectangular window filled with chat content at the lower-right corner of your screen.
2. Make sure there's a conversation in the window.
3. Place your mouse over one of the chat bubbles - if you leave it there for roughly 3 seconds the tooltip will appear. I can time it in my head. What you have to do is move the mouse away from the window just before the three seconds have elapsed.
4. When you time it just right, the tooltip for the chat bubble will appear just down and to the right of your mouse pointer.

This is with Chrome 49.0.2623.87. See the attached movie for a demo.

I don't know if we're using the OS X tooltip machinery or if Blink is putting up its own tooltip windows, but it seems when the tooltip timer triggers the code is placing the tooltip where the cursor currently is instead of where it was when the timer went off.

Deleted: TooltipBug.mov 173 KB

TooltipBug.mov 173 KB Download

Blink calls content::RenderWidget::setToolTipText() with text and direction hint(LTR/RTL). So, RenderWidget should place tooltip in right location.

Leakage out of tab seems like a pretty serious UI bug.

pucchakayala: Can you find someone to bisect this bug?

Note: Followed the Steps to reproduce mentioned in the Description, Comments #2 & #8.

Unable to repro this issue on MAC (10.11.4) for Google Chrome Stable Version - 50.0.2661.86

Tested multiple scenarios -> Hangout App & Extensions.

Screen-recordings are attached.

@rpop: Could you please perform the steps mentioned beneath and let us know your observations.

1. Update your Google Chrome Stable Version - 50.0.2661.86
2. Re-test the same on a clean profile [chrome://settings -> Add Person]

Thank you.

Deleted: 592085 - Hangout App.mov 12.0 MB

592085 - Hangout App.mov 12.0 MB Download

Deleted: 592085 - Hangout Extension.mov 13.2 MB

592085 - Hangout Extension.mov 13.2 MB Download

The problem is still fairly easy to reproduce. The timing has to be just right - you may have to try it many times before you see it. In my movie in #8 I just happened to get it right away.

I tried my steps again in 50.0.2661.86 and was able to reproduce many times. Attached is a small screenshot showing the tooltip in the wrong place.

Deleted: Screen Shot 2016-04-22 at 9.51.33 AM.png 175 KB

	Screen Shot 2016-04-22 at 9.51.33 AM.png 175 KB View Download

More info on reproducing. It looks like if there's a region in a web page that contains a tooltip, simply moving the mouse out of that region to another spot on the page appears not to trigger the bug. You have to move the mouse completely out of the page, so that it's over another window. I'm guessing that Chrome is correctly resetting the tooltip when you move to another location within the page but then gets confused or mistakenly does nothing when you move completely out of the window.

Attached is a movie showing how I am able to reproduce this problem at will (for the most part) using the Google home page. This movie was again made with 49.0.2623.87 but I have 52.0.2713.0 and the same steps easily reproduce the problem.

Based on the comment in #9 and following the code a little bit, I guess the renderer process sends an IPC to the browser process telling it that it needs to display a tooltip. I'm guessing that when the browser receives the IPC, it proceeds to display the tooltip at the current location except the mouse moved from where it was originally.

Deleted: EarthDayTooltip.mov 686 KB

EarthDayTooltip.mov 686 KB Download

still unable to reproduce the issue on MacBook Pro (Retina) 10.11.4 chrome version 52.0.2715.0 - Opened a hangout conversation on one window which is foreground and opened google plus on another window which is background and moved the mouse from the comments to the hangout  - observed no tooltip persisting on foreground window.

shrike@, Could you please let us know the OS details for further triaging

It's running 10.11.4.

shrike@, Somehow i could not reproduce the issue on same mac version 10.11.4 - Please find the screencast

Could you please let me know if i am missing something here in reproducing the issue

Deleted: Tooltip.mov 13.5 MB

Tooltip.mov 13.5 MB Download

I think #13 is on the money. Looking at the code:

Browser receives ViewHostMsg_SetTooltipText
-> RenderWidgetHostImpl::OnSetTooltipText
-> RenderWidgetHostView::SetTooltipText

then looking at RenderWidgetHostViewMac::SetTooltipText:

[cocoa_view_ setToolTipAtMousePoint:tooltip_nsstring];

So if the mouse moves in between when the renderer issues the IPC and the browser handles it, the tooltip will appear where the mouse is moved to.

I'm about to validate this theory by passing the expected mouse position along with the IPC.

ellyjones@ - re: the Appkit tooltip machinery requiring tooltip appearance at the current mouse position, I realized that's not a problem at all. The bug occurs because the renderer requests a tooltip at the current mouse location, but the mouse is in a new location when the IPC with the tooltip request arrives at the browser. When this happens, we don't actually want to display the tooltip at all. If the mouse movement had happened an instant earlier the renderer would not have sent the tooltip request.

In short, if the IPC arrives with a tooltip request, and the mouse location in the IPC is significantly different from the current mouse location, the browser should just drop the tooltip request.

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This issue is Pri-1 but has already been moved once. Lowering the priority and moving to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

#18: it's not that simple, I think. The behavior of tooltips for page elements seems to be based on how long the mouse has been over the element, not how long the mouse has been stationary. If you jiggle the mouse such that it stays over an element, we spawn a tooltip and the tooltip remains until the mouse leaves the element. Dismissing the tooltip if the new mouse position doesn't match the mouse position when it was sent seems like it would break that :\

Okay, after further research:

There are basically two mouse events that tooltips care about: WebInputEvent::MouseMove and WebInputEvent::MouseLeave. The code to show and hide tooltips in ChromeClient::mouseDidMoveOverElement only triggers for MouseMove events, because only MouseMove events can hit an element. However, if you move the mouse fast enough from inside the frame to outside, you can get a MouseLeave event without any intervening MouseMove events, which means the tooltip won't get cleared. So, there probably needs to be ChromeClient::mouseDidLeave(), called at the appropriate place, to clear the tooltip when the mouse leaves the frame.

The second issue in this bug is the tooltip showing when you switch tabs, and I suspect that has the same root cause - when we get the "frame got hidden" notification, we need to tell ChromeClient so it can clear the tooltip.

Neither of these seem like they'll be that hard to fix.

Can you grab the element's bounds? Instead of a point (the mouse location) you could send a rect, and check that the mouse is within the rect before displaying it.

I see this on Windows M53 now. The names of people in the top conversation in the Hangouts app shows through to a browser windows on top of it. I don't have reliable repro.

Hi ellyjones@ - this is the Quality of Life bug I've marked for you for completion in Q4.

Migrating to more generic platform label, so that it can be applied to other platforms (i.e. I love the idea).

https://codereview.chromium.org/2681803002/ implements the behavior suggested in #23.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a741cc8edf82ff1bf0850f9f8756419d6eaf60d0

commit a741cc8edf82ff1bf0850f9f8756419d6eaf60d0
Author: ellyjones <ellyjones@chromium.org>
Date: Wed Feb 22 18:13:42 2017

blink: clear tooltips on frame leaves

If the mouse exits a frame fast enough, EventHandler can receive a
MouseLeave event without any intervening MouseMoved events. In this case, if
there was a tooltip for a previously hovered tooltip, the tooltip does not get
dismissed, which can cause it to draw over other apps or windows. The solution
is to dismiss any active tooltip for a frame when the mouse leaves that frame.

BUG= 592085 

Review-Url: https://codereview.chromium.org/2681803002
Cr-Commit-Position: refs/heads/master@{#452130}

[modify] https://crrev.com/a741cc8edf82ff1bf0850f9f8756419d6eaf60d0/third_party/WebKit/Source/core/input/EventHandler.cpp
[modify] https://crrev.com/a741cc8edf82ff1bf0850f9f8756419d6eaf60d0/third_party/WebKit/Source/core/input/EventHandlerTest.cpp

I think this is now Fixed.

Thank you for fixing this!!!