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.
sending to xp menus...this would be kinda cool
Component: XP Apps: GUI Features → XP Toolkit/Widgets: Menus
Assignee: ben → pinkerton
QA Contact: sairuh → jrgm
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
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 Shift).
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.
Ben reverted his patch (thanks!) so there should be far fewer tooltips showing up now.
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.
Matt, tooltips should have a timeout on chrome elements such as buttons, at least on Windows. That is the standard behavior.
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?
*** Bug 50052 has been marked as a duplicate of this bug. ***
wookin pa nub in all da wong paces.
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla0.9
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
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.