Brian Reporter
	Description • 17 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b1) Gecko/2007110904 Firefox/3.0b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b1) Gecko/2007110904 Firefox/3.0b1

When I was view a bug, I hovered over a drop down menu and a tooltip came up with some info.  After I was done reading, I opened a new tab and when my mouse was just hovering over the white background on a blank page, the same tooltip came up again.  Even as I enter this bug, I can hover over anything and it comes up, and it always shows the same tooltip from the bug I was reading.

Reproducible: Always

Steps to Reproduce:
1. Hover over something on a web page.
2. Then open a new tab, or go to a different website and let the mouse pause somewhere.
3. See the wrong tooltip.
Actual Results:  
I got the wrong tooltip, and sometimes when a tooltip wasnt supose to come up.

Expected Results:  
No tooltip or an updated tooltip.

about:buildconfig

Build platform
target
i686-pc-mingw32

Build tools
Compiler 	Version 	Compiler flags
cl 	14.00.50727 	-TC -nologo -W3 -Gy -Fd$(PDBFILE)
cl 	14.00.50727 	-GR- -TP -nologo -Zc:wchar_t- -W3 -Gy -Fd$(PDBFILE)

Configure arguments
--enable-application=browser --enable-update-channel=beta --enable-optimize --disable-debug --disable-tests --enable-update-packaging --enable-official-branding

	u218732
	Comment 3 • 17 years ago

When you roll over a link appropriate tooltip information appears however when you roll off the link tooltip information is retained and displays where no tooltip information is required, i.e. over text, blank backgrounds, or if a user rolls over a new link the tooltip information from the last link rolled over appears.

	u218732
	Comment 4 • 17 years ago

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007120605 Minefield/3.0b2pre

	Ivica Letunic
	Comment 5 • 17 years ago

Mac OS X Firefox 3 beta5

	Jørn Støylen
	Comment 6 • 16 years ago

Seeing this in Mac OS X Firefox 3 beta 5, both on iBook G4 and Intel Mac Pro.

Also, if no tooltip has been shown yet in current session, a tiny empty tooltip will show.

	Rob Michniewicz
	Comment 7 • 16 years ago

Same as above, last tooltip appears when the mouse is idle.  If no tooltip was yet displayed, displays a blank tooltip, otherwise displays the last displayed tooltip.

Linux Firefox 3 beta 5.

	Ivica Letunic
	Comment 8 • 16 years ago

Still there in RC2. However, I managed to make it go away by disabling one of the toolbar extensions I'm using (self-written, you can get it at http://itol.embl.de/help/toolbar.shtml).

Anyone has any ideas what in the extension could be causing this?   

	Bleizig
	Comment 9 • 16 years ago

I am also experiencing the same problem and I have an error in the console log each time it happens.

"t.replace is not a function"
 
The line that has issues is the following line
     t = t.replace(/[\r\t]/g, ' ');

In the method function FillInHTMLTooltip(tipElement)

in chrome/browser.jar!/content/browser/browser.js

	Bleizig
	Comment 10 • 16 years ago

I did some debug and here is what I found:

If have the following lines in an extension:

function toto(variable) {
}
Object.prototype.toto = toto;

And place some debug output printing "t" right before the line " t = t.replace(/[\r\t]/g, ' ');
"

When I mouse over an element with tooltip, "t" contains the content of the tooltip. When I leave my mouse idle anywhere where there are no tooltips (ie. in order to trigger the "t.replace is not a function" bug, the content of t is:

"function toto(variable) {
}"

I'm still investigating but anyone has an idea, I'd love to hear it.

	Dan Willett
	Comment 11 • 16 years ago

I'm experiencing this problem on all machines that I have installed FF 3.x on.  It is really annoying.  The last tooltip shows wherever you are at. And if you have the Google Toolbar installed, after you visit a form that can be autofilled, the google message shows on all tooltips after that.

The problem appears to be that the tooltip is not cleared after use.

Firefox 2.x does not have this problem.  It is a new bug introduced in Firefox 3.x

	damionfury
	Comment 12 • 16 years ago

By hovering over each object in varying order, you can see the bug at work.

	damionfury
	Comment 13 • 16 years ago

After some testing, I've found these things out:
1) The bug will only manifest in the main window of the Firefox process, not subsequent windows such as those created by popups or the File>>New Window command.  In these windows, Firefox operates normally, creating a workaround for the bug.  Open Firefox, open a New Window(Ctrl+N), then close the first window.

2) Firefox will attempt to render the tooltip whenever the mouse stops moving, regardless of whether the object it hovers over should have one.

3) The tooltip will be rendered without text until the first time the user hovers the mouse over an HTML object with a TITLE attribute,  (i.e. a small, empty box only a few pixels in height and width).

4) When the mouse hovers over an object with a TITLE attribute defined, the text from that TITLE will be displayed.

5) The TITLE text from that object will be displayed anytime the tooltip is rendered (see Note 2), until the mouse hovers over a different object with a defined TITLE attribute.  At that time, the tooltip text will be updated to reflect the new TITLE and the process will continue.

6) If the TITLE attribute is present, but the value is nothing (i.e. title=""), the tooltip will not be updated.


In short, the variable that stores the tooltip text is global, is initially empty (duh), and is changed only when hovering over an object with a nonzero-length TITLE attribute.  This would not be a problem if Firefox were correctly detecting when to render the tooltip, therefore the bug lies somewhere in that code.  Curiously, it is apparent that the problem code is only used by the window created when the Firefox process is launched, and not but subsequent windows within the same process.

	Gleb M. Borisov
	Comment 14 • 16 years ago

I have fixed this bug in my extension by adding check for t.replace (just overrided FillInHTMLTooltip). It's not a true fix, but solves problem for me.

	Kevin Brosnan
	Comment 15 • 16 years ago

works for me - Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6

No extensions installed, cannot reproduce using the steps in comment 0. Please someone who sees this issue try http://support.mozilla.com/kb/Basic+Troubleshooting and http://support.mozilla.com/en-US/kb/Troubleshooting+extensions+and+themes#If_you_have_a_large_number_of_extensions

	Fedge
	Comment 16 • 16 years ago

This is not an extension issue. It is a bug in firefox.

In the tooltip code, in browser.js there is a section where a variable t is tested against /\S+/ but it should be tested with typeof t === 'string' as well. Then the tooltips work properly.

Every time Firefox upgrades I have to fix this again. I don't know how to submit a patch or I would :(

	Bob Davies
	Comment 17 • 16 years ago

I found the same issue on 3.0.6 with an extension I am writing once I had included the 'prototype' framework. (http://www.prototypejs.org/)

I also had a similar issue a few weeks back when including the (http://json.org/) json2.js codefile in a webpage.

I'd assume these files both override or clear the .replace prototype being called by browser.js (which I assume is globally implemented). And since it's throwing an exception whatever code should be updating the tooltip var isn't executing.

My js aint very good, in another language i'd implement the .replace used by browser.js in protected scope, then any external files loaded around it wouldn't affect it's availability. Though I've no idea if this is possible in javascript?
Any ideas?

	u339468
	Comment 18 • 16 years ago

(In reply to comment #16)
> This is not an extension issue. It is a bug in firefox.
> 
> In the tooltip code, in browser.js there is a section where a variable t is
> tested against /\S+/ but it should be tested with typeof t === 'string' as
> well. Then the tooltips work properly.

I can confirm that this change has fixed this annoying bug. Thanks a lot.

	chris
	Comment 19 • 15 years ago

This issue also occurs when the MooTools framework is included within the Add-on.  However, MooTools uses the replace function in it's implementation therefore it still exists.  Why it should be unavailable in browser.js is a mystery to me.

	Avindra Goolcharan
	Comment 20 • 15 years ago

I can both confirm this bug still exists, and the the browser.js patch works fine.

https://bug404124.bugzilla.mozilla.org/attachment.cgi?id=361292

This is my User-Agent:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

	Gleb M. Borisov
	Comment 21 • 15 years ago

Fixing bug for me and my extension.

	Dão Gottwald [:dao]
	Comment 22 • 15 years ago

Comment on attachment 397269 [details] [diff] [review]
Checking for typeof t

>   for each (var t in [titleText, XLinkTitleText]) {
>-    if (t && /\S/.test(t)) {
>+    // XXX Bug 404124: check for type of t.
>+    if (t && typeof t == "string" && /\S/.test(t)) {

Why would t be anything other than a string?

Was somebody able to reproduce this without an extension?

	Gleb M. Borisov
	Comment 23 • 15 years ago

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2
All extensions switched off. Reproduced. Also reproduced on build from mozilla-central branch.

typeof XLinkTitleText == 'object' when I move mouse under page first time. After that — 'string'. Trying to debug this now.

	Gleb M. Borisov
	Comment 24 • 15 years ago

Forgot to revert my changes.

Reproduced only when prototype-mechnism used with String (eg. String.prototype.startsWith = function(s){...}). In all other cases — can't reproduce.

I think this bug might be closed as "Can't reproduce".

Thank for attention, and sorry for disturb.

	u339468
	Comment 25 • 15 years ago

This was probably caused because by extensions which modified the prototype property of builtin Objects. The Javascript ccode in Firefox incorrectly used "for each" to iterate over arrays in "FillInHTMLToolTip". Now that the Bug 524661 is fixed, this bug is probably resolved.