82953 - Tooltips should appear while moving the mouse too

Status: NEW

(Core :: XUL, enhancement)

Description

[James Green]

I just posted a bug on improving the tooltips we provide while hovering over the
Back/Forward button's history arrow.

This problem is irrelevant unless we actually show the tooltips while the mouse
is over the Back/Forward buttons.

Right now we wait for the mouse to stop, then show the tooltip. On moving again,
we erase the tooltip. Watching my mother work the back buttons, she constantly
has the mouse moving slowly around the surface of the buttons wondering what to
do, thus she never gets to see the tooltips explaining the functionality of the
buttons.

Putting this into UI Design for lack of better ideas. The problem occurs on
Linux builds, and I'm guessing it's XP so marking all/all.

Comment 1

[James Green]

My bad, we apparently do keep the tooltips showing. The problem is that we wait
for the mouse to stop THEN show the tooltip. This should change this so that we
show the tooltip regardless of whether we are moving or stationary.

Summary is, however, correct.

Comment 2

[Alex Bishop]

The idea with tooltips is that a user mouses over to a button and then pause as
they try to figure out what it does. This pause is picked up and a tooltip
appears. The problem is solved and everyone's happy. Except your mother. ;-)

I had a look around Windows and its behaviour is identical to Mozilla (with the
exception that if you wait until a tooltip appears and then move to the next
button along its tooltip appears instantly). But I think it's not unreasonable
for people to move the mouse around and, as long as they keep it in the button's
trigger zone, I see no problem with the tooltip still appearing after a delay.

In short, I fully agree with you.

Comment 3

[Alex Bishop]

I think this belongs in XP Toolkit/Widgets so moving it there. I'm also marking
as an enhancement, since it's not really a bug (well, maybe it is, but every
program has it).

Comment 4

[timeless]

so what we want is to instantly show tooltips if we just showed a tooltip. And 
we'll stop showing them instantly when the user takes an action [clicking 
or using the keyboard].

Comment 5

[Alex Bishop]

Yes, but I mentioned that mainly in passing.

James's original request was that you shouldn't have to keep your mouse
completely still while waiting for a tooltip to appear.

These steps to reproduce should clarify things:

1. Move your mouse over a button, for example Reload.
2. Leave your mouse still and wait for the tooltip to appear.
3. Now take your mouse some place else.
4. Move you mouse back over the Reload button. Then slowly move it within the
button's 'trigger zone'.
5. Note that no tooltip appears until a second after you stop moving the mouse.

Expected Result: Tooltip appears after a second whether or not the mouse is moving.

Actual Result: Tooltip only appears after a second if the mouse is kept still.

Comment 6

[Peter Trudelle]

Technically, this is a defect.  The Windows HIG specifies "Display a tooltip
after the pointer...remains over the button for a short period of time".  It
says nothing about the pointer being motionless.  Mac help balloons work
similarly, once you turn them on.  However, we don't have time for this level of
polish in the current release cycle.  ->future

Comment 7

[Jesse Ruderman]

If the target area is large, how would the user make a tooltip disappear once
this bug is "fixed"?

Comment 8

[Alex Bishop]

Jesse: I'm not sure if this is a problem. At the moment I believe (I haven't got
access to a recent Mozilla build, so I can't be certain) that the tooltip stays
until the user moves off the button (i.e. once the tooltip has appeared you can
move the pointer within the 'trigger zone' without the tooltip disappearing).
This wouldn't be changed when this bug is fixed, and I don't believe there's
been any complaints about this behaviour (it's how Windows native apps behave).

Incidentally, I noticed that in Netscape 6.01 tooltips do appear even if the
pointer isn't stationary, so technically, this is a regression.

Comment 9

[Jesse Ruderman]

I vote against this bug.  I think this would get in my way a lot, because I
often keep my mouse over one "target area" for some time while I'm trying to hit
a target within that area or while I'm finishing reading text somewhere else. 
If a tooltip triggered while I was doing that, I'd have to move my mouse out of
the way and back to finish what I was doing.

Comment 10

[John Morrison]

May God have mercy on us all. The 212 bug spam-o-rama is Now!

Comment 11

[Ian Pottinger]

adding self to cc list

Comment 12

[Peter Trudelle]

Mass moving all of my open Nav/toolkit bugs to new owner.

Comment 13

[Vaclav Dvorak]

Would be nice to have. Note that keeping the mouse completely still while still
holding it may be nearly impossible for some people (handicapped, or just
inexperienced with mouse). This is also a big problem for new computer users
trying to double-click (the mouse also needs to be completely still between the
two clicks, but they usually move it a bit with the first click). Also, flakey
optical mice sometimes keep "vibrating" the pointer even when you don't even
touch them.

OTOH, perhaps there should be a limit on the "pixels per second" rate of
movement, so that when you just swipe over an area that just happens to be big
enough to trigger this, you're not annoyed by a tooltip popping up.

Also, how exactly do we determine when to dismiss the tooltip? Now, any movement
makes the tooltip disappear. When this bug/rfe is fixed/implemented, that
wouldn't make much sense.

Why does this depend on bug 45522? If anything, I think this should depend on an
_opposite_ bug, something like: "tooltips shouldn't disappear on small mouse
motion".

Comment 14

[Scott Tankard]

I agree that the tooltips should begin thier countdown to appearance when an element is _first entered_, and not when an element is entered and there is zero motion.

This bug should apply to tooltips in the content area as well as tooltips in the browser UI.

I register a vote for this bug :)

Jesse Ruderman, your worries are outside the scope of this bug as I see it: this referes to a _time-in_, meaning when to first display the tooltip, not a _time-out_, meaning when to hide the tooltip again.

Incidentally, I would like to see the timeout abolished as well, save in the case of zero movement (e.g. user releases mouse for reading a long section, tooltip may get in the way).

timeless, 

"so what we want is to instantly show tooltips if we just showed a tooltip. And 
we'll stop showing them instantly when the user takes an action [clicking 
or using the keyboard]."

I agree, however I this this is outside the scope of this bug as well. :/

Comment 15

[Wayne Mery (:wsmwk)]

see also Bug 204786

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.