Closed Bug 639945 Opened 14 years ago Closed 13 years ago

html5-inlineSVG-title display tooltip

Categories

(Firefox :: General, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 7

People

(Reporter: jay, Assigned: longsonr)

References

Details

Attachments

(2 files, 3 obsolete files)

Attached file testcase (deleted) —
SVG <title> displays as tooltip in file served as SVG however SVG <title> inline in file served as HTML5 does not raise tooltip
The tooltip stuff is handled entirely by the UI, no?
Component: SVG → General
Product: Core → Firefox
QA Contact: general → general
Assignee: nobody → longsonr
Attached patch patch (obsolete) (deleted) — Splinter Review
Attachment #538769 - Flags: review?(dao)
Attachment #538769 - Flags: review?(bzbarsky)
Comment on attachment 538769 [details] [diff] [review] patch >+ tipElement.parentNode.nodeType != Node.ELEMENT_NODE)) { What's the point of this?
Attachment #538769 - Attachment is patch: true
If the document is an svg document, we don't want to display tooltips on the svg root node as that goes into the document title in the tab bar (we have existing tests for that). I was initially expecting parentNode == null but it seems that isn't the case. Whatever the parent is, it isn't a Node.ELEMENT_NODE.
(In reply to comment #4) > If the document is an svg document, we don't want to display tooltips on the > svg root node as that goes into the document title in the tab bar (we have > existing tests for that). This isn't true documents in frames... > I was initially expecting parentNode == null but it seems that isn't the > case. Whatever the parent is, it isn't a Node.ELEMENT_NODE. DOCUMENT_NODE
Attached patch updated patch (obsolete) (deleted) — Splinter Review
Now with DOCUMENT_NODE
Attachment #538769 - Attachment is obsolete: true
Attachment #538769 - Flags: review?(dao)
Attachment #538769 - Flags: review?(bzbarsky)
Attachment #538777 - Flags: review?(dao)
Attachment #538777 - Flags: review?(dao)
Attachment #538777 - Flags: review?(bzbarsky)
Attachment #538777 - Flags: review+
Comment on attachment 538777 [details] [diff] [review] updated patch The docshell tree owner code doesn't seem to match browser.js....
Attachment #538777 - Flags: review?(bzbarsky) → review-
Attached patch updated embedding code to match browser (obsolete) (deleted) — Splinter Review
Attachment #538777 - Attachment is obsolete: true
Attachment #540224 - Flags: review?(bzbarsky)
Comment on attachment 540224 [details] [diff] [review] updated embedding code to match browser r=me
Attachment #540224 - Flags: review?(bzbarsky) → review+
Attached patch hg changeset patch (deleted) — Splinter Review
Attachment #540224 - Attachment is obsolete: true
Keywords: checkin-needed
Keywords: checkin-needed
Whiteboard: [inbound]
Version: unspecified → Trunk
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 7
Flags: in-testsuite+
Do you have some steps to reproduce to verify that is resolved. Thx
Display the testcase attachment and put your mouse on the rect. A tooltip should be displayed which says: my rectangle
Setting resolution to Verified Fixed on Mozilla/5.0 (Windows NT 6.1; rv:7.0a2) Gecko/20110707 Firefox/7.0a2
Status: RESOLVED → VERIFIED
Depends on: 693551
What's the usual procedure if a related regression was found? This bug now depends on an unresolved regression bug, but the status is still VERIFIED FIXED.
Generally, we just mark the dependency (already done) and fix the regression in its own bug. If the regression is really bad (to the point of making our nightly builds unusable or something), then we'd back out the original patch and reopen that bug. Otherwise, though, we generally just leave the original bug closed & deal with regressions in their own bugs.
Whiteboard: [inbound]
Depends on: 715999
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: