[firefox] tooltips disappear too fast

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

It behaved well for some weeks, but was considered "broken" and repaired per Bug 405094.

This can actually get a little annoying on xkcd.com

I was about to file a similar report. Absolutely needed on xkcd.com.

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

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

[Original text copied in from a duplicate bug report:]

Suggested Improvement to Title Text Display Model
=================================================

In Firefox 3, hyperlink title text (title="description") is no longer
truncated, bringing Firefox into line with Internet Explorer. This is a most
welcome addition -- thanks guys!

The trouble is, Firefox now suffers the same problem that IE does: if the page
author puts a large amount of text in a title string, the user doesn't have
time to read it. This is not necessarily the author's oversight and could be
improved in Firefox.

The current title text display model works something like this:

1. User moves mouse pointer over object and then holds still;

2. After something less than one second of zero pointer motion, the title text
is displayed, wrapping if necessary;

3. A display timer is started;

4. Providing the pointer remains static, the title text displays for a maximum
of five seconds;

5. The displayed text disappears and redisplay is disabled;

6. When the pointer next moves, title text redisplay is enabled, subject 2
above.

From the end-user perspective, this translates as:

1. Move pointer over object, hold still, wait for title text to appear;

2. Read frantically as much as you can before the five-second timer cuts in;

3. If you finished reading it, you're done!

4. If you didn't, move pointer slightly, hold still, wait for title text to
reappear;

5. Quickly find where you left off reading previously and repeat as many times
as needed from step 2, trying to understand the partial sentence you just read
and remembering everything you read before.

This can be a frustrating experience, so I'd like to suggest two possible
display models by way of improvement. The first would be very simple to do,
but still only an approximation of what should occur; the second is the proper
way to do it:

Alternative 1
-------------

Instead of displaying the title text for a fixed time period of five seconds,
display it for four seconds (say) plus some function of the title text length.
Through experimentation, the display time could roughly match the time for a
slow-to-average reader to read the title, given no distractions. For different
languages, this would be an approximation.

From the end-user perspective, this would translate exactly as above, but with
greater likelihood of reading it all first time through.

Alternative 2
-------------

With the existing model, title text display is triggered by zero pointer motion
for a fixed time period. Maintain that, but also use pointer motion as the
event trigger to vanish the text, disabling redisplay until the pointer moves
off the object completely (moving back over the object would re-enable
display). Ditch the display timer.

From the end-user perspective, this would translate as:

1. Move pointer over object, hold still, wait for title text to appear;

2. Read as much of the title text as you want, at your own pace;

3. Read something else, or if the title text is obscuring something, move the
pointer slightly to make it disappear. It will disappear when you next move
your mouse anyway.

The advantage of the...

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

Possible solution is to make timer user configurable:

Change this in http://mxr.mozilla.org/firefox/source/layout/xul/base/src/nsXULTooltipListener.cpp#738
:
738 if ( mAutoHideTimer )
739 mAutoHideTimer->InitWithFuncCallback(sAutoHideCallback, this,
kTooltipAutoHideTime,
740 nsITimer::TYPE_ONE_SHOT);

To
738 if ( mAutoHideTimer )
739 mAutoHideTimer->InitWithFuncCallback(sAutoHideCallback, this,
nsContentUtils::GetIntPref("browser.chrome.tooltip_timeout",
kTooltipAutoHideTime),
740 nsITimer::TYPE_ONE_SHOT);

That way, users who want to change it so it stays around longer can.

I'm not promising to fix this anytime soon, but I'm assigning it to myself so I don't forget it exists.

(and, for the record, bugzilla itself makes a nice testcase for this one -- hover over the word "in-testsuite" up at the top and try to read the entire tooltip before it disappears.)

The proposed patch in Comment #9 would solve the problem, but it's a bit "hacky."

I submitted a proposed patch for this here: https://bugzilla.mozilla.org/show_bug.cgi?id=461980

My patch uses a preference changed callback to limit reads from the preferences. I'm not sure how much of a performance issue this is, but given that tooltips appear on a mousemove event, I thought it would be prudent to do it this way. I essentially duplicated the functionality that was already there for the "browser.chrome.toolbar_tips" preference.

I wasn't sure what to call the preference, but I ended up calling it "browser.preferences.tooltipHideTime" which might not be the best name in hindsight since it affects all XUL applications.

I did search for a similar bug, but didn't find this one until one of the comments on the bug I submitted pointed me to it.

A couple of comments above suggest making the fixed 5-second timer user configurable. That would be a very poor solution. There are already myriad configuration settings for Firefox. It's far better to get the design right. Not all tool tip text is the same size, even on the same webpage. The tool tip pop-up needs to display for a time that is appropriate, not some constant time period.

My earlier comment titled "Suggested Improvement to Title Text Display Model" offers two better methods of achieving this. (Alternative 2 is by far preferred.) The original 5-second timer is a kludge to a problem that wasn't thought through properly. Having a user-adjustable timer would be a quick-fix to a piece of kludge. We don't want more kludge, or more fixes to pieces of kludge; we want it done properly. If done properly, no user configuration setting would be required. Just keep it simple by getting the design right.

Alternative 2 in Comment #7 essentially amounts to doing away with the auto-hide timer altogether. The other functionality that you describe is already there. If you move off an object the tooltip disappears as you describe.

Your suggested fix is as simple as not setting the timer when the tooltip is displayed. Am I correct in my assessment?

Regarding the auto-hide timer, does anyone know the rationale behind including it in the first place?

Re: #14:

It's almost as simple as not setting the timer. The timer expiration currently triggers an event to make the pop-up disappear. That event is still required, but without using a timer. I'm suggesting using resumed pointer motion (after holding still to display the pop-up) as the replacement event trigger. The pointer moving off the object in question would also trigger, and if as you suggest that's already there, that bit doesn't need to change.

Further to my previous comment, #15:

After the pop-up has been "popped down", redisplay of the pop-up needs to be disabled until the mouse pointer moves off the object in question. Moving the mouse pointer back over the same object would re-enable pop-up display. In this way, the end user may redisplay the pop-up if required, but won't be annoyed by the pop-up reappearing undesirably, as it does now. Fairly intuitive, I think. But of course, if the pop-up display time responds to mouse movement, such behaviour would only be required infrequently.

To this end, it might be appropriate to maintain two flags for controlling pop-up behaviour internally: a flag controlling whether the tool-tip should be popped up and a flag controlling whether the tool-tip should be popped down. These would be suitably set or cleared at mouse-enter-over-object, mouse-hover-over-object, mouse-move-over-object and mouse-exit-off-object (or whatever the proper terms are). I leave such detail to the implementer -- only a suggestion.

I talked informally with some people and they came up with a situation where you really do want the auto-hide behavior: a large element with clickable sub-regions (e.g. an imagemap) and a long tooltip. If there were no auto-hide, the tooltip would not go away as long as you had the pointer over the element, and depending where it was, could make it very hard to target the sub-region you wanted.

Re: #17

Agreed that the tool-tip cannot be displayed for the duration of the mouse-over. By triggering the pop-down event on pointer movement, the pop-down would still occur, even if the pointer remained over the object. Hence my suggestion for the use of flags to control the pop-up/pop-down behaviour. The tool-tip needs to pop-up just once, pop down under user direction (slight pointer movement) and then stay down, unless the user deliberately acts to cause it to pop up again (moves pointer off object and hovers over it again).

I too have created pages where having the tool-tip pop down is essential and having it repeatedly pop up on a timer is a nuisance, preventing access to what is underneath. I'm certain this can be solved as above.

Here you can download builds (Windows) from the time that the timer was broken and the tooltip stayed until mouse-out:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007/12/2007-12-01-05-trunk/
I considered this behaviour as ideal. Maybe you can point me to a site where this would give trouble, so I can test this?

Pop-down on *any* mouse movement will be unfriendly to users with hand tremors.

Re #20:

For a user with hand tremors, it's still easy: move pointer over object, let go of mouse. Alternatively, pressing down slightly on a mouse usually causes enough friction to hold it still. With a trackball, take fingers off trackball, etc.

I use a Razer Copperhead set to maximum sensitivity. The slightest movement causes the pointer to whizz off screen, but I can hold it still easily. In a situation where I need to hold the pointer still for a long time, letting go of the mouse works well.

But anyway, to cause the tooltip to appear, the user already needs to hold the mouse still, so what's the difference? To cause it to continue to display, the user just does more of the same, or lets go.

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

Created attachment 345448
Proposed patch making timeout user configurable

This patch reads the tooltip display duration from a preference called
"browser.preferences.tooltipHideTime"

It uses a preference changed callback to limit reads from the preferences.

Comment on attachment 345448
Proposed patch making timeout user configurable

>+ if (sTooltipAutoHideTimeListenerCount++ == 0) {

You don't need a separate 'count' variable here; just put the code in the same block as the other preference that is checked.

>+int
>+nsXULTooltipListener::TooltipAutoHideTimePrefChanged(const char *aPref,
>+ void *aClosure)
>+{
>+ sTooltipAutoHideTime = nsContentUtils::GetIntPref("browser.preferences.tooltipHideTime",
>+ sTooltipAutoHideTime);

Align the second line with the first, after the parenthesis.

Created attachment 345482
Revised patch making tooltip display duration user configurable

Added revised patch fixing up issues raised in Comment #24.

The preference "browser.preferences.tooltipHideTime" must be created by the user. The time is specified in milliseconds. The default time of 5 seconds is used if the preference isn't defined.

Created attachment 345484
Revised patch making tooltip display duration user configurable

Fixed one last issue.

Comment on attachment 345484
Revised patch making tooltip display duration user configurable

> ToolbarTipsPrefChanged("browser.chrome.toolbar_tips", nsnull);
>+ TooltipAutoHideTimePrefChanged("browser.preferences.tooltipHideTime", nsnull);
Possibly browser.chrome.toolbar_tips.timeout?

I wonder if this wants to be an *exposed* pref.

Created attachment 345501
Revised patch making tooltip display duration user configurable with new preference name

Changed preference name from "browser.preferences.tooltipHideTime" to "browser.chrome.toolbar_tips.timeout"

Thinking about it more, I agree with comment 13 et seq., I'm not really happy having this be a pref at all. I was playing devil's-advocate to that line of reasoning yesterday, but I do actually think "stays indefinitely until the mouse is moved and then disappears" would be better overall.

I've been looking at how this is handled in other applications. In GNOME/GTK+, the tooltips appear after a 0.5 second delay and then stay until you move off the object. Adobe Reader 8 is the same. In OOo, tooltips appear instantaneously on mouseover and disappear if you move off the object or after a few seconds have elapsed.

I haven't found a case of the tooltip disappearing as soon as the mouse is moved (i.e. still over the object). I see the logic in not having a timeout, but hiding the tooltip on any mouse movement doesn't seem to be consistent with other applications' behaviour.

Do you think that doing away with the autohide timer alone will achieve the desired behaviour?

Re #31:

Comment #19 suggests that what you describe is ideal behaviour, but comment #17 indicates such behaviour would cause problems.

I have encountered instances where a large tooltip obscured and prevented access to what was underneath, so I see a need for it to vanish without moving the mouse pointer off the object.

This was prompted by Comment #30, but is not a direct response to it. It is an attempt to clarify my earlier description, for the benefit of all:

Let's say the object in question is a graphic image of a button. Imagine what happens:

1. Mouse pointer moves over button. At the image boundary, tooltip display is enabled, but won't display until the user holds still.

2. User holds still for the required time (something less than a second, as at present) and the tooltip is displayed.

3. User continues to do nothing with the mouse and so the tooltip continues to display for as long as the pointer remains static, putting the user in direct control of the tooltip display duration.

4. User finishes reading the tooltip.

5. The moment the mouse pointer next moves, as dictated by the user, the tooltip vanishes. That tooltip is now disabled until the mouse pointer crosses (exits) the image boundary and Step 1 recurs (or perhaps just until Step 1 recurs).

At step 5, the tooltip would vanish if the pointer moved only slightly (remaining over the button), or moved off the button completely (see comment #19).

Stripping out the user interaction parts of the above leaves a description of what the software should do.

Hope this is useful.

Normally a tooltip will appear below the mouse pointer, so it will not obscure the *current* mouse position, and if the user repositions the mouse to point to a part of the object that's underneath the tooltip, then this mouse movement should pop down the tooltip as per comment 33, hence allowing clicking on the part of the object that was obscured by the tooltip.

In this case (tooltip can fit below mouse pointer), I see nothing wrong with then re-popping-up the tooltip at a new position if the mouse were to hesitate at its new position. Waiting for the mouse to leave and re-enter the object may be awkward in two ways: (1) the object may be larger than the viewing area, (2) the object's boundary might not be visible. Therefore if the user wants the tooltip again then the only sure strategy to get it back would be to move the mouse out of the browser window and back in. Re-popup at new mouse position would be better than this (although you might want a slightly longer timeout before re-popup).

If there is not enough screen space for the tooltip to appear below the mouse pointer, then I would suggest trying to position it above the mouse pointer, or to the left or right of the mouse pointer, or something, i.e. try as hard as you can to position the tooltip such that it does not obscure what the mouse is currently pointing at. That way, if the user wants to point at something that's underneath the tooltip, they first have to move the mouse pointer anyway, and as soon as they do this the tooltip disappears.

But what if the tooltip is so absolutely huge that it MUST obscure what the mouse is currently pointing at, because it can't be positioned in any other way? In this case, automatic re-popup is NOT helpful because it will keep getting in the way of whatever you are trying to point at. And it would certainly not be helpful to use the logic from the Microsoft Windows common controls DLL, which appears to be "pop down if mouse pointer happens to be over the tooltip", which can lead to large tooltips flashing rapidly on and off (especially when you're working in giant print i.e. high DPI setting) - the tooltip pops up, the computer realises the mouse is now on top of the tooltip, so the tooltip pops down, then it pops up again, and so on. It seems Windows programmers try to avoid this situation by trying to make sure that the tooltip can definitely fit to the right or left of the mouse (by truncating its contents if necessary), but sometimes the programming of this isn't quite right and the tooltip ends up being just a bit too big and it obscures the mouse and starts flashing.

Perhaps, if the tooltip is very large, then we should wait for a longer timeout before re-popup if the mouse has not left and re-entered the object. This means re-popup is still possible without the user having to know where the object boundaries are, but they still have time to look at the object underneath and point the mouse at things before the tooltip comes back.

Another idea would be to press Escape to pop down the tooltip. Especially if the tooltip is obscuring the whole screen - it might not be obvious that the mouse has to be moved to pop it down (espec...

Let's get back to basics and look at the purpose of the tooltip: it's to provide useful information about the element the mouse pointer is over, that the user might be about to click on.

If the tooltip display mechanism works properly, the user should only need the tooltip once. After reading and comprehending it, any forced redisplay would only have nuisance value -- providing the user is in control of when the tooltip disappears. Redisplay of the tooltip should only be required if the user makes it pop down before fully comprehending it. So forcing the tooltip to redisplay, even if it isn't obscuring the active element, would be undesirable in most instances as it would still obscure something else.

Point taken about the object being larger than the viewing area. However, I believe the browser should be designed to operate smoothly for those that have learned to use its capabilities, making it efficient to use once learned. If, by using it incorrectly in the first few instances it causes some inconvenience to the user, that would suitably encourage the user to discover how this simple mechanism works: hold the mouse still, read and fully comprehend the tooltip, then move the mouse.

The underlying principle is this: put the browsing experience in the hands of the user, in the simplest possible way, instead of having the browser make arbitrary decisions on his or her behalf -- decisions that the user might not want.

I agree entirely with Dave Jakeman and comments 33 and 35.

His solution seems very natural to me, and it avoids preference bloat. Also, if the proposed tooltip delay preference doesn't make it into mainstream preferences, and is only accessible through "about:config", it marginalizes the feature, leaving most people with the current, awkward behaviour.

Making it behave intuitively regardless of preferences brings the solution to the masses--not just those who know how to tweak the config.

Created attachment 345861
Reworked patch doing away with auto-hide timer and making tooltips disappear on mouse move

As per the suggestions in the comments above, specifically those by Dave Jakeman, this patch changes the tooltip behaviour as follows:

1. Tooltips appear after 500 milliseconds of hovering over an object without moving. (unmodified)
2. Tooltips disappear as soon as the mouse moves (as opposed to when the mouse leaves the node).
3. Tooltips only reappear if the mouse exits the node and reenters it (new behaviour).

Please can someone test it out to see if it works intuitively. I'm personally more in favour of it reappearing without having to exit the node, but comments above suggest that I am in the minority.

I would love to give John's latest patch a try, but don't know how. I browsed the ftp site mentioned in Comment #19, but wasn't sure where to look. Is that not the way to test? Any clues? I feel dumb asking about this, but couldn't find out how in Bugzilla help, or elsewhere...

John (comment 37): Your patch appears to have been generated versus CVS (that is, it is for Firefox 3.0.x). Could you please redo it versus mozilla-central (Firefox 3.1-to-be)? A patch like this is very unlikely to be included in a 3.0 update. Instructions for anonymous access to the mozilla-central repository is at https://developer.mozilla.org/en/Mozilla_Source_Code_(Mercurial)

Dave (comment 38): I've just sent John's patch to the test builder, look for installable images here: https://build.mozilla.org/tryserver-builds/?C=M;O=D They won't show up for an hour or two.

Builds with John's patch now available:

https://build.mozilla.org/tryserver-builds/2008-11-02_09:<email address hidden>/

Thanks guys. I've tried this out and it works as envisaged.

Whilst I believe the behaviour to be correct in principle, it's easy to nudge the mouse a single pixel whilst reading the tooltip, causing it to vanish prematurely. When I set my mouse to maximum sensitivity, by far the easiest way to read a lengthy tooltip is to position the mouse pointer and let go of the mouse until I've finished reading. This is easy and works reliably. The stop-read-move part comes naturally, but I'm wondering if the "let go of mouse" part will be obvious to some users. Anyone else tried it?

I could live with this as is, but here's another thought by way of improvement:

Would it be feasible to require some small range of mouse movement to pop down the tooltip, larger than a single pixel? Would that be hard to code?

I think this is almost there, but the pop-down mechanism would benefit from a slight tweak.

Created attachment 346080
Mercurial patch doing away with auto-hide timer and making tooltips disappear on mouse move with a small tolerance for cursor jitter

This is hopefully the final version of this patch. It is updated to include a slight tolerance (2 pixels) for small mouse movements while the tooltip is visible. This ensures that the tooltip doesn't inadvertently disappear. It is also generated using the mercurial repository.

Please check to see if it is usable and that it makes reading tooltips easier and more intuitive.

John, (Comment #42): I've set up my home PC to do Firefox builds and have built the "Minefield" version for testing. If you could post the full content of nsXULTooltipListener.cpp, I can test it this evening.

Dave (#43), you can apply the attached patch to your source tree using the following command:

patch -p1 < tooltip.patch

You must run the command in the root directory of the source tree.

Thanks again, John.

First impression: already much better. The slight tolerance on mouse movement is a big improvement.

After my previous experience with zero tolerance on movement, the first thing I wanted to do was loosen that tolerance up, so after playing with it for a while at 2 pixels, I increased kTooltipMouseMoveTolerance to see how high it could go within reason. I tried 5 at first, then 10. I found the value can be quite large and the pop-down mechanism still works well. In fact, it's more friendly that way. If, when it's set to 10, a movement of a few pixels takes the pointer outside the node boundary, the tooltip still vanishes as desired. So large values of kTooltipMouseMoveTolerance don't cause unwanted behaviour.

But what value should it be? I tried 10 because that was clearly too big. Something between 5 and 10 seemed appropriate. I set it to 7 and used it like that for a while. I liked 7. It felt about right.

So, more testing:

The HTML I used was a very demanding piece with small, single-character superscripted and subscripted links, all with medium-to-long tooltips. This piece absolutely needed tooltips to display properly.

I tried setting the Razer Copperhead to minimum sensitivity and that just got easier, so no problems there. Back to maximum sensitivity.

I tried setting my screen resolution to 640 x 480 and managed to screw up my Ubuntu desktop. But the tooltip behaviour didn't seem much affected by the lower res. Back to 2048 x 1536.

I tried different mice to the Copperhead:

 - a cheapo USB/optical that "misbehaves": it was fine, even with its misbehaviour;
 - a Microsoft USB/trackball: very easy and "letting go" was easy and came naturally;
 - an ancient Microsoft serial ball mouse: no problems at all;
 - a Wacom USB graphics tablet: took some practice;
 - a Wacom tablet mouse: fine (but had other issues).

Overall, the trackball was the easiest to use; the most difficult was the Wacom graphics tablet.

With the tablet, you have the choice of pressing the pen against the tablet slightly to hold the pointer still and inadvertently clicking something, or holding it just clear of the tablet and having the mouse pointer "tremble". This trembling makes the motion tolerance essential. The trembling can be so bad it delays the tooltip from popping up in the first place. Another oddity is that "letting go" isn't an option. If you lift the pen clear of the tablet, the mouse pointer jumps to a corner of the screen. I guess this is why Wacom supply a free mouse to use in conjunction with the tablet. In operation, the mouse is very nice, but with Ubuntu, the mouse pointer can't reach important parts of the screen -- such as the Firefox "Back" button. So I guess we don't have to worry about the Wacom just yet. With practice though, I was able to use the pen and tablet, but it's not what I'd choose for general mouse work anyway.

Second worst overall was my favourite -- the high-speed Copperhead at maximum sensitivity. That said, I can still control the tooltip behaviour easily with kTooltipMouseMoveTolerance set to 7. And the Copperhead has two buttons dedicated to changing sensitivity on-the-fly, ...

Created attachment 346420
Patch removing auto-hide timer so that tooltips hide on mousemove (with 7 pixel tolerance)

I've changed the mouse move tolerance to a 15x15 pixel window (specified as the "radius" of 7) as per Dave Jakeman's suggestion.

For the record, I've re-applied John's latest patch (Comment #46), rebuilt and re-tested using another mouse (an old, cheapo Compaq serial) and the tooltip display still works just fine. As far as I'm concerned, this latest patch fixes the problem we set out to solve.

Comment on attachment 346420
Patch removing auto-hide timer so that tooltips hide on mousemove (with 7 pixel tolerance)

> NS_IMETHODIMP
> nsXULTooltipListener::MouseOut(nsIDOMEvent* aMouseEvent)
> {
...
> mTooltipTimer->Cancel();
> mTooltipTimer = nsnull;
> return NS_OK;
>+ } else {
>+ HideTooltip();
> }

Won't this hide the tooltip on any mouseout event? If someone puts a tooltip on a toolbar for instance, a mouseout event will fire every time someone moves the mouse out of an element.

>+ // filter out false win32 MouseMove event
> if (mMouseScreenX == newMouseX && mMouseScreenY == newMouseY)
>+ return NS_OK;
>+
>+ // filter out minor movements due to crappy optical mice and shaky hands
>+ // to prevent tooltips from hiding prematurely.
>+ nsCOMPtr<nsIContent> currentTooltip = do_QueryReferent(mCurrentTooltip);
>+
>+ if ((currentTooltip) &&
>+ (abs(mMouseScreenX - newMouseX) <= kTooltipMouseMoveTolerance) &&
>+ (abs(mMouseScreenY - newMouseY) <= kTooltipMouseMoveTolerance))

I don't see any reason to do this. Also, it won't work if someone moves the mouse slowly.

>+ // set a flag so that the tooltip is only displayed once until the mouse
>+ // leaves the node
>+ mTooltipShown = PR_TRUE;

The tooltip may not actually be shown though, if, for example, a popupshowing event prevents it or it's in a hidden tab. Better to do this at the end of LaunchTooltip where a check is done for the popup being open.

> Won't this hide the tooltip on any mouseout event? If someone puts a tooltip on
> a toolbar for instance, a mouseout event will fire every time someone moves the
> mouse out of an element.

This is the same as the current tooltip behaviour, which I see as desirable. Try it out on "in-testsuite" above.

> I don't see any reason to do this. Also, it won't work if someone moves the
> mouse slowly.

See Comment #41 and Comment #45. Have you tried this? It does work if the mouse moves slowly.

Created attachment 349172
New patch incorporating review suggestions

(In reply to comment #48)
> (From update of attachment 346420 [details])
> > NS_IMETHODIMP
> > nsXULTooltipListener::MouseOut(nsIDOMEvent* aMouseEvent)
> > {
> ...
> > mTooltipTimer->Cancel();
> > mTooltipTimer = nsnull;
> > return NS_OK;
> >+ } else {
> >+ HideTooltip();
> > }
>
> Won't this hide the tooltip on any mouseout event? If someone puts a tooltip on
> a toolbar for instance, a mouseout event will fire every time someone moves the
> mouse out of an element.

I have reverted this section to the old code that checks if the mouse is leaving the target node. This seemed unnecessary to me since the event callback would only trigger if the mouseout event was for the target node.

> >+ // filter out false win32 MouseMove event
> > if (mMouseScreenX == newMouseX && mMouseScreenY == newMouseY)
> >+ return NS_OK;
> >+
> >+ // filter out minor movements due to crappy optical mice and shaky hands
> >+ // to prevent tooltips from hiding prematurely.
> >+ nsCOMPtr<nsIContent> currentTooltip = do_QueryReferent(mCurrentTooltip);
> >+
> >+ if ((currentTooltip) &&
> >+ (abs(mMouseScreenX - newMouseX) <= kTooltipMouseMoveTolerance) &&
> >+ (abs(mMouseScreenY - newMouseY) <= kTooltipMouseMoveTolerance))
>
> I don't see any reason to do this. Also, it won't work if someone moves the
> mouse slowly.

This code implements the exact behaviour that a few people in this bug discussion have requested. It changes the way tooltips behave, but it works well so I've left it there. I've tested it extensively and it works even if the mouse is moved slowly, since it compares the current mouse position to the position when the tooltip was shown.

> >+ // set a flag so that the tooltip is only displayed once until the mouse
> >+ // leaves the node
> >+ mTooltipShown = PR_TRUE;
>
> The tooltip may not actually be shown though, if, for example, a popupshowing
> event prevents it or it's in a hidden tab. Better to do this at the end of
> LaunchTooltip where a check is done for the popup being open.

Noted. I've moved this to LaunchTooltip.

jmorkel: since you're actually working on this and seem to have it more or less nailed, I'm reassigning it to you rather than myself; hope you don't mind.

Comment on attachment 349172
New patch incorporating review suggestions

This patch doesn't seem to work properly. Hovering over a button, say the Home button, shows a tooltip. Moving the mouse makes it disappear and then completely prevents any tooltip from appearing thereafter.

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

Created attachment 360518
Working patch addressing previous patch bug

There was an issue with the mTooltipShown flag not being reset when exiting a node so I have set it to be reset on MouseOut. I've tested it and it works as desired.

I've tried out John's latest patch with Minefield and it seems to work fine. I'm happy with it.

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

Comment on attachment 360518
Working patch addressing previous patch bug

>+ mTooltipShown = PR_FALSE; // reset flag so that tooltip
will display next time

This seems like it wouldn't be accurate if someone hides a tooltip via a script say, which wouldn't fire mouseout possibly.

Now that I think about it, does this flag just need to know if the popup is open or not? It seems like this could be done just by checking IsPopupOpen in the one case where it needs to know.

I think the approach in general looks right and the patch now works correctly. Going to ask for a ui-review as this changes two tooltip behaviours:

1. It makes tooltips only disappear when mouse exiting or mouse moving on an element, not after a 5 second delay.
2. It adds a 7 pixel move threshold so tooltips don't close within this.

Comment on attachment 360518
Working patch addressing previous patch bug

This seems to make the behavior closer to tooltips in chrome (and other desktop apps), which is overall a good thing. The UI is fine, but I should note that I didn't have a chance to read all of the above comments, and I can't comment on what if any minor implications this would have for Web developers and the existing functionality sites.

Comment on attachment 360518
Working patch addressing previous patch bug

OK, let's try it and see if it causes any problems.

Comment on attachment 360518
Working patch addressing previous patch bug

>+ // flag specifying if the tooltip has already been displayed
>+ PRBool mTooltipShown;
It took me some time to work out what this really means... what you're trying to say here is that you only ever show the tooltip once for any given element while the mouse is hovering over it. You could do with a better comment here, and maybe rename the flag to mRecentTooltip or something slightly more relevant.

There has been some discussion about the flag controlling what to do with the tooltip, started by me in comments #16 and #18, and more recently in comments #54, #57 and #60.

I like the suggestion in #57 about using IsPopupOpen instead of a separately maintained flag that duplicates (and possibly mis-duplicates) the effect of IsPopupOpen. Is it worth adopting IsPopupOpen (and stripping out mTooltipshown) to simplify things here?

[I say this without fully understanding what IsPopupOpen is, but assume it to be a routine that returns the display status of a given pop-up.]

Created attachment 370586
Patch with more meaningful comments and variable names

I've changed mTooltipShown to mTooltipShownOnce and added some extra comments in both the header and the main file. I also put a reference to this bug.

Comment on attachment 370586
Patch with more meaningful comments and variable names

Ah yes, that's much better.

Looks like this can finally be checked in.

http://hg.mozilla.org/mozilla-central/rev/5263468b1d60

John, any thoughts on Comments #57 and #61?

I backed this out because it turned the unit tests orange because content/tests/widgets/test_tooltip.xul and content/tests/widgets/test_tooltip_noautohide.xul were timing out. (Sometimes the timeout was only caught by the buildbot harness (which then killed the whole run), and sometimes the mochitest harness managed to catch it.)

http://hg.mozilla.org/mozilla-central/rev/54dda9955a7f
http://hg.mozilla.org/mozilla-central/rev/4c789475528b

So is this a problem with the patch or with the test harness? We're talking intentional functionality change here, so would the test failures be expected?

Or is this to do with that flag we were talking about?

I wouldn't say it's a problem with the test harness, but it may be a problem with the tests, since they were written to test different behaviour.

Created attachment 371077
Patch that doesn't break any unit tests

There seemed to be a problem with hiding a tooltip with a script that was causing content/tests/widgets/test_tooltip.xul to timeout. This patch fixes that.

I've moved where mTooltipShownOnce is set to true from LaunchTooltip() to just after HideTooltip() is called in MouseMove(). This causes the tooltip to display _once_ per entry into a node if a mousemove event causes the tooltip to hide. If the tooltip is hidden because of mousedown, mouseup, keydown or DOMMouseScroll events, or a script, then it will reappear if the mouse is moved within a node (without having to exit and reenter the node).

I hope this is clear and produces the desired behaviour.

I've tested John's latest patch with Minefield and it seems to work fine.

With the 5-second timer display model, I wasn't aware that pressing a Shift or Ctrl key made the tooltip pop down. With our modified tooltip behaviour, this feature is quite handy. However, it does produce an inconsistency: if one pops down the tooltip through mouse movement, it stays down; if one pops down the tooltip using the shift key, it can pop up again before mouseout.

I'm not sure whether this inconsistency should be considered a problem or desirable behaviour, as it gives the user additional control over the tooltip. This feature could also solve one of the problems previously mentioned (object larger than viewing area), so I suggest we stick with the behaviour of the current patch.

Comment on attachment 371077
Patch that doesn't break any unit tests

This seems OK, (event though I'd commented previously that this change wasn't as good ;)) but why was the test timing out?

http://hg.mozilla.org/mozilla-central/rev/07599e2b0941

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090412 Minefield/3.6a1pre
This patch has the side effect of not being able to reshow the tooltip. Previously if the tooltip disappeared you could move the mouse a bit and the tooltip would reappear, now it won't, is that expected/desired?

(In reply to comment #74)
> This patch has the side effect of not being able to reshow the tooltip.
> Previously if the tooltip disappeared you could move the mouse a bit and the
> tooltip would reappear, now it won't, is that expected/desired?

If you follow the discussion above, you'll see that this is the desired behaviour. The tooltip remains indefinitely visible so long as the mouse remains stationary on a node and only hides once the mouse moves more than the tolerance of 7 pixels horizontally or vertically. The tooltip will reappear if the mouse leaves the node and re-enters it.

I've just discovered a regression here... tree titletips don't reappear until you mouse out of the entire tree, whereas changing cells should suffice.

(In reply to comment #76)
> I've just discovered a regression here... tree titletips don't reappear until
> you mouse out of the entire tree, whereas changing cells should suffice.

Could you please provide a test case? I have a potential fix, but can't find anywhere to test it.

This is not fixed,https://addons.mozilla.org/en-US/firefox/addon/11233 can fix this problem

Thanks.

Comment on attachment 371077
Patch that doesn't break any unit tests

Black_Ps`, which version did you test with? The patch has currently only been checked into trunk (3.6-to-be), not 3.5-to-be or any earlier branch. There's maybe a case for putting it into 3.5, it doesn't look that invasive. I've flagged it for possible approval to that branch.

RESOLVED FIXED means "checked into trunk", even when (as now) that doesn't necessarily mean "will be in next major release." Sorry.

I have it installed on firefox 3.0.0.10 and it's working

Thanks,sorry i`m not that good like you people.

Keep up the good work.

Comment on attachment 371077
Patch that doesn't break any unit tests

I don't think this is a big enough issue to take in the RC, and touching tooltips (no matter how safe the patch looks or the fact that it doesn't break reftests) makes me a little nervous.

Let's let it bake for a bit longer and can reconsider if we hear a huge outcry.

This bug's priority relative to the set of other polish bugs is:
P3 - Polish issue that is in a secondary interface, occasionally encountered, or is not easily identifiable.

Tooltips are a secondary UI, and this bug is less identifiable since you would have to wait for 5 seconds to see it.

Ubuntu Bug:
https://bugs.launchpad.net/bugs/239462

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

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

Mozilla/5.0 (X11; Linux x86_64; rv:2.2a1pre) Gecko/20110331 Firefox/4.2a1pre SeaMonkey/2.2a1pre ID:20110331193613

Just tried the testcase in duplicate bug 410043 comment #0, and it is indeed fixed.

Considering that almost two years have passed without this bug being REOPENED, I feel confident that it is now VERIFIED even on platforms other than mine. If you see the bug again on a build whose useragent string ("Build ID" on the about: page) includes rv:1.9.2a1 or later, please open a new bug with keyword "regression" and a mention that bug 395668 has come unstuck.

It now times out after one second.

(In reply to local from comment #87)
> It now times out after one second.

I am not seeing this timeout on Firefox 85.0.1 in Fedora 33. Maybe you need to raise a new bug report with the details of your platform and version?

Terribly sorry, I was running unclutter, and didn't notice the quick timeout this caused until immediately after updating to 85.0.1. Everything is fine.