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

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

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.

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

jose.jeria@razorfish.de, don't set flags if you don't know how to use them.

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

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

To avoid dupes, perhaps the summary should include WHAT is broken in the tooltip functionality?

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

This bug is making it very annoying to use bugzilla..

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

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

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.

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

confirm. 12-27 phoenix, winme.

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

I have changed the Summary, to include the word "title".

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

Fixed with bug 185889.

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.

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.

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.

Yeah, the regression is almost certainly bug 190767 from the problem description. Hopefully we'll get that checked in today.

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

> the regression is almost certainly bug 190767 s/regression/fix/ this is working for me now with current CVS

Thought so. Thanks.

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.

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.

I've filed bug 191651 for the new tab button issue (at jkeiser's request), so this can stay marked as fixed.

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.

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

Anyway the problem doesn't appear with the version I've just compiled.