[whatwg] <object> behavior

[Michael A. Puls II]

On Fri, 18 Sep 2009 08:18:04 -0400, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 9/18/09 4:57 AM, Michael A. Puls II wrote:
>>> We (Gecko) consider it a bug that a display:none <object> in a
>>> document doesn't instantiate the plug-in.
>>
>> BTW, what is the reason for considering it a bug?
>
> Because the current behavior of having the plug-in instantiation handled  
> by effectively the CSS box means that any time that box changes (e.g.  
> when you switch from display:block to display:inline) the plug-in is  
> reinstantiated.  Worse yet, it can be reinstantiated due to other  
> unrelated DOM mutations, depending on what effect they have on CSS  
> boxes.  That's pretty undesirable.

O.K.

>> {
>> visibility: hidden;
>> width: 0;
>> height: 0;
>> padding: 0;
>> margin: 0;
>> line-height: 0;
>> font-size: 0
>> border: 0
>> }
>>
>> is insufficient and or a pain when you want to load a plug-in but
>> completely hide it so it's as if it's not there layout-wise?
>
> That CSS is a pain _and_ insufficient, depending on context.  For  
> example, consider the situation when the parent of that <object> is  
> display:table-row.

O.K.

>> Do you know of any sites that would work better if the bug was fixed?
>
> Looking at https://bugzilla.mozilla.org/show_bug.cgi?id=90268 and its  
> duplicates and depenencies, at least:
>
> http://reviewkaki.blogspot.com/
> http://www.youtube.com/
> Any site using Dojo 1.0.0 TabContainer with plug-ins in the tabs
>
> and a number of cases where web site developers ended up having to work  
> around this behavior or reported it without mentioning which site they  
> were working on.
>
> Funny enough, people want to be able to set paused Flash videos to  
> display:none and back without losing their position in the video....

Thanks for this.

>> Know any sites that'd break or begin to unexpectedly load a bunch of
>> <object>'s that weren't meant to be loaded yet?
>
> Not sure, but since as far as I now Opera and IE both keep the plug-in  
> alive when the CSS box goes away, as far as I can tell, I'm rather  
> hoping there won't be many.  Not sure what webkit's behavior is here.  
> Want to test?

Attaching a test.

Results:

O.K., if the initial display state of the <object> is none, then Opera,  
Firefox, Safari and IE don't load the plug-in.

Then, once you set the display to inline, inline-block, block or table for  
example, the <object> will display and fire up the plugin.

Then:

In Opera:

If you switch the display to none, it destroys the plug-in instance.  
Setting the display to something else again doesn't restore the previous  
plug-in instance. It creates a new one that starts playing from the  
beginning.

However, switching between inline, inline-block, block and table just  
changes the display and the plug-in keeps playing the file.

In Safari:

Setting to a display of none destroys the plug-in instance like Opera.

However, switching between inline, inline-block, block and table destroys  
the current instance and creates a new one each time, which causes the  
plug-in to start playing from the beginning.

In IE:

Once the <object> is shown for the first time, you can set its display to  
none, inline, inline-block, block and table and it will just change the  
display while letting the plug-in keep playing. This means that setting  
the display to none won't destroy the plug-in instance like it does in  
other browsers.

In Firefox:

Same as Safari.

So, is it IE's behavior we want here, or Opera's? The difference being  
that display: none can kill an already-started plug-in in Opera (and other  
browsers right now), while in IE, I think you have to actually remove the  
<object> from the document to get rid of it, or perhaps change its  
@type/@classid etc.

Judging by the use-case you mentioned above, IE's exact behavior in these  
situations is what's desired?

Or, are you saying that the <object> should also load the plug-in even  
when its display is set to none by default?

Just want to make sure what's desired, if HTML5 matches it and what each  
browser has to change.

>> If the change is trivial, maybe someone can throw up an experimental FF
>> or webkit binary with the fix.
>
> If the change were trivial it would have been done back when the bug was  
> filed, in 2001.

O.K. Thanks (thought maybe it was a political issue for why it wasn't  
fixed yet instead.)

-- 
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090918/32e051a3/attachment-0002.html>