[whatwg] <object> behavior

[Ben Laurie]

On Thu, Aug 13, 2009 at 10:05 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Thu, 6 Aug 2009, Andrew Oakley wrote:
>>
>> The rules in the HTML5 spec for which plugin to load for an <object> do
>> not seem to be followed by any browser, and in some cases are different
>> to behavior that is common to Opera, Webkit and Gecko (I haven't tested
>> with IE due to its lack of nsplugin support).
>>
>> Most notably HTML5 says that the Content-Type header is used in
>> preference to the type attribute, whereas the browsers seem to honour
>> the attribute in preference to the header.  (If the spec is changed to
>> match the browsers behaviour then the conditions on when to load a new
>> plugin also need to be changed.)  HTML5 also seems to prefer the type
>> attribute on <script>s rather than the Content-Type header.
>>
>> Detaching and reattaching a <object> from the document seems to make the
>> browsers destroy the object and then recreate it.  Presumably this means
>> that the DOM objects also change depending on whether or not an <object>
>> is attached to the document (haven't confirmed that this is the case).
>>
>> Changing the attributes on an <object> that is attached to the document
>> doesn't seem to "work" - Webkit does nothing, Opera seems to stop
>> scripting (presumably some kind of error), Firefox reloads the plugin in
>> some cases (even if its not the right one anymore).
>>
>> Removing an <object> from the document (browsers destroy plugin object),
>> changing the attributes and reattaching it to the document (browser
>> creates plugin object) seems to work fairly reliably across browsers.
>>
>> In effect it seems that browsers use the attributes that were on the
>> <object> when it was attached to the document, and do not respond to
>> changes in the attributes.
>>
>> The test cases I used are available at
>> http://ado.is-a-geek.net/~andrew/pluginstest.tar.bz2 (sorry they are
>> somewhat linux based due to the platform specific plugins).
>>
>> In summary I have a few questions related to <object>s:
>> - Should the type attribute take precedence over the Content-Type header?
>
> No, I believe what the spec says here is the preferred behaviour. Unless
> this is incompatible with legacy content, we should try to move towards
> this behaviour.

I realise this is only one of dozens of ways that HTML is unfriendly
to security, but, well, this seems like a bad idea - if the page
thinks it is embedding, say, some flash, it seems like a pretty bad
idea to allow the (possibly untrusted) site providing the "flash" to
run whatever it wants in its place.

>
>
>> - Should <object>s exist all the time whether they are attached to the
>> document or not?
>
> Assuming you mean the plugins, as opposed to the elements themselves, then
> the way the spec is written, the plugin instantiates regardless of whether
> it is in the document or not.
>
>
>> - Should changing the attributes change the plugin, or should we just
>> use the attributes when the object was attached to the document?
>
> I'm pretty sure that for compatibility with legacy content, only the type,
> data, and classid attributes would cause the plugin to be restarted if
> changed.
>
>
> On Thu, 6 Aug 2009, Boris Zbarsky wrote:
>>
>> The exact Gecko behavior is the following.
>>
>> 1)  If the header type is application/octet-stream and the type
>>     attribute was set to something that parsed as a MIME type, use the
>>     type attribute's type.
>> 2)  If the type attribute was set to something that parsed as a MIME
>>     type, and if that type would be handled by a plug-in (that is, we
>>     have a plug-in to handle it, and have no other method for handling
>>     it), then use the type attribute's type instead of the header type.
>> 3)  In all other cases the header type is used.
>
> Step 2 above isn't what the spec says. The rest is, more or less.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>