Bug 164102

Summary: [Unix] PluginProcessProxy::scanPlugin should not parse stdout
Product: WebKit Reporter: Michael Catanzaro <mcatanzaro>
Component: Plug-insAssignee: 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
Reported 2016-10-27 19:01:04 PDT
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
Carlos Garcia Campos
Comment 1 2016-11-02 07:55:12 PDT
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
Comment 2 2022-07-01 11:35:52 PDT
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.
Note You need to log in before you can comment on or make changes to this bug.