Title tooltips do not go away on mouse out

RESOLVED FIXED in mozilla1.3beta

Status

()

Core
XUL
P2
major
RESOLVED FIXED
16 years ago
16 years ago

People

(Reporter: José Jeria, Assigned: John Keiser (jkeiser))

Tracking

({regression})

Trunk
mozilla1.3beta
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20021217
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20021217

Since today the tooltips are not working correctly. They dont disappear when
mouse leaves the element with the title. 

The title stays for several seconds and  you have to wait for it to disappear
before hovering a new element which has a title.

Reproducible: Always

Steps to Reproduce:
1. See testcase
(Reporter)

Comment 1

16 years ago
Created attachment 109631 [details]
Testcase
(Reporter)

Updated

16 years ago
Keywords: regression

Comment 2

16 years ago
A "quick" workaround (rather than waiting for the tooltip to timeout) is to
click elsewhere in the document.
(Assignee)

Comment 3

16 years ago
This is me, a direct regression of bug 103055.  What's happening is the
XULTooltipListener is setting the "tooltip node" to the textnode on mousemove,
and when mouseout comes in it comes in as the elemnt node, and they compare !=.
 There are two fixes for this (aside from regressing bug 103055):

(a) don't fire mousemove at textnodes anymore (this is probably going to happen
anyway)
(b) have XULTooltipListener set the "tooltip node" as the node that actually
contains the tooltip, and only unset it when you exit *that* node.  This would
eliminate flicker and such when you have <a><b><c>text</c></b></a> and the
tooltip itself is on <a>.  There are potential problems with this; for example,
if there were a sibling of <c> that had a tooltip itself maybe you want to show
that tooltip instead of <a>.  That could be solved by *checking* if you need to
change the tooltip on mouse over or mouse move.  I think this should be done
whether (a) is done or not.

There is another tooltip listener in our code, in nsDocShellTreeOwner; I wonder
why they are not combined.

The Movie opens tonight.  I cannot do this, therefore, until tomorrow.
Assignee: jaggernaut → jkeiser
Depends on: 103055
Priority: -- → P2
Target Milestone: --- → mozilla1.3beta
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED

Updated

16 years ago
OS: Windows 2000 → All
Hardware: PC → All
(Reporter)

Updated

16 years ago
Flags: blocking1.3b+

Comment 4

16 years ago
Just thought I would confirm that this is happening on Mac OS X build 2002122003.

Comment 5

16 years ago
jose.jeria@razorfish.de, don't set flags if you don't know how to use them.
Flags: blocking1.3b+
(Reporter)

Comment 6

16 years ago
Sorry, I was suppose to set it as "?", though that is also pointless since this
already is targeted to that milestone. Pointless, sorry again...
(Assignee)

Updated

16 years ago
Depends on: 185889

Comment 7

16 years ago
*** Bug 186885 has been marked as a duplicate of this bug. ***

Comment 8

16 years ago
To avoid dupes, perhaps the summary should include WHAT is broken in the tooltip
functionality?
(Assignee)

Updated

16 years ago
Summary: Tooltip functionality broken → Tooltips do not go away on mouse out

Updated

16 years ago
Flags: blocking1.3b?

Comment 9

16 years ago
If someone's going to check tooltips code, see also bug 185650

Comment 10

16 years ago
This bug is making it very annoying to use bugzilla..

Comment 11

16 years ago
Yup very annoying. I'm using 2003010508 on Windows XP and this bug is still here.

Comment 12

16 years ago
John, are you going to be able to get to this in time for 1.3beta (about 2 weeks
out)? It's a highly visible regression and we really shouldn't ship it in 1.3
Flags: blocking1.3b? → blocking1.3b+
(Assignee)

Comment 13

16 years ago
Yes.  I have a patch ready for the blocking bug (I still need to fix selection),
but even if that doesn't work out there is a somewhat lesser fix I can make.

Comment 14

16 years ago
*** Bug 188894 has been marked as a duplicate of this bug. ***

Comment 15

16 years ago
confirm.  12-27 phoenix, winme.

Comment 16

16 years ago
*** Bug 189054 has been marked as a duplicate of this bug. ***

Comment 17

16 years ago
I have changed the Summary, to include the word "title".
Summary: Tooltips do not go away on mouse out → Title tooltips do not go away on mouse out

Comment 18

16 years ago
*** Bug 188511 has been marked as a duplicate of this bug. ***
This has also made it possible to reproduce, in the GTK port, the complete UI
freezing described in bug 155018.  See bug 155018 comment 27.
(Assignee)

Comment 20

16 years ago
Fixed with bug 185889.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Updated

16 years ago
Keywords: nsbeta1+

Comment 21

16 years ago
Not quite fixed. Mouse over a bookmark on personal toolbar till tooltip appears.
When it appears, click on another application -or even mailnews titlebar. The
browser tooltip will remain visible.

Now minimize mozilla. The tooltip is still visible. Click on the tooltip for
fun. Then un-minimize mozilla and try to exit it. No can do.

In addition: After this fix was checked in i started seeing bug 184363.

Comment 22

16 years ago
I also see similar problems with the navigation toolbar, the site navigation
bar, tabs ("Open a new tab" and the titles for each tab), the "close sidebar"
button and the search results from the sidebar. They are often reproducible (and
always for the "Open a new tab" one).

If this is the same bug, it should be reopened.

Comment 23

16 years ago
I'm using build 2003012804 on Windows XP and have also the same problems with
popups not going away. After you go over parts of Mozilla status bar and then
move mouse out of Mozilla window the tootips stay. They stay even if you for
example mouse over some item in Windows taskbar that shows it's own tooltip.
(Assignee)

Comment 24

16 years ago
Yeah, the regression is almost certainly bug 190767 from the problem
description.  Hopefully we'll get that checked in today.
Status: RESOLVED → REOPENED
Depends on: 190767
Resolution: FIXED → ---

Updated

16 years ago
Flags: blocking1.3b+
(Assignee)

Comment 25

16 years ago
bug 90767 was checked in tonight.  Please retest in tomorrow's builds.

Comment 26

16 years ago
> the regression is almost certainly bug 190767

s/regression/fix/

this is working for me now with current CVS
(Assignee)

Comment 27

16 years ago
Thought so.  Thanks.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 28

16 years ago
I did a checkout at Sat Feb  1 18:40:48 2003 (UTC) and compiled Mozilla, but I
can still see the bug with the "Open a new tab" button. So, this bug should be
reopened. No problem with the other buttons, however.

Comment 29

16 years ago
fixed in general, including status bar now, but as Vincent (no relation!) says,
this is still happening with the new tab button (using 2003020208/win2k).

reopening. if the new tab would be better as a new bug (or is a different
issue), feel free to re-resolve and I'll file a new bug or whatever. thanks.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 30

16 years ago
I've filed bug 191651 for the new tab button issue (at jkeiser's request), so
this can stay marked as fixed.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 31

16 years ago
This bug hasn't been fixed in all cases. When one follows a link that contains
something that has a title, the tooltip incorrectly appears over the new page
and doesn't disappear immediately. Always reproducible.

Comment 32

16 years ago
Vincent: I guess the same applies as to the new tab thing - file a new bug for
this other residual issue.

Comment 33

16 years ago
Anyway the problem doesn't appear with the version I've just compiled.
You need to log in before you can comment on or make changes to this bug.