16136 2012-02-27 16:46:54 +0000 Requiring a "plugin" for <embed> is not compatible with <embed> pointing to SVG 2013-06-05 23:24:26 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#the-embed-element P3 critical Unsorted 1 contributor ian bzbarsky ian mike zcorpan contributor oldest_to_newest 64649 0 contributor 2012-02-27 16:46:54 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html Multipage: http://www.whatwg.org/C#the-embed-element Complete: http://www.whatwg.org/c#the-embed-element Comment: Requiring a "plugin" for <embed> is not compatible with <embed> pointing to SVG Posted from: 71.184.125.56 by bzbarsky@mit.edu User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0a1) Gecko/20120218 Firefox/13.0a1 64650 1 bzbarsky 2012-02-27 16:50:32 +0000 Specifically, I believe <embed> pointing to SVG creates a child browsing context in browsers, whereas the current spec text requires that no child browsing context ever be created for <embed>.... Gecko's behavior for <embed> is that it's only handled via plug-ins (in the "no child browsing context" sense, though they also happen to be NPAPI plug-ins) except for "image/svg+xml" when it creates a child browsing context. I haven't tested other browsers extensively to see what their behavior is. 70609 2 contributor 2012-07-18 16:21:11 +0000 This bug was cloned to create bug 18070 as part of operation convergence. 73936 3 ian 2012-09-14 17:59:27 +0000 Is it an accessible browsing context? Or could it be simulated by an NPAPI plugin? 78753 4 ian 2012-11-25 03:05:53 +0000 The only method I seem to be able to get a hold of is getSVGDocument(), and it's always returning null for me: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1925 78799 5 ian 2012-11-26 04:22:45 +0000 bz: Could you elaborate on what you mean by "creates a child browsing context"? 78800 6 bzbarsky 2012-11-26 04:42:08 +0000 Acts just like http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-object-element around where it says "The object element must be associated with a newly created nested browsing context, if it does not already have one." Linking to that part specifically is slightly rocket-science because the various lists of steps are not actually linkable to. :( But it's in step 8 ("Handler") of the steps run by the queued task that (re)determines what the object element represents... It's a real child browsing context in at least the following senses: 1) getSVGDocument() will return the document object inside, if you call it _after_ the SVG has actually had a chance to load, unlike the testcase linked in comment 4. From here you can get to the Window, change the location, etc. When that happens the browsing context participates in session history in the usual way, at first glance. 2) It can be targeted by links, in at least Firefox, Safari, Chrome, and Opera; I haven't tested IE. Yes, this may just be a bug they all share. Testcase looks somewhat like this: <embed name="foo" src="test.svg"> <a href="http://w3.org" target="foo">click me</a> When this happens, the browsing context participates in session history in the usual way. 3) Scripts running in the SVG document see a Window, and window.parent is the Window corresponding to the document the <embed> is in. I strongly suspect simulating the session history bits with an NPAPI plug-in would be .... difficult at best. But I'm not an NPAPI expert. 78863 7 ian 2012-11-26 20:41:48 +0000 Oy vey. Ok. Well that's... interesting. 78875 8 bzbarsky 2012-11-26 22:23:01 +0000 Yeah, "interesting" is one way to describe it.... 78888 9 zcorpan 2012-11-27 05:20:54 +0000 Is (2) something we should try to change? Refuse navigation in <embed> browsing contexts? 82711 10 ian 2013-02-07 20:04:31 +0000 So really here we're just saying <embed> turns into a version of <object>. 82763 11 bzbarsky 2013-02-08 17:01:51 +0000 Yes, but with different behavior in terms of how it decides what type of content it's dealing with and how it will handle it... 86825 12 ian 2013-04-25 22:27:11 +0000 *** Bug 9362 has been marked as a duplicate of this bug. *** 88772 13 ian 2013-06-05 23:23:15 +0000 I've tried to define this better. Note that WebKit is way more happy-go-lucky than Gecko with <embed> (e.g. it allows src="" to point to HTML docs or images and happily renders them). I haven't specified this. I don't see much point in opening <embed> to be just a poor man's <object>; that would just lead to more surface for bugs, without adding anything. 88781 14 contributor 2013-06-05 23:24:26 +0000 Checked in as WHATWG revision r7914. Check-in comment: pushing <embed>'s specification further towards its reality http://html5.org/tools/web-apps-tracker?from=7913&to=7914