[whatwg] instantiating display:none plugins

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. 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.

Another way to look at it is that it means that code which is running
from a timer can't ever know if the plugin is running or not. Even if
the plugin has been hidden using display:none.

A more predictable model is to terminate the plugin at the end of the
task if it has been hidden. That way all other tasks see the
application in a consistent state.

/ Jonas

Received on Tuesday, 8 May 2012 15:58:56 UTC