[whatwg] instantiating display:none plugins

On Wed, 2 Nov 2011, Robert O'Callahan wrote:
>
> 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.

Fixed.


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

For consistency with other code I've also made visibility:collapse for 
boxes in the table model (i.e. when 'collapse' collapses rather than just 
acting like 'hidden') do the same thing.


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


On Wed, 2 Nov 2011, Michael A. Puls II wrote:
> 
> These threads (at least) have the discussion on <object> and the css 
> display property:
> 
> <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-September/thread.html#22563> 
> <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-October/thread.html#23641> 
> <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-November/024010.html> 
> <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/thread.html#24434>
> 
> Boris mention that it was considered a bug by Mozilla that <object> is 
> affected by the display property (including display: none). Hixie agreed 
> and said that the author is expected to use JS and not create and append 
> the <object> until it's expected to be instantiated. I agreed with that, 
> but also suggested a load-on-demand attribute for <object> for authors 
> that want to create the object with parsed markup and just defer 
> instantiation where just removing the attribute with JS would cause it 
> to instantiate. That wasn't received well though.
> 
> Also, the display property never really affected <object> in Opera 
> except for display: none. But, that's was changed in Opera for images ( 
> <img> and <object> I think and maybe everything) I think. Opera users 
> are pissed by the change though because users used display: none for 
> ad-blocking (including blocking the resource fetching) and Opera didn't 
> provide an alternative when making the change. See 
> <http://my.opera.com/community/forums/topic.dml?id=1112972> and 
> <http://my.opera.com/community/forums/topic.dml?id=972092>. But, that's 
> not web-compat-related and not necessarily about plug-ins, but the users 
> in those threads want the old display: none behavior back.
> 
> I still think display: none shouldn't affect <object> instantiation and 
> if there needs to be a solution, it should be an attribute and we should 
> evangelize and get any problem sites fixed (by using the attribute for 
> example).

Unfortunately we seem to be constrainted by legacy.


On Thu, 3 Nov 2011, Boris Zbarsky wrote:
> 
> I think having an explicit instantiation trigger that works even if 
> display:none would be a reasonable thing to do.

I haven't added this yet, but if there's a compelling need we can always 
consider adding it.

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

Received on Tuesday, 8 May 2012 14:06:52 UTC