Closed Bug 250825 Opened 20 years ago Closed 20 years ago

Tiny empty tooltip appears seemingly random when loading a page.


(SeaMonkey :: UI Design, defect)

Not set


(Not tracked)



(Reporter: stephend, Assigned: ilya.konstantinov+future)



(Keywords: regression)


(1 file)

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.
<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
Who was on the hook?  Pick likely perp and assign this bug to him or her; cc the

Fallout from bug 91312 perhaps?
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 (author) and timeless (patch lander),
for now.
(assigning, rather, since I should follow Brendan's directive)
Assignee: nobody → mozilla-bugzilla
This bug always appears for me whenever I go to ( to look at a
VNC server.
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: = 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.
Commenting out the assignment to direction seems to fix it also (leaving intact
the other two lines 1) +  var direction = "inherit"; 2) + = 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;
Flags: blocking1.8a2+
I backed bug 91312 out of the trunk so that we can progress towards shipping 1.8a2.
Closed: 20 years ago
Resolution: --- → FIXED
Verified FIXED using 2004-07-13-08 on Windows XP.
*** Bug 251461 has been marked as a duplicate of this bug. ***
Component: XP Miscellany → XP Apps: GUI Features
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.