getCTM does not work in SVG element combined inside XBL

RESOLVED WONTFIX

Status

()

Core
SVG
RESOLVED WONTFIX
11 years ago
6 years ago

People

(Reporter: Ondrej Palkovsky, Unassigned)

Tracking

1.8 Branch
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

11 years ago
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).
Assignee: nobody → general
Component: General → SVG
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → 1.8 Branch
What web example are you referring to? The URL seems to go to a simple SVG file.
(Reporter)

Comment 2

11 years ago
The SVG file has a stylesheet associated (test.css) which connect the 'test' tag to an xbl file (test.xbl).
Ondrej, the SVG file is completely empty. Can you attach a test to this bug please?
(Reporter)

Comment 4

11 years ago
I have returned the file back to the web server, try it again.
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.
(Reporter)

Comment 6

11 years ago
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. 
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.
(Reporter)

Comment 8

11 years ago
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.
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>).
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.
Assignee: general → nobody
QA Contact: ian → general

Comment 11

9 years ago
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.
(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
extends tagname support was removed in bug 378518.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.