[whatwg] <object> behavior
benl at google.com
Fri Oct 16 13:12:22 PDT 2009
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
> 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg