Repro crash with many Google image search results Steps to reproduce: 1. Click the following G.I.S. link: http://www.google.com/imgres?imgurl=http://www.jetsetreport.com/admin2/photos/1_2.jpg&imgrefurl=http://www.jetsetreport.com/nightlife.php%3FarticleId%3D273&h=400&w=400&sz=142&tbnid=ktJvcGmr5X9wdM:&tbnh=124&tbnw=124&prev=/images%3Fq%3Dpacha%2Bmarrakech&usg=__10-y4cSC3cRK05lXmqXoBIrT8lo=&ei=ksLyS7mNB4vysQPtzoyYDA&sa=X&oi=image_result&resnum=8&ct=image&ved=0CDAQ9QEwBw 2. Crash! > 1 com.apple.WebKit 0x7fffa6e2ce53 WebFrameLoaderClient::redirectDataToPlugin(WebCore::Widget*) + 0x37 2 com.apple.WebCore 0x7fffacf3d46b WebCore::PluginTokenizer::writeRawData(char const*, int) + 0x7b 3 com.apple.WebCore 0x7fffacbee2a2 WebCore::FrameLoader::write(char const*, int, bool) + 0x11c 4 com.apple.WebCore 0x7fffacc266b1 WebCore::FrameLoader::addData(char const*, int) + 0xb 5 com.apple.WebKit 0x7fffa6de59d7 -[WebFrame(WebInternal) _addData:] + 0xa7 6 com.apple.WebKit 0x7fffa6de5000 -[WebFrame(WebInternal) _receivedData:textEncodingName:] + 0x100 7 com.apple.WebKit 0x7fffa6de4d41 -[WebHTMLRepresentation receivedData:withDataSource:] + 0x91 8 com.apple.WebKit 0x7fffa6de4c10 -[WebDataSource(WebInternal) _receivedData:] + 0x50 9 com.apple.WebKit 0x7fffa6de4b97 WebFrameLoaderClient::committedLoad(WebCore::DocumentLoader*, char const*, int) + 0x69 10 com.apple.WebCore 0x7fffacc1ee60 WebCore::FrameLoader::committedLoad(WebCore::DocumentLoader*, char const*, int) + 0x44 11 com.apple.WebCore 0x7fffacc1ca30 WebCore::DocumentLoader::receivedData(char const*, int) + 0x90 12 com.apple.WebCore 0x7fffacc1c999 WebCore::FrameLoader::receivedData(char const*, int) + 0x25 13 com.apple.WebCore 0x7fffacc1c879 WebCore::MainResourceLoader::addData(char const*, int, bool) + 0x37 14 com.apple.WebCore 0x7fffacc1c7d6 WebCore::ResourceLoader::didReceiveData(char const*, int, long long, bool) + 0x38 15 com.apple.WebCore 0x7fffacc1c740 WebCore::MainResourceLoader::didReceiveData(char const*, int, long long, bool) + 0x262 16 com.apple.WebCore 0x7fffacc1c4db WebCore::ResourceLoader::didReceiveData(WebCore::ResourceHandle*, char const*, int, int) + 0x1b 17 com.apple.WebCore 0x7fffacc1c4b1 -[WebCoreResourceHandleAsDelegate connection:didReceiveData:lengthReceived:] + 0x91 ... The Widget is null. The PluginDocument has an embed element, that has a RenderWidget, but it didn't actually create a widget. The reason why is due to sandboxing, which g.i.s. uses when iframing the source page for an image result. In FrameLoader::requestObject(): ... bool useFallback; if (shouldUsePlugin(completedURL, mimeType, renderer->hasFallbackContent(), useFallback)) { Settings* settings = m_frame->settings(); if ((!allowPlugins(AboutToInstantiatePlugin) // Application plugins are plugins implemented by the user agent, for example Qt plugins, // as opposed to third-party code such as flash. The user agent decides whether or not they are // permitted, rather than WebKit. && !MIMETypeRegistry::isApplicationPluginMIMEType(mimeType)) || (!settings->isJavaEnabled() && MIMETypeRegistry::isJavaAppletMIMEType(mimeType))) return false; if (isDocumentSandboxed(m_frame, SandboxPlugins)) return false; ... Later, the plugin data is being fed to this nonexistent Widget. In radar as <rdar://problem/7685669>
This will only happen on sites that use an <iframe> but set the src to a plugin. <iframe src="foo.swf">, for example. I have a patch coming up that will replace the plugin document with a sink document that just throws the data away and renders nothing. In a future world, we should detect the case of "would we use a plugin document for this?" earlier and cut off the load, and do so as early as possible after we know the mime type.
Filed https://bugs.webkit.org/show_bug.cgi?id=39330 to followup and make this more perfect later (patch is coming up shortly)
Created attachment 56422 [details] Proposed fix + test Replace any PluginDocuments that violate sandboxing with a new document/tokenizer that acts as a data sink, just ignoring the resource data. This prevents the crash and prevents the plugin binaries from loading.
Comment on attachment 56422 [details] Proposed fix + test r=me
http://trac.webkit.org/changeset/59719