Last Comment Bug 386856 - onload event handler not called for SVG that are result of XSLT transformation
: onload event handler not called for SVG that are result of XSLT transformation
Status: RESOLVED INVALID
:
Product: Core
Classification: Components
Component: SVG (show other bugs)
: unspecified
: x86 Windows XP
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://www.astrotexte.ch/sources/svgo...
: 493585 570696 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-04 08:53 PDT by Rüdiger Plantiko
Modified: 2010-06-14 12:45 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Rüdiger Plantiko 2007-07-04 08:53:55 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

When embedding an SVG graphic into an HTML Site with an object tag as below, 
with a XSL-styled XML document as source, the onload event handler is not called . If, however, the result tree which is a valid SVG document, is produced by an external XSLT processor and embedded the same way into the HTML page, the onload handler will be called and the graphic will be displayed correctly.

...
  <object data="horo.xml" type="image/svg+xml" width="400" height="400">
    <param name="src" value="horo.xml">
    [no SVG viewer installed... blabla...]
  </object>
...

http://www.astrotexte.ch/sources/svgonload.html contains a reproduceable example and all the necessary files.
 


Reproducible: Always

Steps to Reproduce:
1. Create a sample XML document in an arbitrary format
2. Create an XSLT transformation which generates an SVG graphic from it. The graphic contains an onload-handler to manipulate the SVG tree depending on the XML source document (1).
3. Use the <?xml-stylesheet... ?> processing instruction to associate (2) with (1)
4. Create a HTML page and embed the XML-document into it as SVG-graphic, using the <object> tag.
5. When calling the HTML page, observe that the onload handler is not called and therefore the graphic doesn't render as expected.
6. However, when transforming the XML document externally, e.g. with Perl's XML::XSLT processor, and embedding the result into the page using the <object> tag as above, observe that the onload handler is called and the graphic renders as expected.

http://www.astrotexte.ch/sources/svgonload.html contains a reproduceable example and all the necessary files.
 

Actual Results:  
onload handler is not called => graphic not rendered properly

Expected Results:  
onload handler should be called
Comment 1 Boris Zbarsky [:bz] 2009-08-23 12:36:52 PDT
The SVG specification defines the onload handler as being called when the element is parsed.  In this case, there is no parsing going on: you're directly synthesizing SVG DOM nodes.  You'd get the same effect if you built the DOM tree involved using createElementNS.

You might want to raise this with the SVG working group...
Comment 2 Rüdiger Plantiko 2009-08-24 23:42:46 PDT
Hi Boris, 

thank you for your answer which I can accept - although I remain now with the problem which event could be used (if not onload) to attach the JavaScript to it. XSLT in its current form is not apt for trigonometrical calculations. Maybe I will try to contact the SVG working group, as you recommended.

Regards,
Rüdiger
Comment 3 chris 2009-08-26 01:01:14 PDT
This was discussed at the 26 August SVG WG telcon. We observed that some browsers (Safari and Opera) do throw a load event, so the upper and lower subtests look the same. Firefox (various versions up to 3.6a1) did not.

XSLT does not define the processing of the result tree and says its application dependent how its loaded
http://www.w3.org/TR/2009/PER-xslt20-20090421/#result-trees

In general we felt that load should throw, but are investigating further. Also doing similar testing for XSLT which generates HTML. Anyway, just to say that your report was picked up and is being acted on.
Comment 4 Boris Zbarsky [:bz] 2009-08-26 03:04:39 PDT
Chris, just to be clear, XSLT has two primary modes of operation.  Either DOM nodes are produced directly as the output of the transform, or they're produced, serialized, then parsed.  Per the current definitions in the SVG spec, the latter would fire load events.  Some browser XSLT engines operate in the latter mode some or all the time.  In the former mode, the operation really does look just like building a DOM with createElementNS then adopting it into another document.

Thanks for looking into this.
Comment 5 Rüdiger Plantiko 2009-08-27 12:29:55 PDT
Hi Boris and Chris, 

thank you for these deep and detailed inside informations on SVG as well as on the Firefox implementation. Persopnally, I would agree that re-using the existing onload event in the XSLT case is better than providing an extra event for that case. But you both will agree with me about the necessity of such an event - whatever decision the W3C SVG group will make.

With best regards,
Rüdiger
Comment 6 Cameron McCormack (:heycam) 2009-09-02 18:48:10 PDT
HTML 5 doesn't say anything about how to treat the result of xml-stylesheet-begotten HTML documents either, but Firefox, Opera and WebKit all dispatch a load event:

  http://mcc.id.au/temp/2009/xslt-load-event-html.xml

For SVG documents, Opera and WebKit dispatch it:

  http://mcc.id.au/temp/2009/xslt-load-event-svg.xml

So I think despite the lack of spec treatment it would at least be consistent with HTML to dispatch it for SVG documents created using XSLT.
Comment 7 Boris Zbarsky [:bz] 2009-09-02 19:10:38 PDT
In the former case, the event is fired on the window.  We do fire it on the window for the SVG case too; if your script were registering a handler for the window load event, you would see it.  But it's not doing that; unlike onload on <body> in HTML (which HTML5 DOES define to add an event handler to the window), onload on the root <svg> in SVG just listens for the load event on the element.

So we're already being consistent in terms of HTML and SVG here as far as the events we dispatch; the two are just not consistent with each other as far as what event listeners they register.

Opera and Webkit reparse their XSLT output last I checked, so there is no spec issue.
Comment 8 Robert Longson 2010-06-08 05:27:38 PDT
*** Bug 570696 has been marked as a duplicate of this bug. ***
Comment 9 Robert Longson 2010-06-13 13:12:47 PDT
*** Bug 493585 has been marked as a duplicate of this bug. ***
Comment 10 jonathan chetwynd 2010-06-13 13:46:15 PDT
#7  Boris, could you expand on what you mean in this comment?
I have read the complete comments.

in particular it seems to my reading that you may at least, be saying that in the case of svg only, that is not using object in html; you believe the onload event is fired, however my Bug 493585 which has a testcase, is also broken, and I cannot quite understand the issue, most particularly as Safari and Opera work fine.

in my simple understanding, there is no svg document until after the xslt transformation, and so there should be an onload event that is used by script.
Comment 11 Boris Zbarsky [:bz] 2010-06-13 13:57:58 PDT
> however my Bug 493585 which has a testcase, is also broken

You really need to read comment 7 again...  To repeat, Gecko fires a load event on the _window_ in that case.  You aren't putting an event handler on the window.  So you don't see the load event.  The XSLT behavior in Safari and Opera is different because last I checked they produce a _string_ and parse it.  SVG _element_ load events fire during parsing.

All of which I said before.
Comment 12 Rüdiger Plantiko 2010-06-13 15:03:40 PDT
Hi Boris, 

the only unsatisfactory point with your solution (which happily means for Firefox to keep everything as it was in 2007 when I submitted this report) is a layer problem: 

If an HTML page embeds an SVG graphic - why should the SVG graphic itself know or care about this? Why should the SVG graphic register its load handler on "window:onload" which does not belong to the graphic itself? On the other hand, the example shows that the SVG graphic itself needs a load event.

You could argue that it's in the responsibility of the HTML page to call the load handler for the embedded SVG graphics. But again, the example shows that this handler belongs to the graphics itself and not to the environment in which it is embedded. Why should the HTML page care about the inner structure of a graphic (in particular about its special necessity of being finished by a load handler) - the HTML page only wants to embed it. If it contains, say, 20 images in different formats, the markup should only contain the references to these images, but not further graphic-format-specific details for rendering the images properly.

Regards,
Rüdiger
Comment 13 Boris Zbarsky [:bz] 2010-06-13 18:50:06 PDT
> Why should the SVG graphic register its load handler on "window:onload" which
> does not belong to the graphic itself?

It shouldn't, nor does it.

> On the other hand, the example shows that the SVG graphic itself needs a load
> event.

Why?  The SVG spec defines load events that fire during parsing.  They don't fire when you create SVG images in some other way (say via the DOM's createElement and appendChild).  If you think that should change, the right place to bring it up is the SVG working group.
Comment 14 Rüdiger Plantiko 2010-06-14 12:45:55 PDT
Hi Boris, 

thanks for patiently clarifying again, and for reminding me to my pending request at w3.org. I now added a new message there asking for the status.

http://lists.w3.org/Archives/Public/www-svg/2009Aug/0054.html

QUOTATION ON

[...]

To remember: I need a means (an appropriate event?) to preprocess a graphic (in my special case, using JavaScript as manipulation language).

This preprocessing belongs to the graphic itself, and it is of no relevance whether this graphic is generated by XSLT, by the DOM API or embedded into the HTML page using the <object> element. The concrete way how the SVG is produced is irrevelant. The preprocessing is inherent to the graphic, independent of its production.

Before the graphic is rendered, there should be an option to preprocess it. The page

http://www.astrotexte.ch/sources/svgonload.html

still serves as a good example, since the positioning of the symbols involves trigonometric calculations - for such kind of computations JavaScript is an appropriate choice.

[QUOTATION OFF]

Kind regards,
Rüdiger

Note You need to log in before you can comment on or make changes to this bug.