If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

tooltips should disappear on input/motion

NEW
Unassigned

Status

()

Core
XUL
P3
normal
17 years ago
8 years ago

People

(Reporter: tor, Unassigned)

Tracking

(Depends on: 2 bugs, Blocks: 2 bugs, {helpwanted, meta, polish})

Trunk
Future
helpwanted, meta, polish
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [UE2])

(Reporter)

Description

17 years ago
Recent changes to mozilla make it pop up a tooltip anytime you hover over 
a second or so.  While sometimes useful, it can also be annoying for some
people.  There should be a preference setting that turns off tooltips.

Comment 1

17 years ago
I don't know if that is exactly what the bug reporter meant, but:
Currently all links will give a "Location:..." tooltip.
Sometimes you will see the link location on the screen anyway. Even if not, the
location will appear in the status bar (JavaScript shouldn' be allowed to
override that BTW).
There will be seldom the need to display links as tooltips and it can often be
annoying.
So, when link tooltips are not turned off all the time, there should be an
option to do that.

Confirming & moving bug to XP/Toolkit Widgets, where most other tooltip bugs are
Status: UNCONFIRMED → NEW
Component: User Interface: Design Feedback → XP Toolkit/Widgets
Ever confirmed: true

Comment 2

17 years ago
And reassigning to pinkerton, just because he has lots of tooltip bugs :-).
Sorry if you were the wrong one.
Assignee: bdonohoe → pinkerton
QA Contact: mpt
Summary: Need tooltip preference

Comment 3

17 years ago
Correcting URL by removing it and placing it as summary instead.

This bug is somewhat related to the fix for bug 27828, and it seems that the
"Location:" and "URL will open in:" aren't quite the spec. Furthermore, tooltips
should not trigger over links without the TITLE tag set, but they currently do.
Summary: Need tooltip preference

Comment 4

17 years ago
I think we don't need another pref for this when tooltips on links are only 
triggered by a TITLE tag, which IMHO would be ok (There are already enough 
prefs).
Although I'm not the reporter of the bug, I take the freedom the change the 
summary from "Need tooltip preference" to: "Don't show tooltip over link without 
TITLE tag".
Summary: Need tooltip preference → Don't show tooltip over link without TITLE tag

Comment 5

17 years ago
From a UI perspective, I'd say that unless we change the tooltip behavior, 
we DO need a tooltip preference.  As it stands, tooltips will pop-up after 
the specified period of time, no matter what, not just when there's no 
activity.  Along the same lines, tooltips will pop up in the middle of an 
action like opening a menu (try the keyverbs menu) or typing a URL and 
display on top of the action, obscuring whatever's happening underneath.  
In such a state, there had better be a way to turn off tooltips.

Tooltips should pop-up only after the specified period of inactivity -- 
meaning the mouse stops moving, there are no clicks, there are no key 
presses.  If ANY of those activities occurs before the tooltip displays, the 
timer should be reset.  Once the tooltip displays, however, it's a 
semi-modal state; now moving the mouse around to different controls 
displays the tooltip immediately.  Clicking or pressing a key would exit the 
state and clear the tooltips, requiring the specified interval of inactivity to 
display again.  Likewise, the tooltip mode should timeout, hiding tooltips 
after a single tooltip has displayed for a specified period of time (5 or so 
seconds).  Also, tooltips should never appear for a control underneath the 
active item, e.g. for the button which called a menu while the menu is 
already open.  If this behavior is implemented correctly, tooltips won't get 
in the way, won't pop-up unexpectedly in the middle of an action, and won't 
obscure what you're working on.  In such case, a preference is less 
necessary and could be scrapped in favor of simplifying an already 
complex dialog.

So, that said, I recommend returning this bug to its original intention and 
not hijacking it for another smaller issue.  Tooltip behavior is irritating and 
we need to fix it or provide a way to turn it off (or both).
Summary: Don't show tooltip over link without TITLE tag → Improve tooltip behavior or add pref to turn them off.
We should improve tooltip behavior, not force the user to choose between broken 
tooltips or none at all.

Let's change this bug to "improve tooltip behavior".
QA Contact: jrgm

Comment 7

17 years ago
Righto, resummarizing.

Correction to Brendan's comment that `If ANY of those activities occurs before 
the tooltip displays, the timer should be reset':
`the timer should be reset' -->
`the timer should be turned off'.
The `timer should be reset' behavior is how 4.x for Mac OS works, and it's a bug. 
The timer should only be reset if the cursor leaves and then re-enters the 
tooltipped item.

So, a tooltip should disappear permanently (where `permanently' has the meaning 
given above) when:
* the cursor moves *at all*
* the tooltipped item moves beyond the cursor (e.g. an animated page element)
* the tooltipped item disappears (bug 45497)
* (possibly) a timeout occurs (bug 45530)
* any other input device (such as a keyboard) is used.

If someone wants to file separate bugs for those items listed above which don't 
already have their own bugs, this bug can turn into a tracker.
Depends on: 45497, 45530
Summary: Improve tooltip behavior or add pref to turn them off. → Improve tooltip behavior

Comment 8

17 years ago
Also when:
* mousedown occurs (bug 39078).
Depends on: 39078
won't get to this one any time soon.
Status: NEW → ASSIGNED
Keywords: polish
Target Milestone: --- → M22

Updated

17 years ago
Keywords: helpwanted

Comment 10

17 years ago
Adding meta keyword, since this appears to have morphed beyond a defect report.
I don't think we'll get to any of this, so if anyone feels strongly about it,
now would be the right time to submit patches that fix it.
Keywords: meta
so many bigger fish to fry
Target Milestone: M22 → Future

Updated

17 years ago
Whiteboard: [UE2]

Comment 12

17 years ago
[ue2] ??? adding ue2 keyword. Would someone please explain what [ue2] means?
Keywords: UE2

Comment 13

17 years ago
cc: (sorry about the spam)
Target Milestone: Future → mozilla0.9
Blocks: 43183
Depends on: 59917

Updated

17 years ago
Depends on: 61016
Target Milestone: mozilla0.9 → Future

Updated

17 years ago
Depends on: 82953

Updated

16 years ago
Keywords: UE2

Comment 14

16 years ago
The big about hiding the tooltip upon keyboard input is fixed by the work I'm
doing for bug 93839.  I'll just take this one from pinkerton, I'm sure he won't
mind.
Assignee: pinkerton → hewitt
Status: ASSIGNED → NEW

Updated

16 years ago
Status: NEW → ASSIGNED

Comment 15

15 years ago
re-summarizing to be less vague
Summary: Improve tooltip behavior → tooltips should disappear on input/motion

Updated

15 years ago
Blocks: 135962

Comment 16

14 years ago
Maybe as a simple fix, could we just set the onmouseover on a tooltip to nuke
the tooltip?  If you point at the top of your back button, wait for the tooltip
to arrive, then mouse down onto the tooltip, Mozilla starts flashing
uncontrolably (Windows 98 with Xmouse behaviour on).

In MS Word and IE the tooltip simply vanishes when your mouse moves over it. 
But the tooltip does NOT vanish if you move the mouse within the confines of the
host object (which is what seems to be proposed in this bug).
Assignee: hewitt → nobody
Status: ASSIGNED → NEW
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.