Bug 36297 - getSVGDocument method of an Object element returns undefined in unload
Summary: getSVGDocument method of an Object element returns undefined in unload
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-18 08:47 PDT by azerkoculu
Modified: 2016-10-12 05:40 PDT (History)
5 users (show)

See Also:


Attachments
Example of issue (624 bytes, text/html)
2011-12-03 10:10 PST, Rob Crowther
no flags Details
SVG for attachment 117763 (257 bytes, image/svg+xml)
2011-12-03 10:11 PST, Rob Crowther
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description azerkoculu 2010-03-18 08:47:19 PDT
As I've written in the summary, getSVGDocument method of the Object element doesn't work. Please check the test page in the URL.

User Agent: AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.249.30 Safari/532.5
Comment 1 Rob Crowther 2011-12-03 10:10:25 PST
Created attachment 117763 [details]
Example of issue
Comment 2 Rob Crowther 2011-12-03 10:11:07 PST
Created attachment 117764 [details]
SVG for attachment 117763 [details]
Comment 3 Rob Crowther 2011-12-03 10:15:25 PST
Problem still exists in Google Chrome 16.0.912.59 beta, Linux x64.
Comment 4 Alexey Proskuryakov 2011-12-04 21:15:26 PST
There is no such method in HTML5. Why is it important to support?
Comment 5 Rob Crowther 2011-12-05 00:28:33 PST
I don't care if you don't want to support it, but it's already implemented:

var svg = document.getElementById('myembed');
window.alert(typeof svg.getSVGDocument);

This will alert 'function' (http://jsfiddle.net/HkVY8/).  So either don't support it, or make it work.
Comment 6 Alexey Proskuryakov 2011-12-05 01:14:04 PST
You are right, it is supported in WebKit.

In your test case, undefined is returned simply because there is no document in <embed> yet at the time when load event is dispatched. It will be there after a timeout. Why do you think that this a is a bug?
Comment 7 Rob Crowther 2011-12-05 01:45:02 PST
I'm already in window.onload in the testcase, why is there no document loaded yet?  If you attach to the load event on the embed (or object) element itself, you get the same result.  Is it really necessary to resort to setTimeout hacks?  Why are these events firing if the content isn't yet loaded?

If you try the testcase in Firefox or Opera there will be a document loaded when getSVGDocument is called.
Comment 8 Alexey Proskuryakov 2011-12-05 09:14:33 PST
Per HTML5, load event should be delayed until the resource specified by embed's src attribute is fetched. Nothing says that it should be delayed until it's parsed into a document. So, WebKit result on this test doesn't appear non-compliant.

That said, a look at Web Inspector timeline reveals that WebKit doesn't delay load event until after fetching the resource specified by the src attribute, which is wrong per HTML5.
Comment 9 Rob Crowther 2011-12-05 11:09:06 PST
I've been able to confirm today that the test case also works in IE9.  Chrome is the only browser I have available that it doesn't work in.

If the load event doesn't require that the document be parsed when it's getting fired on a document object then it makes the load event kind of useless in that scenario.  Should I file a bug on the spec, or do you think this issue would be resolved if the load event was being delayed correctly?
Comment 10 Alexey Proskuryakov 2011-12-05 11:48:17 PST
This might be worth discussing with the standards community. Let me add some more background.

Object and embed element behavior is primarily tailored for plug-ins, and you don't get much insight into what happens inside a plug-in after fetching its top resource from the network. For many plug-ins, that top resource could be just a small handle to the real data. 

Plug-ins that do media playback are different yet, the load event definitely shouldn't be delayed until after the media file loads. Such plug-ins often don't even attempt to hold the whole media file locally. It's the same as <video> and <audio> elements in HTML5, which also don't delay the load event.

So, it seems that HTML5 is not quite right when it requires that loading plug-in resource must delay the load event. That cannot and shouldn't be done for media at least.

Providing different behavior for plug-ins and for types handled internally by the engine seems inconsistent, but could be considered.

Practically, I would suggest putting the SVG document in an iframe, not in an embed.
Comment 11 Rob Crowther 2011-12-05 15:13:11 PST
> This might be worth discussing with the standards community.

I'll file a bug and see what happens.  At the very least, if Firefox, Opera, IE and Chrome are all following the same spec then they should all behave the same way.  So if Chrome is arguably doing the right thing then the spec needs to be made more clear.

> Practically, I would suggest putting the SVG document in an iframe, not
> in an embed.

Doesn't really help if the primary reason for using object/embed was to provide fallback content or plugins for older browsers?
Comment 12 Brian Burg 2015-10-28 09:50:59 PDT
+cdumez for thoughts on spec conformance.
Comment 13 Dirk Schulze 2016-10-12 05:40:24 PDT
We did change the loading behavior in SVG a couple of years ago. At the moment the test case on jsfiddle does work as expected and the same across browsers. Closing.