[whatwg] instantiating display:none plugins
ian at hixie.ch
Wed Jun 13 15:46:49 PDT 2012
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg