Bug 45049 - MASTER: Move plugin loading out of the renderers and into the DOM
Summary: MASTER: Move plugin loading out of the renderers and into the DOM
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Plug-ins (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on: 45007 45054 45055 45058 45065 50312
Blocks: 27775 39286 56575 68072 70009 24346 43655
  Show dependency treegraph
 
Reported: 2010-09-01 12:40 PDT by Eric Seidel (no email)
Modified: 2012-10-23 13:06 PDT (History)
17 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2010-09-01 12:40:49 PDT
Move plugin loading out of the renderers and into the DOM

This will allow for all sorts of cleanup.  Including possibly removing lazyAttach() support, and implementing always-load-even-if-display-none support as requested in bug 27775 and hacked in in bug 24215.

This will take a bunch of changes to accomplish. I'll relate them all here.
Comment 1 Andy Estes 2010-12-15 16:15:19 PST
<rdar://problem/8775221>
Comment 2 Eric Seidel (no email) 2011-01-21 12:00:11 PST
I thought I pretty much finished this this summer.  I'm not sure what's left if anything to do here.
Comment 3 Eric Seidel (no email) 2011-03-22 17:01:42 PDT
Bug 17828 seems to be asking for the opposite behavior.  But it may be old and confused.
Comment 4 Eric Seidel (no email) 2011-03-22 17:01:57 PDT
This may also be related to bug 43655.
Comment 5 ssseintr 2011-09-15 02:03:11 PDT
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.
Comment 6 ssseintr 2011-10-11 02:04:14 PDT
hi eric!!

any updates on this issue!!!. because it is a blocking issue for me.

regards,
vicky.
Comment 7 Simon Fraser (smfr) 2011-11-02 16:42:18 PDT
In http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-November/033732.html Roc argues that display:none plugins should not be instantiated.
Comment 8 Simon Fraser (smfr) 2011-11-02 16:46:00 PDT
See also https://bugzilla.mozilla.org/show_bug.cgi?id=697651
Comment 9 Eric Seidel (no email) 2011-11-02 17:05:34 PDT
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.)
Comment 10 ssseintr 2011-11-03 02:34:40 PDT
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
Comment 11 Eric Seidel (no email) 2011-11-03 10:35:10 PDT
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.
Comment 12 ssseintr 2011-11-04 02:02:35 PDT
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.
Comment 13 ssseintr 2012-07-12 02:44:07 PDT
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.
Comment 14 ssseintr 2012-07-12 02:46:23 PDT
If committee/forum members agrees I would like to start working on this issue. Please comment on this.
Comment 16 Simon Fraser (smfr) 2012-07-12 08:48:51 PDT
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.
Comment 17 Ian 'Hixie' Hickson 2012-07-12 09:59:43 PDT
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
Comment 18 Eric Seidel (no email) 2012-07-12 10:16:55 PDT
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.
Comment 19 Eric Seidel (no email) 2012-07-12 10:19:35 PDT
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.
Comment 20 ssseintr 2012-07-13 02:09:09 PDT
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)
Comment 21 ssseintr 2012-07-13 02:18:52 PDT
>>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.
Comment 22 ssseintr 2012-07-13 02:23:24 PDT
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.
Comment 23 ssseintr 2012-07-19 01:55:45 PDT
Any comments, suggestions?