Closed Bug 250825 Opened 19 years ago Closed 19 years ago

Tiny empty tooltip appears seemingly random when loading a page.

Categories

(SeaMonkey :: UI Design, defect)

x86
All
defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED

People

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

References

Details

(Keywords: regression)

Attachments

(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
rest.

/be
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 mozilla-bugzilla@future.shiny.co.il (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 (domain.com):5800 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:
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.
Status: NEW → ASSIGNED
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;
   }
Flags: blocking1.8a2+
I backed bug 91312 out of the trunk so that we can progress towards shipping 1.8a2.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Verified FIXED using 2004-07-13-08 on Windows XP.
Status: RESOLVED → VERIFIED
*** 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.