[whatwg] instantiating display:none plugins

[Ian Hickson]

On Tue, 8 May 2012, Jonas Sicking wrote:
> On Tue, May 8, 2012 at 2:06 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Wed, 2 Nov 2011, Robert O'Callahan wrote:
> >> One more thing. I added a "hide and show plugin with flush" test that 
> >> sets the plugin to display:none, causes a "layout flush" (by 
> >> requesting body.getBoundingClientRect()) and then sets the plugin 
> >> back to display:inline. On Firefox, Chrome and Opera this restarts 
> >> the plugin instance; on IE9 it doesn't. If you take out the flush, 
> >> none of the browsers restart the plugin.
> >>
> >> I think this should just be considered a browser bug. We don't want 
> >> to have to specify the timing of style and layout flushing. (We'll 
> >> fix this in Firefox shortly.)
> >
> > I just did it as a task that is queued. (This means it doesn't cause 
> > anything to happen if an alert() fires, because per spec alert() 
> > blocks the event loop. This isn't consistent with the test cases you 
> > gave. Not sure what to do about that.)
> 
> This creates a pretty racy situation.

Plugin instantiation is often racy anyway, since you have to download the 
resource to work out that it needs a plugin.


> Consider a page which reacts to a state change by showing or hiding a 
> bunch of UI by setting display:none on an element.
> 
> If two of these state changes happen in response to a timers, the 
> showing/hiding will sometimes cause the plugin to restart, sometimes 
> not. If the two timers end up in the queue before any of them fire then 
> the task to kill the plugin won't have time to run in between. If they 
> end up slightly further apart it will cause the plugin to get restarted.

For <object>, yeah. I suppose I could have the special case of the element 
obviously no longer having a plugin (e.g. it's now display:none) result in 
the plugin being killed sync with the event loop going back to step 1, but 
that's going to make the algorithm even more crazy. Are we sure we want that?

For <embed> the situation is much simpler, and so it's indeed based on the 
event loop and not a queued task.

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