45530 - Tooltips need to time out

Status: RESOLVED FIXED

(Core :: XUL, enhancement, P3)

Description

[R.K.Aa.]

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

[Blake Ross]

sending to xp menus...this would be kinda cool

Comment 2

[Blake Ross]

oops..reassign

Comment 3

[Peter Trudelle]

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.

Comment 4

[John Dobbins]

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.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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 
Shift).

Comment 6

[Matthew T (active 1999-2002)]

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.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Ben reverted his patch (thanks!) so there should be far fewer tooltips showing 
up now.

Comment 8

[Peter Trudelle]

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
them.

Comment 9

[:deanis74]

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

Comment 10

[Luis Villa]

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

[scottputterman]

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

Comment 12

[Mike Pinkerton (not reading bugmail)]

wookin pa nub in all da wong paces.

Comment 13

[Mike Pinkerton (not reading bugmail)]

fixed. r=danm/a=hyatt.