[whatwg] <object> behavior

[Ian Hickson]

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.


> 2. Its element must not be set to display of 'none' (and therefore must 
> not be part of fallback content that's not triggered yet).

This is definitely a bug; the fallback handling is done in a different way 
in HTML5, anyway.


> 3. For flash (non-activex-version) at least, in window modes other than 
> 'window' (like 'opaque' and 'transparent'), the plug-in won't *fully* 
> initialize (as in, it won't paint and start fetching data) until you 
> scroll the element into view. Firefox, Opera and Safari do this at 
> least, and it's actually quite nice most of the time that things work 
> that way. You can see this behavior on songza.com and blip.fm sometimes. 
> You can also see this on very tall pages with lots of flash player 
> objects attached.

That's a detail of the NPAPI, I think.


On Mon, 31 Aug 2009, Ola P. Kleiven wrote:
> 
> Opera prefers HTTP Content-Type over object type and we see some 
> compatibility issues due to this.
> 
> Examples that fail in Opera:
> 
> http://www.antena3videos.com/
> http://gamepod.hu/hir/ilyen_lett_a_terminator_salvation_es_a_bionic_comm.html

On Mon, 31 Aug 2009, Boris Zbarsky wrote:
> 
> 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.

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


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


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

Yeah, that's specced already.

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