[whatwg] <object> behavior

On Thu, 3 Sep 2009, Henri Sivonen wrote:
> On Sep 3, 2009, at 00:39, Ian Hickson wrote:
> > > 
> > > 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.
> 
> Why is this a bug in browser behavior as opposed a bug in the spec?

Because as far as I can tell there's no reason a plugin's behaviour should 
depend on whether it is visible or not. And because Boris said so. :-)


On Tue, 15 Sep 2009, Boris Zbarsky wrote:
> Ian Hickson wrote:
> > > Since the whole point of text/plain sniffing is a workaround around 
> > > a known issue where content is reliably mis-marked as text/plain, 
> > > and since in this case there is a source of MIME information that's 
> > > more reliable than that, it's not clear to me why we want to 
> > > continue sniffing.
> > > 
> > > Of course if there is no @type there is no problem; I'm specifically 
> > > concerned about the @type="text/plain" case here.
> > 
> > What exactly are you proposing here?
> > 
> >  - Always honour type="" if it's a UA-supported type, ignoring server-
> > provided content-type?
> >  - Always honour type="" without sniffing if it matches the server-
> > provided content-type, even if normally that type would be sniffed?
> >  - Just honour type="text/plain" regardless of the server type, but for
> >    other UA-supported type=""s, use the server type?
> 
> My suggestion is to only perform text/plain "is this text or binary" 
> sniffing where it belongs: on the HTTP level; since it's a workaround 
> for a particular HTTP server bug.  It shouldn't affect other type 
> metadata.

Ah, I see. So your concern is with the case where <object 
type="text/plain" data="x"> is specified, if the user has a plugin that 
supports text/plain, and "x" contains data that is invalid in text/plain 
content. In this case, you would like the plugin to be invoked, even if 
sniffing the content would find that it was in fact some other format 
(e.g. flash).

That seems reasonable. I've changed the spec to prevent sniffing in this 
case.


> Perform the sniffing such that it detects as either text/plain or 
> application/octet-stream.
> 
> Then if it's application/octet-stream we'll end up using the @type. 
> Though see below on other sniffing issues.
> 
> This does fail to sniff text/plain as the various "non-scriptable" 
> types, but I question how desirable that is anyway, honestly.  If we 
> want to preserve this property without clobbering @type="text/plain" 
> then I need to think a bit more about how to specify the behavior here.

I'm a bit concerned about introducing even more sniffing algorithms (which 
this effectively is) rather than just reusing the existing ones. Why would 
we not want text/plain to be treated more or less the same here as in an 
<iframe>?


> > > My concern about text/plain data being sniffed as text/html by your 
> > > current algorithm (even with the changes you've made) seems to 
> > > remain unaddressed.
> > 
> > I thought I had. Can you walk me through how anything labeled 
> > text/plain could get sniffed as text/html with the new text?
> 
> Hmm.  Assume the type attribute is not set and HTML data is sent as 
> text/plain and contains a "binary byte" in the first 512 bytes (can just 
> stick it in the <title> or something).  Also assume no plug-in claims to 
> support the URI's file extension.
> 
> At step 3, the resource type is set to text/plain.
> 
> At step 4, the resource type is sniffed as application/octet-stream, since
> text/html is marked as scriptable in [MIMESNIFFF].
> 
> At step 5, there is no @type, and the resource type is
> application/octet-stream, so the resource type is changed to unknown.
> 
> At step 6, nothing changes since there is no plug-in supporting the URI's file
> extension.
> 
> At step 7, the resource type is "unknown", so it is changed to the "sniffed
> type of the resource".

Ooh, yes. good catch. Hm.

I've forced it to text/plain in this case. (To be precise, I've changed 
the algorithm slightly so that you only do the sniffing once -- either the 
text-v-binary sniff, or the full sniff, and if the text-v-binary sniff 
just says application/octet-stream but the extension doesn't help, then I 
convert it back to text/plain.)

Note that in practice this makes no difference, unless there is a plugin 
that supports text/html or text/plain. If there is no such plugin, then 
the end result is that a browsing context is created, and the resource is 
treated as normal (including sniffing it again properly).


On Sun, 20 Sep 2009, Michael A. Puls II wrote:
> 
> O.K., so put simply, HTML5 should explicitly mention that the css 
> display property for <object>, <embed> (and <applet> in the handling 
> section) has absolutely no effect on plug-in instantiation and 
> destroying and has absolutely no effect on @src and @data resource 
> fetching.
> 
> HTML5 could also be extra clear by example that display: none doesn't 
> destroy, or prevent the creation of, the plug-in instance and that 
> changing the display value doesn't destroy the instance.
> 
> Lastly, HTML5 could briefly mention that what the plug-in does when its 
> window/area is not displayed because of display: none, is plug-in and 
> plug-in API dependent.

I've added a note to this effect.


There was also some discussion of what to do about preventing a plugin 
instantiating. It seems to me that authors can do that by not creating the 
<object> element ahead of time.

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

Received on Friday, 16 October 2009 02:28:46 UTC