250825 - Tiny empty tooltip appears seemingly random when loading a page.

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

Build ID: 2004-07-10-08, Seamonkey trunk on Windows XP, but this has been seen
by biesi and dbaron on Linux.

Summary: Tiny empty tooltip appears seemingly random when loading a page.

This is a new regression in today's 2004-07-10-08 build.

Steps to Reproduce:

1.  I'm not sure just yet, but loading pages (no user events are necessary)
seems to trigger this.

See screenshot.

Comment 1

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Screenshot showing tiny empty tooltip

Comment 2

[Stephen Donner [:stephend] Not actively reading bugmail]

<stephend> dbaron, so, more research shows me that it's something related to
TITLE attributes
<stephend> and also, that it is drawn in a straight line above the mouse pointer
<stephend> (at least on windows)
<stephend> (I mean title attributes)
<stephend> because composer is registered to edit HTML files?
<stephend> something isn't killing tooltips per-page.
<stephend> I'm loading other pages, and seeing previous tooltips bleeding over

Comment 3

[Brendan Eich [:brendan]]

Who was on the hook?  Pick likely perp and assign this bug to him or her; cc the
rest.

/be

Comment 4

[[e-mail]]

Fallout from bug 91312 perhaps?

Comment 5

[Stephen Donner [:stephend] Not actively reading bugmail]

My Spidey senses tell me bug 91312 is a likely culprit.

I've done:

cvs update -j1.30 -j1.29 mozilla/xpfe/browser/resources/content/browser.js

followed by a top-level make chrome in C:\moz_src\mozilla, and that cured both
of my ails.

cc:ing [e-mail] (author) and timeless (patch lander),
for now.

Comment 6

[Stephen Donner [:stephend] Not actively reading bugmail]

(assigning, rather, since I should follow Brendan's directive)

Comment 7

[Jason Bassford]

This bug always appears for me whenever I go to (domain.com):5800 to look at a
VNC server.

Comment 8

[Ilya Konstantinov]

Unfortunatelly I'm not talking currently from a place where I can debug this, but nor can I see how my patch could ever cause this regression.

Could you please try adding my patch again, but then removing this line:
tipNode.style.direction = direction;
?
I wonder if it fixes your problem. If so, it's still some kind of a bug with the TOOLTIP XUL element, but at least we could narrow it down.

Comment 9

[Stephen Donner [:stephend] Not actively reading bugmail]

Commenting out the assignment to direction seems to fix it also (leaving intact
the other two lines 1) +  var direction = "inherit"; 2) + 
tipNode.style.direction = direction;)

Index: browser/resources/content/browser.js
===================================================================
RCS file: /cvsroot/mozilla/xpfe/browser/resources/content/browser.js,v
retrieving revision 1.30
diff -u -w -r1.30 browser.js
--- browser/resources/content/browser.js        10 Jul 2004 00:56:41 -00001.30
+++ browser/resources/content/browser.js        11 Jul 2004 18:25:25 -0000
@@ -360,7 +360,7 @@
     if (tipElement.nodeType == Node.ELEMENT_NODE) {
       titleText = tipElement.getAttribute("title");
       XLinkTitleText = tipElement.getAttributeNS(XLinkNS, "title");
-      direction = tipElement.ownerDocument.defaultView.getComputedStyle(tipElem
ent, "").getPropertyValue("direction");
+      // direction = tipElement.ownerDocument.defaultView.getComputedStyle(tipE
lement, "").getPropertyValue("direction");
     }
     tipElement = tipElement.parentNode;
   }

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I backed bug 91312 out of the trunk so that we can progress towards shipping 1.8a2.

Comment 11

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED using 2004-07-13-08 on Windows XP.

Comment 12

[Bill Mason]

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