html5-inlineSVG-title display tooltip

VERIFIED FIXED in Firefox 7

Status

()

Firefox
General
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: jonathan chetwynd, Assigned: Robert Longson)

Tracking

Trunk
Firefox 7
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 3 obsolete attachments)

(Reporter)

Description

6 years ago
Created attachment 517824 [details]
testcase

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)

Updated

6 years ago
Assignee: nobody → longsonr
(Assignee)

Comment 2

6 years ago
Created attachment 538769 [details] [diff] [review]
patch
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
(Assignee)

Comment 4

6 years ago
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
(Assignee)

Comment 6

6 years ago
Created attachment 538777 [details] [diff] [review]
updated patch

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)

Updated

6 years ago
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-
(Assignee)

Comment 8

6 years ago
Created attachment 540224 [details] [diff] [review]
updated embedding code to match browser
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+
(Assignee)

Comment 10

6 years ago
Created attachment 543245 [details] [diff] [review]
hg changeset patch
Attachment #540224 - Attachment is obsolete: true
(Assignee)

Updated

6 years ago
Keywords: checkin-needed
http://hg.mozilla.org/integration/mozilla-inbound/rev/74635b831e9e
Keywords: checkin-needed
Whiteboard: [inbound]
Version: unspecified → Trunk
http://hg.mozilla.org/mozilla-central/rev/74635b831e9e
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 7
(Assignee)

Updated

6 years ago
Flags: in-testsuite+

Comment 13

6 years ago
Do you have some steps to reproduce to verify that is resolved.
Thx
(Assignee)

Comment 14

6 years ago
Display the testcase attachment and put your mouse on the rect. A tooltip should be displayed which says: my rectangle

Comment 15

6 years ago
Setting resolution to Verified Fixed on Mozilla/5.0 (Windows NT 6.1; rv:7.0a2) Gecko/20110707 Firefox/7.0a2
Status: RESOLVED → VERIFIED

Updated

6 years ago
Depends on: 693551

Comment 16

6 years ago
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]

Updated

6 years ago
Depends on: 715999
Blocks: 601091
You need to log in before you can comment on or make changes to this bug.