This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
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.
This bug was cloned to create bug 18070 as part of operation convergence.
Is it an accessible browsing context? Or could it be simulated by an NPAPI plugin?
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
bz: Could you elaborate on what you mean by "creates a child browsing context"?
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.
Oy vey. Ok. Well that's... interesting.
Yeah, "interesting" is one way to describe it....
Is (2) something we should try to change? Refuse navigation in <embed> browsing contexts?
So really here we're just saying <embed> turns into a version of <object>.
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...
*** Bug 9362 has been marked as a duplicate of this bug. ***
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.
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