240408 - Allow browser to handle <embed> content

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[tor]

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 1

[tor]

Attachment: allow browser to handle <embed> content

Comment 2

[Johnny Stenback (:jst)]

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

Nice! :-)

sr=jst

Comment 3

[Jonathan Watt [:jwatt]]

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

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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?

Comment 5

[tor]

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.

Comment 6

[P. Damian Cugley]

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.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

review- per comment 7

Comment 9

[Hixie (not reading bugmail)]

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

Comment 10

[Jungshik Shin]

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.  

Comment 11

[Boris Zbarsky [:bzbarsky]]

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 12

[tor]

Attachment: only allow handing of svg <embed>

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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 14

[tor]

Attachment: adjust per dbaron's review comments

Comment 15

[Johnny Stenback (:jst)]

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

sr=jst

Comment 16

[tor]

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