<rdar://problem/8775221>

I thought I pretty much finished this this summer. I'm not sure what's left if anything to do here.

Bug 17828 seems to be asking for the opposite behavior. But it may be old and confused.

This may also be related to bug 43655.

Hi, This is Vicky. Actually I too having the same issue. Please see the bug at https://bugs.webkit.org/show_bug.cgi?id=68072 Looking for your updates. Regards, Vicky.

hi eric!! any updates on this issue!!!. because it is a blocking issue for me. regards, vicky.

In http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-November/033732.html Roc argues that display:none plugins should not be instantiated.

See also https://bugzilla.mozilla.org/show_bug.cgi?id=697651

Yes, I believe this behavior was the original motivation for hanging them off the renderer. However, I believe that behavior can be created independent of where we hang the plugin objects. Moving them to the DOM allows either behavior. :) (Thank you for the links, btw, my impression had been was that the decision had gone the other way. Interesting to hear that this is still being discussed.)

hi folks, what will be the status if I intentionally use 'display:none' to avoid the layout space reservation when use of plug-ins. for example,keeping background music(I don't want the graphics here) for my website with flash plugin styled as 'display:none'. regards, vicky

to avoid the "layout space" you can make any object participate in flow by using "position: absolute". You can also make your plugin 1px by 1px. You can also use visibility: hidden, I believe. This bug is not related to your usecase directly, but instead is general architectural cleanup.

hi eric, yes, a web author do the layout disabling with 'width:0;height:0;' css property. but some browsers like netfront & ANT galio supports 'display:none' plugin instantiating, so web applications developed using those will not compatible with webkit. i think, w3c spec too says plugin loading shouldn't be based on css properties. regards, vicky.

HTML5 specification also requires the display:none plugin to run. http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#the-object-element Also CE browsers like ANT & Netfront & general browsers like FireFox & Opera allows display:none plugins to run.

If committee/forum members agrees I would like to start working on this issue. Please comment on this.

Additional info,. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-November/024010.html

No, the spec now says that display:none plugins should not render. See <http://dev.w3.org/html5/spec/single-page.html#the-object-element>, particularly, the <http://dev.w3.org/html5/spec/single-page.html#being-rendered> reference.

Just as a reminder: Both this: http://www.w3.org/TR/2011/WD-html5-20110525/ ...and this: http://dev.w3.org/html5/spec/single-page.html ...are not currently being updated. The current HTML spec is at: http://whatwg.org/html

If others are interested, my next steps for this bug are to figure out exactly what FF does for NPAPI plugins. Which likely means writing a (very simple) custom NPAPI plugin to test. I want to see if FF will ever instantiate a plugin first at 0x0 size and then resize. If it does (suggesting plugins would be OK with this behavior), then it would be easy for me to always request plugins at 0x0 from the DOM and then resize them once the renderers layout. However, my current suspicion is that this behavior (although convenient for our implementation) would break plugins.

To give context: Currently in WebKit, plugins are handled largely by the webkit layer. Because we don't know if something is going to be a plugin when we do the network request, we have to assume it will be, and we work hard to provide that plugin its final rendered size before making that request. Depending on that final rendered size is what makes us need to do the load from the render object, and is what causes some of the slowdown in loading/parsing any page with plugins (extra style resolves, see bug 70009), as well as some of the complexity in the code.

FireFox will not instantiate 'display:none' plugins, but if plugin is made 'display: none' after it finishes loading(via js, myplugin.style.display='none') it will never removes the plugin.(no side effect for display:none except it's graphics visibility)

>>I want to see if FF will ever instantiate a plugin first at 0x0 size and then >>resize. If it does (suggesting plugins would be OK with this behavior), then >>it would be easy for me to always request plugins at 0x0 from the DOM and then >>resize them once the renderers layout. However, my current suspicion is that >>this behavior (although convenient for our implementation) would break plugins. Eric, If I understood correctly, you are meaning like always RederObject will be created for HTMLPluginElement with size of 0x0, if it is really asked to display resize it to actual. What will be the status if <object> elements parent is styled as 'display:none' <div style='display:none'><object type='application/..'/><div> (or) <body style='display:none'> ... <object type='application/..'/> ..</body> Also what happen to plugin elements which is initially not 'display:none', but changed to 'display:none' via JavaScript.

I suggest to move NPAPI management(plugin management) from PluginView to HTMLPluginElement. PluginView can get the NPP from HTMLPluginElement upon really needed. Idea may be stupid, please comment.

Any comments, suggestions?

Plugin support has been removed from WebKit, so marking as WONTFIX.