Bug 164102
Summary: | [Unix] PluginProcessProxy::scanPlugin should not parse stdout | ||
---|---|---|---|
Product: | WebKit | Reporter: | Michael Catanzaro <mcatanzaro> |
Component: | Plug-ins | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED WONTFIX | ||
Severity: | Normal | CC: | ap, bugs-noreply, cgarcia, mcatanzaro |
Priority: | P2 | ||
Version: | Other | ||
Hardware: | PC | ||
OS: | Linux | ||
See Also: | https://bugzilla.gnome.org/show_bug.cgi?id=763568 |
Michael Catanzaro
PluginProcessProxy::scanPlugin spawns a WebKitPluginProcess and parses its stdout to populate a RawPluginMetaData object. It leads to very bad results if plugins print anything. For example, the name field for the GNOME Shell browser plugin gets set to "(WebKitPluginProcess:26462): GnomeShellBrowserPlugin-DEBUG: plugin loaded" because it prints a debug statement. The mimeDescription field gets set to "this plugin provides integration with gnome shell for live extension enabling and disabling. it can be used only by extensions.gnome.org" rather than a list of MIME types. This is too fragile.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Carlos Garcia Campos
This is weird, we spawn the process with G_SPAWN_STDERR_TO_DEV_NULL to ensure we don't end up with stderr in stdout, and then in the plugin process after the plugin is loaded and before calling NP_GetValue with NPPVpluginNameString and NPPVpluginDescriptionString and then NP_GetMIMEDescription we redirect stdout to devnull to avoid this from happening. "plugin loaded" message is called from NP_Initialize, so that should have been redirected to /dev/null. Unless StdoutDevNullRedirector is not really working, or we need some flush before deleting StdoutDevNullRedirector.
Alexey Proskuryakov
Mass closing plug-in bugs, as plug-in support has been removed from WebKit.
Please comment and/or reopen if this still affects WebKit in some way.