| Summary: | Plug-in failed to initialize message should be called when Java fails to initialize | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Steve Falkenburg <sfalken> | ||||
| Component: | New Bugs | Assignee: | Steve Falkenburg <sfalken> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | sam | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Other | ||||||
| OS: | OS X 10.5 | ||||||
| Attachments: |
|
||||||
|
Description
Steve Falkenburg
2011-04-29 18:06:31 PDT
Created attachment 91784 [details]
Patch
Comment on attachment 91784 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=91784&action=review r=me > Source/WebKit2/WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:1257 > + const String mimeType = "application/x-java-applet"; I suggest naming this javaMimeType or appletMimeType or something like that. I don't understand this patch. This is not checking initialization, but rather whether a java plugin exists or not. Inside WebPage::createPlugin for the failure case, GetPluginPath succeeds, returning the proper path to the Java plug-in. The failure occurs when NetscapePluginModule::getOrCreate calls pluginModule->load() to initialize the plug-in. When this fails, getOrCreate returns 0, and then createPlugin returns 0. The Java applet path doesn't appear to use PluginView, so the call you added to DidFailToInitializePlugin in PluginView::initializePlugin doesn't get called in this case. I'd be open to fixing this another way - let me know. Committed r85493: <http://trac.webkit.org/changeset/85493> |