We should allow the browser to handle the content of <embed> frames as we do for <object>. This would allow a mozilla with native SVG to handle the SVG content of pages that were written for use with a plugin.

Comment on attachment 146016 [details] [diff] [review] allow browser to handle <embed> content Nice! :-) sr=jst

*** Bug 231171 has been marked as a duplicate of this bug. ***

This seems like it would make EMBED work with text/html too, which I don't think we want to do. Also, are people really using EMBED for plugin SVG content, rather than OBJECT?

The Adobe SVG demos, the Adobe "SVG Site Spotlight", and the W3C's SVG test suite all are using <embed>. Why would an embed of text/html be a bad thing? A roundabout way of doing an iframe, but doesn't seem harmful.

Using the 'object' tag to embed SVG in web pages crashes Safari 1.0, so I have been forced to switch to using 'embed' [1]. Since updates to Safari are not available to users of Mac OS X version 10.2, I have to assume Safari 1.0 will be in circulation for some years to come. [1]: http://www.alleged.org.uk/pdc/2004/02/14.html For some reason, almost all browsers have had disastrously buggy implementations of 'object' at some point; Safari is merely the most recent. As a result, 'embed' is a lot more prevelant than the W3C would have liked.

I don't think we should be adding additional capabilities to deprecated features of HTML if nobody wants them, since it just encourages use of the deprecated features.

Comment on attachment 146016 [details] [diff] [review] allow browser to handle <embed> content review- per comment 7

dbaron: Would it make you feel better if we put <embed> into a whatwg.org spec and said it was no longer deprecated?

Some standard-conscious people are forced to use 'embed' because MS IE refuses to 'render' the following straightforward construct using 'object' complaining about 'insecure' content being fed to ActiveX control. <object data="test.mp3" type="audio/mpeg" height="239" width="45"> You are expected to listen to ..... </object> To avoid that, one has to use a construct like this: <object id="Player" CLASSID="CLSID:6BF52A52-394A-11d3-B153-00C04F79FAA6" width="239" height="45" title="Playing Music"> <param name="URL" value="music.mp3" /> <param name="autoStart" value="true" /> <embed src="music.mp3" type="application/x-mplayer2" width="239" height="45" pluginspage = "http://www.microsoft.com/Windows/MediaPlayer/"> <noembed>Music to be played</noembed> </object> Again, those caring about the standard compliance would love to use 'object' in place of 'embed', but MS IE does NOT ignore the inner 'object' and complain about 'the security' although it should just ignore it because it can process the outer object.

What does that have to do with this bug? This bug is about objects that would be handled by Mozilla itself (like, say, text/html objects).

Comment on attachment 164791 [details] [diff] [review] only allow handing of svg <embed> >+#ifndef MOZ_SVG > // only do the following for the object tag > if (aContent->Tag() != nsHTMLAtoms::object) > return rv; >+#endif Just drop this entirely. It makes things more confusing, and it's not performance-critical. Also, while you're there, it looks like IsSupportedImage and IsSupportedDocument can be static. If that's correct, please make them static (one less argument passed).

Comment on attachment 164802 [details] [diff] [review] adjust per dbaron's review comments sr=jst

Checking in nsObjectFrame.cpp; /cvsroot/mozilla/layout/html/base/src/nsObjectFrame.cpp,v <-- nsObjectFrame.cpp new revision: 1.475; previous revision: 1.474 done Checking in nsObjectFrame.h; /cvsroot/mozilla/layout/html/base/src/nsObjectFrame.h,v <-- nsObjectFrame.h new revision: 1.32; previous revision: 1.31 done