... and it shouldn't! Except it actually should have PDFPlugin in it. But only application plugins. <rdar://problem/14678030>
Created attachment 208382 [details] patch
Comment on attachment 208382 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=208382&action=review > Source/WebKit/mac/WebCoreSupport/WebPlatformStrategies.mm:134 > + if (Frame* frame = page->mainFrame()) { I don’t think Page::mainFrame can be null. > Source/WebKit2/WebProcess/WebCoreSupport/WebPlatformStrategies.cpp:288 > + if (Frame* frame = page->mainFrame()) { Ditto.
http://trac.webkit.org/changeset/153877
This patch seems to have caused a huge regression in the time it takes to create WebViews in GTK, according to my bisection (> 3 seconds when the java plugin is present - eek). It's now scanning all plugins when a new WebView is created, I guess it might be related to the changes to Settings::setPluginsEnabled, but haven't investigated in detail yet.
(In reply to comment #4) > This patch seems to have caused a huge regression in the time it takes to create WebViews in GTK, according to my bisection (> 3 seconds when the java plugin is present - eek). It's now scanning all plugins when a new WebView is created, I guess it might be related to the changes to Settings::setPluginsEnabled, but haven't investigated in detail yet. Hmm, we should make it only-refresh-if-you-already-have-cached-data.
(In reply to comment #5) > (In reply to comment #4) > > This patch seems to have caused a huge regression in the time it takes to create WebViews in GTK, according to my bisection (> 3 seconds when the java plugin is present - eek). It's now scanning all plugins when a new WebView is created, I guess it might be related to the changes to Settings::setPluginsEnabled, but haven't investigated in detail yet. > > Hmm, we should make it only-refresh-if-you-already-have-cached-data. Please file another bug and I'll do that.
Filed https://bugs.webkit.org/show_bug.cgi?id=119665, thanks!