This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 16136 - Requiring a "plugin" for <embed> is not compatible with <embed> pointing to SVG
Summary: Requiring a "plugin" for <embed> is not compatible with <embed> pointing to SVG
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 critical
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
: 9362 (view as bug list)
Depends on:
Reported: 2012-02-27 16:46 UTC by contributor
Modified: 2013-06-05 23:24 UTC (History)
4 users (show)

See Also:


Description contributor 2012-02-27 16:46:54 UTC

Requiring a "plugin" for <embed> is not compatible with <embed> pointing to

Posted from: by
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0a1) Gecko/20120218 Firefox/13.0a1
Comment 1 Boris Zbarsky 2012-02-27 16:50:32 UTC
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.
Comment 2 contributor 2012-07-18 16:21:11 UTC
This bug was cloned to create bug 18070 as part of operation convergence.
Comment 3 Ian 'Hixie' Hickson 2012-09-14 17:59:27 UTC
Is it an accessible browsing context? Or could it be simulated by an NPAPI plugin?
Comment 4 Ian 'Hixie' Hickson 2012-11-25 03:05:53 UTC
The only method I seem to be able to get a hold of is getSVGDocument(), and it's always returning null for me:
Comment 5 Ian 'Hixie' Hickson 2012-11-26 04:22:45 UTC
bz: Could you elaborate on what you mean by "creates a child browsing context"?
Comment 6 Boris Zbarsky 2012-11-26 04:42:08 UTC
Acts just like 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="" 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.
Comment 7 Ian 'Hixie' Hickson 2012-11-26 20:41:48 UTC
Oy vey. Ok. Well that's... interesting.
Comment 8 Boris Zbarsky 2012-11-26 22:23:01 UTC
Yeah, "interesting" is one way to describe it....
Comment 9 Simon Pieters 2012-11-27 05:20:54 UTC
Is (2) something we should try to change? Refuse navigation in <embed> browsing contexts?
Comment 10 Ian 'Hixie' Hickson 2013-02-07 20:04:31 UTC
So really here we're just saying <embed> turns into a version of <object>.
Comment 11 Boris Zbarsky 2013-02-08 17:01:51 UTC
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...
Comment 12 Ian 'Hixie' Hickson 2013-04-25 22:27:11 UTC
*** Bug 9362 has been marked as a duplicate of this bug. ***
Comment 13 Ian 'Hixie' Hickson 2013-06-05 23:23:15 UTC
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.
Comment 14 contributor 2013-06-05 23:24:26 UTC
Checked in as WHATWG revision r7914.
Check-in comment: pushing <embed>'s specification further towards its reality