Tooltips need to time out

RESOLVED FIXED in mozilla0.9



18 years ago
10 years ago


(Reporter: R.K.Aa., Assigned: Mike Pinkerton (not reading bugmail))


(Blocks: 1 bug)


Firefox Tracking Flags

(Not tracked)




18 years ago
While cursor is over html elements or widgets, tooltips do not go away.
If over large elements, like TABLE with SUMMARY tag set, user has no way to "get
away" from the element, so it will display continously, covering text on the
page itself.

NC has a timeout on all tooltips, and one has to move out of the element and
back, to trigger that tooltip to display again.
This should also be the desireable behaviour in Mozilla.

There is no reason to persistantly display the information in a tooltip, it is
usually brief and user "gets the message" the first time it displays. Tooltips
that "won't go away" to some degree ruins the user experience.

Comment 1

18 years ago
sending to xp menus...this would be kinda cool
Component: XP Apps: GUI Features → XP Toolkit/Widgets: Menus

Comment 2

18 years ago
Assignee: ben → pinkerton
QA Contact: sairuh → jrgm

Comment 3

18 years ago
Windows native tooltips have a timeout, but it is not explained in their
interface guidelines, and we did not have any on Mac or Linux, so I don't agree
that it is expected or even necessarily beneficial. Also, the arbitrarily short
timeout on Windows may not be sufficient for our tabletip. In any case, NS
feature development for this release is closed, moving to future.
Target Milestone: --- → Future

Comment 4

18 years ago
Tooltips are a major irratiation in recent builds. If this is left as future, 
then hopefully bug 45522 (pref to turn off tooltips) will be implemented soon. 
No tooltips is preferable to little pop-ups blocking out the site I'm trying to 
view. This Isn't a feature it's a bug.
Recomend this be moved out of future milestone and since this behavior doesn't 
occur in NC 4.x 4xp keyword should be added. Adding Mitchell to CC.
The reason that tooltips are annoying is because Ben, without consulting anyone, 
checked in a patch that made tooltips pop up over all links. That patch needs to 
be removed.

The situation that this bug describes --- TABLE SUMMARY attributes and TITLE 
attributes covering large areas of a page --- is actually quite rare in my 
experience (and I've been browsing for several weeks with the tooltips on). I 
think that once we revert to the original, spec'ed behavior, most of the 
aggravation will go away.

This bug still deserves some attention at some point. I personally don't think 
timeouts are a complete solution, because if the tooltip is unwanted, we want 
the user to be able to get rid of it as soon as possible. Perhaps the tooltip 
should disappear after a timeout, OR if the user moves the mouse a certain 
distance, OR if they press any key (including an "effectless" key like Ctrl or 

Comment 6

18 years ago
People here are attacking the symptom (tooltips lasting too long) instead of the 
problem (useless tooltips showing in the first place).

Tooltips shouldn't have a timeout. Unlike in 4.x, we're using them to show 
content of arbitrary length (it could be very long, in the case of some TITLE 
attributes). So if we have a timeout, the tooltip might easily disappear before 
the user has read its contents, and that would be Bad.


18 years ago
Blocks: 45522
Ben reverted his patch (thanks!) so there should be far fewer tooltips showing 
up now.

Comment 8

18 years ago
We have in the past distinguished those that show expanded content by calling
them tabletips.  If we were to have a timeout, it should certainly not apply to

Comment 9

18 years ago
Matt, tooltips should have a timeout on chrome elements such as buttons, at 
least on Windows.  That is the standard behavior.

Comment 10

18 years ago
I've sort of spoken my mind on this subject over at bug 50052, but I think that
this is not a matter of "enhancement"- tooltips that don't go away interfere
with the operation of other programs on my system, not just mozilla. Is there
any way (short of fixing it myself, which I am eminently unqualified to do) that
this can be changed?

Comment 11

18 years ago
*** Bug 50052 has been marked as a duplicate of this bug. ***

Comment 12

18 years ago
wookin pa nub in all da wong paces.
Target Milestone: Future → mozilla0.9

Comment 13

18 years ago
fixed. r=danm/a=hyatt.
Last Resolved: 18 years ago
Resolution: --- → FIXED


10 years ago
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.