tooltiptext fails on XUL button in HTML page

RESOLVED FIXED in mozilla29

Status

()

RESOLVED FIXED
13 years ago
5 years ago

People

(Reporter: smolens, Assigned: mkmelin)

Tracking

({testcase})

Trunk
mozilla29
testcase
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 3 obsolete attachments)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060124 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060124 Firefox/1.5.0.1

The tooltiptext attribute on an XUL button created in an HTML document by document.createElementNS fails.  The tooltip doesn't appear.  Behaves the same when loaded in chrome.


Reproducible: Always

Steps to Reproduce:
1. Load test case.
2. Hover cursor over button.

Actual Results:  
No tooltip appears.

Expected Results:  
A tooltip should appear.
(Reporter)

Comment 1

13 years ago
Created attachment 216323 [details]
testcase
Created attachment 216391 [details]
testcase

It also happens with non-dynamic xul buttons (you had a regular html document, not an xhtml document), which normally prevents you from entering elements from other namespaces, unless you use document.createElementNS, which you did.

The problem is that this only works in xul documents, see:
http://lxr.mozilla.org/seamonkey/source/layout/xul/base/src/nsDocElementBoxFrame.cpp#127
Here the anonymous tooltip is created that is used for tooltips in xul elements with tooltiptext attributes. But it is only created for xul documents, as I said.
Attachment #216323 - Attachment is obsolete: true
Assignee: nobody → jag
Status: UNCONFIRMED → NEW
Component: General → XP Toolkit/Widgets
Ever confirmed: true
Keywords: testcase
OS: Linux → All
Product: Firefox → Core
QA Contact: general → jrgmorrison
Version: unspecified → Trunk
Created attachment 216394 [details] [diff] [review]
patch

This makes it work. I would probably also need to patch titletip attributes.
But I'm really not sure if this is the right way to do this.
It doesn't work for cases where html documents are viewed outside of the browser, but in that case tooltip for html elements also don't work.
Assignee: jag → nobody
I can still see this in 3.6.2 at least. Any chance of moving forward on this? Although the patch has bitrotten, the proposed fix seems simple enough to be applied to the current implementation of FillInHTMLTooltip AFAICT. Any thoughts?

Comment 5

9 years ago
Supporting the previous comment!
The patch needs to be updated, tests have to be written, etc, to have a chance of getting it into the tree.

Comment 7

9 years ago
This issue affects addons such as GMail Conversation View:
https://addons.mozilla.org/en-US/thunderbird/addon/54035
(Assignee)

Comment 8

5 years ago
Ok, so Thunderbird included a similar patch like the one above in bug 561854.

Now with bug 480356 fixed I'm looking to moving away from FillInHTMLTooltip for Thunderbird, which will also give us HTML5 form element validation and such.

This issue is kind of blocking me. If there is agreement about the suggested behavior?

In the thunderbird code we also had a test that makes xlink:title be the preferred title if also a plain title element is present. That's not the case with the current toolkit implementation. Is that wrong or preferred behavior?
QA Contact: jrgmorrison
Hardware: x86 → All
(Assignee)

Comment 10

5 years ago
Created attachment 8347719 [details] [diff] [review]
bug331772_tooltiptext_in_html_page.patch
Assignee: nobody → mkmelin+mozilla
Attachment #216394 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #8347719 - Flags: review?(enndeakin)

Comment 11

5 years ago
Comment on attachment 8347719 [details] [diff] [review]
bug331772_tooltiptext_in_html_page.patch

>-          while ((titleText == null) && (XLinkTitleText == null) &&
>-                 (SVGTitleText == null) && tipElement) {
>-            if (tipElement.nodeType == Node.ELEMENT_NODE &&
>-                tipElement.namespaceURI != XULNS) {
>-              titleText = tipElement.getAttribute("title");
>+          while (tipElement && !titleText && !XLinkTitleText && !SVGTitleText &&
>+                 !XULtooltiptextText) {

Comparing to null is done intentionally so that title="" can be used to undefine a title on a child element. So please use the original form. You might want to add a comment to that effect.
(Assignee)

Updated

5 years ago
Summary: tooltiptext fails on XUL button dynamically created in HTML page → tooltiptext fails on XUL button HTML page
(Assignee)

Comment 12

5 years ago
Created attachment 8349616 [details] [diff] [review]
bug331772_tooltiptext_in_html_page.patch

Comparing to null
Attachment #8347719 - Attachment is obsolete: true
Attachment #8347719 - Flags: review?(enndeakin)
Attachment #8349616 - Flags: review?(enndeakin)

Updated

5 years ago
Attachment #8349616 - Flags: review?(enndeakin) → review+
(Assignee)

Updated

5 years ago
Keywords: checkin-needed
(Assignee)

Updated

5 years ago
Summary: tooltiptext fails on XUL button HTML page → tooltiptext fails on XUL button in HTML page
https://hg.mozilla.org/integration/fx-team/rev/b44543dfeec6
Flags: in-testsuite+
Keywords: checkin-needed
Whiteboard: [fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/b44543dfeec6
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → mozilla29
You need to log in before you can comment on or make changes to this bug.