36297 2010-03-18 08:47:19 -0700 getSVGDocument method of an Object element returns undefined in unload 2016-10-12 05:40:24 -0700 1 1 1 Unclassified WebKit SVG 528+ (Nightly build) All All RESOLVED INVALID P2 Normal --- 0 azerkoculu webkit-unassigned ap bburg cdumez krit robertc oldest_to_newest 201322 0 azerkoculu 2010-03-18 08:47:19 -0700 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 514516 1 117763 robertc 2011-12-03 10:10:25 -0800 Created attachment 117763 Example of issue 514517 2 117764 robertc 2011-12-03 10:11:07 -0800 Created attachment 117764 SVG for attachment 117763 514518 3 robertc 2011-12-03 10:15:25 -0800 Problem still exists in Google Chrome 16.0.912.59 beta, Linux x64. 514882 4 ap 2011-12-04 21:15:26 -0800 There is no such method in HTML5. Why is it important to support? 514955 5 robertc 2011-12-05 00:28:33 -0800 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. 514967 6 ap 2011-12-05 01:14:04 -0800 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? 514978 7 robertc 2011-12-05 01:45:02 -0800 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. 515129 8 ap 2011-12-05 09:14:33 -0800 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. 515217 9 robertc 2011-12-05 11:09:06 -0800 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? 515249 10 ap 2011-12-05 11:48:17 -0800 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. 515437 11 robertc 2011-12-05 15:13:11 -0800 > 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? 1137150 12 bburg 2015-10-28 09:50:59 -0700 +cdumez for thoughts on spec conformance. 1239253 13 krit 2016-10-12 05:40:24 -0700 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. 117763 2011-12-03 10:10:25 -0800 2011-12-03 10:10:25 -0800 Example of issue svg-embed-javascript.html text/html 624 robertc PCFET0NUWVBFIGh0bWw+CjxodG1sPgo8aGVhZD4KICAgIDxtZXRhIGNoYXJzZXQ9InV0Zi04Ij4K ICAgIDx0aXRsZT5TVkcgRW1iZWQ8L3RpdGxlPgogICAgPHNjcmlwdD4KICAgIHdpbmRvdy5vbmxv YWQgPSBmdW5jdGlvbiAoKSB7CiAgICAgICAgdmFyIHN2Z2VsID0gZG9jdW1lbnQuZ2V0RWxlbWVu dEJ5SWQoJ215ZW1iZWQnKTsKICAgICAgICB2YXIgc3ZnOwogICAgICAgIGlmICh0eXBlb2Ygc3Zn ZWwuZ2V0U1ZHRG9jdW1lbnQgIT09ICd1bmRlZmluZWQnKSB7CiAgICAgICAgICAgIHN2ZyA9IHN2 Z2VsLmdldFNWR0RvY3VtZW50KCk7CiAgICAgICAgfSBlbHNlIHsKICAgICAgICAgICAgc3ZnID0g c3ZnZWwuY29udGVudERvY3VtZW50OwogICAgICAgIH0KICAgICAgICB2YXIgcmVjdCA9IHN2Zy5n ZXRFbGVtZW50QnlJZCgnbG90MWEnKTsKICAgICAgICB3aW5kb3cuYWxlcnQoJ3g6JyArIHJlY3Qu Z2V0QXR0cmlidXRlKCd4JykgKyAnIHk6JyArIHJlY3QuZ2V0QXR0cmlidXRlKCd5JykpOwogICAg fQogICAgPC9zY3JpcHQ+CjwvaGVhZD4KPGJvZHk+CiAgICA8ZW1iZWQgc3JjPSJteXN2Zy5zdmci IHR5cGU9ImltYWdlL3N2Zyt4bWwiIGlkPSJteWVtYmVkIiAvPgo8L2JvZHk+CjwvaHRtbD4K 117764 2011-12-03 10:11:07 -0800 2011-12-03 10:11:07 -0800 SVG for attachment 117763 mysvg.svg image/svg+xml 257 robertc PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+Cjxz dmcgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB2ZXJzaW9uPSIxLjEiIHZpZXdC b3g9IjAgMCAzMDAgMzAwIj4KICA8cmVjdCB4PSI1MCIgeT0iNTAiIHdpZHRoPSI1MCIgaGVpZ2h0 PSI1MCIgc3R5bGU9ImZpbGw6IHJlZDsiIGlkPSJsb3QxYSIgLz4KICA8cGF0aCBkPSJNMTUwIDAg TDc1IDIwMCBMMjI1IDIwMCBaIiAvPgo8L3N2Zz4=