[whatwg] <object> behavior

Ian Hickson wrote:
> On Tue, 25 Aug 2009, Andrew Oakley wrote:
>> So if we had a type attribute of application/x-shockwave-flash, and a 
>> Content-Type header of image/png we would use the flash plugin. 
>> Following the HTML5 spec we would use the image renderer.
> 
> Ah, yes, that's intentional (doing otherwise violates HTTP1.1). Is this 
> something you're forced into for compatibility?

Yes.  Initially we implemented preferring the HTTP content-type header 
to the type attribute in 
<https://bugzilla.mozilla.org/show_bug.cgi?id=1156>.  This caused a 
variety of compatibility issues:

1)  Various sites serving plug-in data as text/plain or 
application/octet-stream.  This was resolved by using the regular "is 
this text actually binary?" sniffer and dispatching based on type hint 
(in practice the type attribute at the time, but see below) if we have 
sniffed binary or application/octet-stream.  See 
<https://bugzilla.mozilla.org/show_bug.cgi?id=389677>, which lists two 
sites that hit this.  See 
<https://bugzilla.mozilla.org/show_bug.cgi?id=390891> for another 
example of this problem.

2)  A number of sites, including for example all the Apple keynote 
videos, just plain served plug-ins with the wrong server-provided MIME 
type which was not either text/plain or application/octet-stream.  See 
<https://bugzilla.mozilla.org/show_bug.cgi?id=395110> (and 
<https://bugzilla.mozilla.org/show_bug.cgi?id=416480>, 
<https://bugzilla.mozilla.org/show_bug.cgi?id=414310>, 
<https://bugzilla.mozilla.org/show_bug.cgi?id=416867>).  Note that we 
did some debugging here and found that Opera had the same compatibility 
issues we did on the Apple videos; Safari did not because it was mapping 
a limited set of ActiveX classids to its internal MIME type dispatch and 
thus using the outer <object>, not the inner one.  As a result of this 
issue, we introduced our current behavior of preferring @type if it's a 
type we handle via a plug-in.

3)  A number of sites not only send a bogus server-provided type (e.g. 
application/octet-stream) but also use a bogus type attribute 
(specifically, application/plugin-mimetype; I suspect this is a relic of 
Netscape's devedge documentation using that as an example placeholder). 
  See <https://bugzilla.mozilla.org/show_bug.cgi?id=393756>.  The URI 
extension is used to get the type to really use in those cases in 
Gecko...  If desired, I could probably dig through and figure out the 
exact conditions that trigger this case.

-Boris

P.S.  For <embed> things are different but still quite interesting, of 
course...  In particular, one has to use the URI extension there, not 
just the @type.

Received on Monday, 31 August 2009 06:25:23 UTC