Bug 72961 - [WK2][X11] Plugins should not be loaded into the UI process
Summary: [WK2][X11] Plugins should not be loaded into the UI process
Status: RESOLVED DUPLICATE of bug 72121
Alias: None
Product: WebKit
Classification: Unclassified
Component: Plug-ins (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2011-11-22 08:25 PST by Balazs Kelemen
Modified: 2012-02-28 02:30 PST (History)
9 users (show)

See Also:

WIP patch (16.66 KB, patch)
2011-11-23 07:40 PST, Balazs Kelemen
hausmann: review-
kbalazs: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Balazs Kelemen 2011-11-22 08:25:42 PST
Currently we load plugins in the UI process to get the mime description. This negates the security benefit of the multi-process architecture and it causing problems with Qt5 because some plugins rely on Qt4 and for some strange reason Qt4 and Qt5 does not like each other in a process (which result in a crash at dlopen when loading the plugin). To solve this I am planning to introduce a scanner process for querying the plugin.
Comment 1 Anders Carlsson 2011-11-22 12:39:14 PST
We do something similar for the Mac port where we launch the plug-in process when plug-ins need to write an updated MIME type plist file, see PluginProcessProxy::createPropertyListFile for more details.
Comment 2 Balazs Kelemen 2011-11-23 07:40:46 PST
Created attachment 116357 [details]
WIP patch

WIP patch for feedback. I set the r? just to not miss your attention :)
Comment 3 Balazs Kelemen 2011-11-23 07:41:15 PST
I choose to introduce a dedicated executable for the task so this solution does not depend on the plugin process. The work-in-progress patch is missing gtk build parts - I need to learn that.
Comment 4 Gustavo Noronha (kov) 2011-11-23 07:45:25 PST
Comment on attachment 116357 [details]
WIP patch

Attachment 116357 [details] did not pass gtk-ews (gtk):
Output: http://queues.webkit.org/results/10616294
Comment 5 Carlos Garcia Campos 2011-11-23 09:21:38 PST
Would it be possible to use CoreIPC for all the IPC stuff, instead of custom code and parsing stdout output?
Comment 6 Balazs Kelemen 2011-11-23 10:06:52 PST
(In reply to comment #5)
> Would it be possible to use CoreIPC for all the IPC stuff, instead of custom code and parsing stdout output?

I was also thinking about that. Our case is a bit trickier than the property list file thing what Andresca suggested. In that case there is no need to communicate with the plugin porcess but it just being launched and it creates the file. In our situation we are in the middle of a sync message from web process to ui process and we need to reply that. So we would have to launch the process and wait for a sync message from it and then reply to the web process. Maybe this could be done with a timer based approach (an inner run loop until got the message or a timout expires), I'm not sure. So basically it is not trivial with CoreIPC - that's why I found adding a bit of custom IPC easier.
Comment 7 Balazs Kelemen 2011-11-23 12:49:58 PST
After a bit investigation I realized that the situation is the same when the plugin process is launched so my concerns seems to be invalid.
Comment 8 Balazs Kelemen 2011-11-24 01:59:32 PST
Ok, finally I remember what was in my mind when I started working on this. I though we need to avoid linking against qt (because of the incompatibility of qt4 plugins and qt5) so I decided to implement a self-contained program for the task. But we will have the same issues with the plugin process so the plan is to reuse the gtk plugin process. I'm going to investigate in that. If that is possible than we don't need this patch but we can handle this in the plugin process. However I'm a bit afraid that the dependencies of webcore are too deep and it's not suitable to rebuild the word with gtk just for the plugin process.

I promise I stop brain dumping form now... :)
Comment 9 Simon Hausmann 2011-11-24 07:21:42 PST
I would also prefer an approach similar to what's done on Mac OS X. A file on the disk has two advantages:

    1) It doesn't require hand-crafted IPC altogether.
    2) It can even serve as a cache, making it possible to avoid running the scanning process unless we can determine that we need to update the cache.
Comment 10 Simon Hausmann 2011-11-24 07:24:49 PST
Comment on attachment 116357 [details]
WIP patch

Taking this out of the review queue, as I'm pretty sure we don't want the hand-crafted IPC approach. Like I said in the previous comment, I'd prefer a non-IPC approach with a disk-cache. See also bug #43179 for an alternate approach of using an sqlite database as cache.
Comment 11 Balazs Kelemen 2012-02-28 02:30:35 PST

*** This bug has been marked as a duplicate of bug 72121 ***