[whatwg] <object> behavior

[Ian Hickson]

On Thu, 3 Sep 2009, Michael A. Puls II wrote:
> On Wed, 02 Sep 2009 17:39:00 -0400, Ian Hickson <ian at hixie.ch> wrote:
> > On Thu, 27 Aug 2009, Michael A. Puls II wrote:
> > > 
> > > Here's an example that uses a more modern plug-in that shows what 
> > > browsers do.
> > > 
> > > window.onload = function() {
> > >     var obj = document.createElement("object");
> > >     obj.type = "application/x-shockwave-flash";
> > >     obj.data = "http://adobe.com/shockwave/welcome/flash.swf";
> > >     obj.width = "320";
> > >     obj.height = "240";
> > >     //document.body.appendChild(obj);
> > >     //obj.style.display = "none";
> > >     setTimeout(function() {
> > >         alert(obj.SetVariable);
> > >     }, 1000);
> > > };
> > > 
> > > In other words, for a plug-in to be initialized (and scriptable if it's
> > > capable):
> > > 
> > > 1. Its element must be attached to the document.
> > 
> > I'm told this is considered a bug.
> 
> O.K., so once that's fixed in browsers, if I do:
> 
> var obj = document.createElement("object");
> obj.type = "application/x-shockwave-flash";
> obj.data = "file.swf"
> obj.appendParam("quality", "low");
> 
> , will that load as soon as I set @type (according to HTML5) and result in
> @data and the param not being honored because the plug-in already initialized?

Hm, good point.

Fixed.


On Sun, 6 Sep 2009, Boris Zbarsky wrote:
> 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 thought by you, but apparently I misunderstood the point you had been 
making! I've changed HTML5 to not instantiate plugins when their element 
is not in the document, and to uninstantiate any that are removed from the 
document.


> > 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?

I didn't realise that the list of types the UA supported and the list of 
types plugins supported could overlap.

Fixed.


> 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?

Yes. This is the same as happens if you navigate straight to such a file, 
as far as I can tell. Why would we not want that?


> > > 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>).

Ok, I've added that. It matches what happens with <embed> now.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'