306669 - Need to hover twice to see the tooltip

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Ria Klaassen (not reading all bugmail)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050831 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050831 Firefox/1.6a1

I don't always see a tooltip on first mouseover.


Reproducible: Always

Steps to Reproduce:
1. Go to https://bugzilla.mozilla.org/show_bug.cgi?id=306662 and put your mouse
on DUPLICATE of bug 245163 in one move.
2. If you don't see the bug reload the page first.

Actual Results:  
Tooltip doesn't appear. Move your mouse, then the tooltip appears.



Expected Results:  
Tooltip should always appear.

Bug depends on the machine I'm using. On the computer I'm using now I never see
the tooltip on first mouseover.
On another computer I mostly need to reload first to see the bug.

Comment 1

[Martijn Wargers (dead)]

I've seen this now and then, but very sporadically.
If I remember correctly, a click in the document makes the tooltip appear again
on hovering the link.

Comment 2

[Adam Guthrie]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050901 Firefox/1.6a1
ID:2005090108

I've seen this multiple times when first loading a bug page and hovering over
the link to see a bug summary. Same thing as Martijn, though. Clicking on the
page and then hoving again seems to fix this. 

This *might* be related to some of the focus issues when loading new pages in
new tabs, although I can't say for sure I had loaded a new tab when this occured.

Comment 3

[Adam Guthrie]

I did some testing and came up with the following:

1. I'm pretty sure this isn't related to bfcache.
2. I'm pretty sure this isn't related to JavaScript.
3. It seems like there is almost a timeout happening. If you wait long enough
after the page loads to hover the link, it will always show the tooltip, but if
you hover it pretty soon after the page loads it won't show it. 
4. I also see this in 1.0.

I tried to make a testcase for this but was unsuccessful.

Comment 4

[Stephen Donner [:stephend] Not actively reading bugmail]

*** Bug 308224 has been marked as a duplicate of this bug. ***

Comment 5

[Wayne Mery (:wsmwk)]

hover is completely dead in SM suite when a timer is hosed, eg Bug 291386 and Bug 318419.  So not same, but perhaps related?

Comment 6

[Ria Klaassen (not reading all bugmail)]

It looks like this has become worse.

Comment 7

[Neil Deakin]

Attachment: make sure current tooltip is cleared properly

What's happening here is that the js function FillinHTMLTooltip is returning false in its popupshowing handler causing the tooltip to not show, but mCurrentTooltip never gets cleared, causing a later tooltip to not appear. Here, a check is made to see if the tooltip actually opened and if not, clears mCurrentTooltip.

Comment 8

[[e-mail]]

Comment on attachment 271723 [details] [diff] [review]
make sure current tooltip is cleared properly

Note: Only marking r+ because I don't think I have r+sr powers here.

>     pm->ShowPopupAtScreen(mCurrentTooltip, mMouseClientX, mMouseClientY, PR_FALSE);
>+    // Clear the current tooltip if the popup was not opened successfully.
>+    if (!pm->IsPopupOpen(mCurrentTooltip))
I was slightly surprised that ShowPopupAtScreen doesn't tell you this...

>+  PRBool IsPopupOpen(nsIContent* aPopup);
...but this looks useful, especially if we can have a scriptable wrapper ;-)

Comment 9

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 271723 [details] [diff] [review]
make sure current tooltip is cleared properly

>Index: layout/xul/base/src/nsXULPopupManager.cpp
>-  while (item) {
>-    if (item->Frame() == aPopup)
>-      return PR_FALSE;
>-    item = item->GetParent();
>-  }
>+  if (IsPopupOpen(aPopup->GetContent()))
>+    return PR_TRUE;

You mean |return PR_FALSE|, right?

With that fixed, sr=bzbarsky