[whatwg] instantiating display:none plugins

Robert O'Callahan robert at ocallahan.org
Tue Nov 1 16:36:44 PDT 2011


http://www.whatwg.org/specs/web-apps/current-work/#the-object-element
"The above algorithm is independent of CSS properties (including 'display',
'overflow', and 'visibility'). For example, it runs even if the element is
hidden with a 'display:none' CSS style, and does not run again if the
element's visibility changes."

Unfortunately this breaks real-world usage. The example we ran into is
documented here:
https://bugzilla.mozilla.org/show_bug.cgi?id=697651
In this case, the site has a display:none autoplay Youtube Flash video
that's not supposed to play.

I did some experiments on browser behavior, documented here:
https://bugzilla.mozilla.org/show_bug.cgi?id=697651#c19
There are some variations but no browser instantiates a plugin that's
always display:none.

I recommend that the spec be changed so that the "steps to (re)determine
what the object element represents" avoid instantiating plugins that are
display:none (or have a display:none ancestor). Dynamic changes to the
display state should queue a task that checks whether the display state of
the element has changed since the last time the "steps to (re)determine
what the object element represents" ran; if it has, it should rerun those
steps.

As far as I know, there is no need to consider any visibility state other
than display:none.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not
in us. If we confess our sins, he is faithful and just and will forgive us
our sins and purify us from all unrighteousness. If we claim we have not
sinned, we make him out to be a liar and his word is not in us." [1 John
1:8-10]


More information about the whatwg mailing list