hangs when an SVG group element is enclosed within a XUL template's action block




14 years ago
13 years ago


(Reporter: Andrew Harvey, Assigned: Alex Fritze)




Firefox Tracking Flags

(Not tracked)



(4 attachments)



14 years ago
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040207

If we wish to generate more than one SVG element every time a XUL template finds
a match, the elements must be enclosed within an SVG group. The
uri="?instancename" attribute is associated with the group.

As far as I can acertain, if the block contains an SVG element that uses units -
 for example

<svg:ellipse cx="1cm" cy="1cm"/>,

as opposed to

<svg:ellipse cx="16" cy="16"/>

- then Mozilla hangs.

In the attached example, I have included extra snippets of SVG which are
commented out. They demonstrate small variations that curiously work without a

Reproducible: Always
Steps to Reproduce:
1. Place the attached files svggrpexample.xul and svggrpexample.rdf in the same
2. Open ("File->Open File...") svggrpexample.xul within a version of Mozilla
with native SVG support.

Actual Results:  
Mozilla hangs as soon as the browser area is wiped. Excessive amounts of memory
begin to be consumed. The subsequent memory swapping degrades system performance

Expected Results:  
Mozilla should have displayed three ellipses in the top left corner, one on top
of another. Each ellipse should belong to it's own group, and each group should
have an ID that matches the corresponding resource name in the RDF file.

Comment 1

14 years ago
Created attachment 140858 [details]
RDF example data

Comment 2

14 years ago
Created attachment 140859 [details]
XUL example. Open this up in a version of Mozilla with native SVG support

Comment 3

14 years ago
Can someone please attach some stack trace sampes of the "hanging" mozilla ?
Keywords: stackwanted

Comment 4

14 years ago
Created attachment 140870 [details]
Stack trace

A stack trace taken while Mozilla was in its hung state.
I managed to get this to happen once; cpu usage was 0, so it's a deadlock (as
the stack shows) rather than an infinite loop....

Comment 6

14 years ago
Created attachment 140881 [details]
Stack trace demonstrating a recursive loop in 'art_vpath_render_bez()'

Found this going on in another thread. ;)

GDB was unable to give me a full stack trace in a timely manner, so I have
included only the most recent frames. The 'art_vpath_render_bez()' function is
called many hundreds of thousands of times more.

CPU usage plumets while running this test, although that is most likely due to
the excessive swapping going on.

Comment 7

14 years ago
The infinite (well nearly-infinite) loop happens because there is no viewport
axis context in content/svg/content/src/nsSVGLength.cpp::mmPerPixel().
mmPerPixel returns a very small value if the context is missing, leading to a
very large path being created.
Ever confirmed: true

Comment 8

14 years ago
The axis context for nsSVGLengths wasn't correctly restored when content was
moved from one doc to another. This is now fixed on the trunk. 
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 9

14 years ago
Fixed by what?
by the checkin alex made before adding that comment?

Comment 11

14 years ago
I'm sorry - there's no explicit comment that something was actually checked in
(or by who).  Just a diagnostic comment and then a comment that it's been fixed.
 However, if that's what happened then that's good enough.

Comment 12

14 years ago
Jason: Sorry, I should have been clearer in my comment. I did check in a fix for
this problem.
You need to log in before you can comment on or make changes to this bug.