639945 - html5-inlineSVG-title display tooltip

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[jonathan chetwynd]

Attachment: testcase

SVG <title> displays as tooltip in file served as SVG

however SVG <title> inline in file served as HTML5 does not raise tooltip

Comment 1

[Boris Zbarsky [:bzbarsky]]

The tooltip stuff is handled entirely by the UI, no?

Comment 2

[Robert Longson [:longsonr]]

Attachment: patch

Comment 3

[Dão Gottwald [:dao]]

Comment on attachment 538769 [details] [diff] [review]
patch

>+           tipElement.parentNode.nodeType != Node.ELEMENT_NODE)) {

What's the point of this?

Comment 4

[Robert Longson [:longsonr]]

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.

Comment 5

[Dão Gottwald [:dao]]

(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

Comment 6

[Robert Longson [:longsonr]]

Attachment: updated patch

Now with DOCUMENT_NODE

Comment 7

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 538777 [details] [diff] [review]
updated patch

The docshell tree owner code doesn't seem to match browser.js....

Comment 8

[Robert Longson [:longsonr]]

Attachment: updated embedding code to match browser

Comment 9

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 540224 [details] [diff] [review]
updated embedding code to match browser

r=me

Comment 10

[Robert Longson [:longsonr]]

Attachment: hg changeset patch

Comment 11

[Daniel Holbert [:dholbert]]

http://hg.mozilla.org/integration/mozilla-inbound/rev/74635b831e9e

Comment 12

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

http://hg.mozilla.org/mozilla-central/rev/74635b831e9e

Comment 13

[Vlad [QA]]

Do you have some steps to reproduce to verify that is resolved.
Thx

Comment 14

[Robert Longson [:longsonr]]

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

Comment 15

[Vlad [QA]]

Setting resolution to Verified Fixed on Mozilla/5.0 (Windows NT 6.1; rv:7.0a2) Gecko/20110707 Firefox/7.0a2

Comment 16

[yvoschu]

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.

Comment 17

[Daniel Holbert [:dholbert]]

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.