378165 - getCTM does not work in SVG element combined inside XBL

Status: RESOLVED WONTFIX

(Core :: SVG, defect)

Description

[Ondrej Palkovsky]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070310 Iceweasel/2.0.0.3 (Debian-2.0.0.3-1) XPCOMViewer/0.9.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070310 Iceweasel/2.0.0.3 (Debian-2.0.0.3-1) XPCOMViewer/0.9.5

When XBL is combined with SVG, the XBL objects do not have the nsIDOMSVGLocatable interface. The getCTM (and the other similar functions) traverse the DOM tree from the child and upon encountering a parent that does not have this interface, they fail.
The solution is either have the XBL elements contain the nsIDOMSVGLocatable interface (I do extend from svg:generic, it does not seem to make any difference), or skip elements that do not have this interface. See nsSVGGraphicElement.cpp and nsSVGSVGElement.cpp.

Translating event.clientX/Y to the SVG coordinates correctly is difficult without these functions, making a clickable SVG application thus becomes nearly impossible.

Reproducible: Always

Steps to Reproduce:
See the web example.
Actual Results:  
Displays one dialog and fails on the second getCTM.

Expected Results:  
Should display 2 dialogs with Matrix object. First for ownerSVGelement (works), second for svg:text inside xbl (does not work).

Comment 1

[Robert Longson [:longsonr]]

What web example are you referring to? The URL seems to go to a simple SVG file.

Comment 2

[Ondrej Palkovsky]

The SVG file has a stylesheet associated (test.css) which connect the 'test' tag to an xbl file (test.xbl).

Comment 3

[Jonathan Watt [:jwatt]]

Ondrej, the SVG file is completely empty. Can you attach a test to this bug please?

Comment 4

[Ondrej Palkovsky]

I have returned the file back to the web server, try it again.

Comment 5

[Jonathan Watt [:jwatt]]

So you have:

<svg xmlns="http://www.w3.org/2000/svg"   width="300" height="300">
  <test />
</svg>

and an XBL binding attached to the <test/> element to give it an anonymous <svg:text> child. The reason this doesn't work as you expect is that <test> is not a valid SVG element. As a result of this invalid SVG tree you get things breaking. Not too surprising.

Comment 6

[Ondrej Palkovsky]

the binding has an attribute 'extends="svg:generic"'. How do you build a valid svg binding then? Actually, this type of examples was given in some tutorials. 

Comment 7

[Jonathan Watt [:jwatt]]

I'm actually not clear on what 'extends="svg:generic"' _really_ does, so CC'ing Jonas in the hope he might comment on this bug.

Comment 8

[Ondrej Palkovsky]

I would expect it would make the element an SVG one - unfortunately it does not. The point is that I did not find any other way how to make an XBL binding while preserving the ability to call getCTM, which then makes XBL with SVG slightly less usable.

Comment 9

[Jonathan Watt [:jwatt]]

The key would be to bind to a valid SVG element instead of any other type. You might consider using <g> or some other element that fits in the context (e.g. <tspan> in <text>).

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Not sure what using 'svg:generic' does, but if you use 'svg:g' that means that you should get an svg:g-frame. Not sure how well this is supported though, and we've talked about removing support for extends="tagname" anyway due to it being so buggy.

So I would do what jwatt suggests and bind to an svg element instead.

Comment 11

[Paul Nickerson]

This testcase actually crashes me on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a2pre) Gecko/20090814 Minefield/3.6a2pre (.NET CLR 3.5.30729). I'm going to pull and compile the latest source then I'll try again and attach the stack.

Comment 12

[Robert Longson [:longsonr]]

(In reply to comment #11)
> This testcase actually crashes me on Mozilla/5.0 (Windows; U; Windows NT 5.1;
> en-US; rv:1.9.2a2pre) Gecko/20090814 Minefield/3.6a2pre (.NET CLR 3.5.30729).
> I'm going to pull and compile the latest source then I'll try again and attach
> the stack.

That's expected. bug 508247 hasn't landed on 1.9.2 yet

Comment 13

[Robert Longson [:longsonr]]

extends tagname support was removed in bug 378518.