[whatwg] <object> behavior

Ian Hickson wrote:
>> 1. Its element must be attached to the document.
> 
> I'm told this is considered a bug.

Told by whom, if I might ask?

> I've updated the spec to do the above, to the extent that I could work 
> out what the expected result is.

This doesn't actually specify what Gecko implements.  In particular, the 
current spec text means that if I have a plug-in installed which 
supports text/html and the <object> has type="text/html" then the data 
should be rendered as text/html regardless of the server type, even 
though it will be rendered by the browser itself, not by the plug-in. 
This was explicitly something I wanted to avoid in the Gecko code, and 
was called out that way in the bugs I referenced.

Was that difference intentional?

Another other difference is the way data-sniffing is applied.  In Gecko, 
data-sniffing is applied on the HTTP layer in this case, so that the 
type considered in subsubstep 3 of your algorithm already takes 
data-sniffing into account.  In practical terms the difference is that 
data-sniffing only occurs if the HTTP response from the server doesn't 
deliver a Content-Type header (modulo the text/plain thing, of course). 
  If we assume that no plug-in has registered itself for 
application/octet-stream, then the only cases that lead to a different 
behavior between the two algorithms are those of the server sending 
text/plain (for binary data) or application/octet-stream as the type. 
Your algorithm leads to data-snifing in both cases, while no 
data-sniffing is performed in Gecko for either case.

I'm not particularly happy performing data-sniffing in those cases, 
particularly the text/plain case (since that can lead to such data being 
handled as text/html by the UA, given how your spec text is written 
right now).

As far as text/plain goes, the current spec text means that if I have a 
PostScript file that includes some "binary" bytes in the first 512 bytes 
and my web server sends text/plain for it and the <object> has a type 
attribute with the value "text/plain" then the data will be treated as 
application/postscript.  That doesn't seem desirable to me.  Is it 
intentional?

>> 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.
> 
> I haven't specced this for <object> yet -- let me know exactly what the 
> spec should say if you want this added also. I'd rather have as little 
> dependence on extensions as possible.

What the Gecko code basically does is that if the type is 
application/octet-stream after everything else has been done (so the 
place where your current spec says "then change the resource type to be 
unknown, so that the sniffing rules in the next step are invoked") then 
we examine the extension of the URI.  If that extension exists and if 
there's a plug-in registered for that extension, then we set the 
"resource type" (in your current draft's terms) to be the associated 
MIME type reported by the plug-in.  I'm not sure where this list of 
(extension,type) pairs comes from, but it looks like the plug-in 
provides it somehow (possibly even in that form, looking at 
<http://mxr.mozilla.org/mozilla-central/source/modules/plugin/base/src/nsPluginsDirUtils.h#53>).

-Boris

Received on Sunday, 6 September 2009 11:53:47 UTC