On Thu, Aug 13, 2009 at 10:05 PM, Ian Hickson <i...@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. `._.-(,_..'--(,_..'`-.;.' >