WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WONTFIX
45049
MASTER: Move plugin loading out of the renderers and into the DOM
https://bugs.webkit.org/show_bug.cgi?id=45049
Summary
MASTER: Move plugin loading out of the renderers and into the DOM
Eric Seidel (no email)
Reported
Wednesday, September 1, 2010 8:40:49 PM UTC
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.
Attachments
Add attachment
proposed patch, testcase, etc.
Andy Estes
Comment 1
Thursday, December 16, 2010 12:15:19 AM UTC
<
rdar://problem/8775221
>
Eric Seidel (no email)
Comment 2
Friday, January 21, 2011 8:00:11 PM UTC
I thought I pretty much finished this this summer. I'm not sure what's left if anything to do here.
Eric Seidel (no email)
Comment 3
Wednesday, March 23, 2011 1:01:42 AM UTC
Bug 17828
seems to be asking for the opposite behavior. But it may be old and confused.
Eric Seidel (no email)
Comment 4
Wednesday, March 23, 2011 1:01:57 AM UTC
This may also be related to
bug 43655
.
ssseintr
Comment 5
Thursday, September 15, 2011 10:03:11 AM UTC
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.
ssseintr
Comment 6
Tuesday, October 11, 2011 10:04:14 AM UTC
hi eric!! any updates on this issue!!!. because it is a blocking issue for me. regards, vicky.
Simon Fraser (smfr)
Comment 7
Thursday, November 3, 2011 12:42:18 AM UTC
In
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-November/033732.html
Roc argues that display:none plugins should not be instantiated.
Simon Fraser (smfr)
Comment 8
Thursday, November 3, 2011 12:46:00 AM UTC
See also
https://bugzilla.mozilla.org/show_bug.cgi?id=697651
Eric Seidel (no email)
Comment 9
Thursday, November 3, 2011 1:05:34 AM UTC
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.)
ssseintr
Comment 10
Thursday, November 3, 2011 10:34:40 AM UTC
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
Eric Seidel (no email)
Comment 11
Thursday, November 3, 2011 6:35:10 PM UTC
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.
ssseintr
Comment 12
Friday, November 4, 2011 10:02:35 AM UTC
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.
ssseintr
Comment 13
Thursday, July 12, 2012 10:44:07 AM UTC
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.
ssseintr
Comment 14
Thursday, July 12, 2012 10:46:23 AM UTC
If committee/forum members agrees I would like to start working on this issue. Please comment on this.
ssseintr
Comment 15
Thursday, July 12, 2012 11:40:19 AM UTC
Additional info,.
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-November/024010.html
Simon Fraser (smfr)
Comment 16
Thursday, July 12, 2012 4:48:51 PM UTC
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.
Ian 'Hixie' Hickson
Comment 17
Thursday, July 12, 2012 5:59:43 PM UTC
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
Eric Seidel (no email)
Comment 18
Thursday, July 12, 2012 6:16:55 PM UTC
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.
Eric Seidel (no email)
Comment 19
Thursday, July 12, 2012 6:19:35 PM UTC
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.
ssseintr
Comment 20
Friday, July 13, 2012 10:09:09 AM UTC
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)
ssseintr
Comment 21
Friday, July 13, 2012 10:18:52 AM UTC
>>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.
ssseintr
Comment 22
Friday, July 13, 2012 10:23:24 AM UTC
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.
ssseintr
Comment 23
Thursday, July 19, 2012 9:55:45 AM UTC
Any comments, suggestions?
Alexey Proskuryakov
Comment 24
Friday, June 24, 2022 2:21:23 AM UTC
Plugin support has been removed from WebKit, so marking as WONTFIX.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug