Bug 72961 – [WK2][X11] Plugins should not be loaded into the UI process

• Component: Plug-ins
• Status: RESOLVED DUPLICATE

[Balazs Kelemen]

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.

[Anders Carlsson]

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.

[Balazs Kelemen]

Created attachment 116357 [details]
WIP patch

WIP patch for feedback. I set the r? just to not miss your attention :)

[Balazs Kelemen]

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.

[Gustavo Noronha (kov)]

Comment on attachment 116357 [details]
WIP patch

Attachment 116357 [details] did not pass gtk-ews (gtk):
Output: http://queues.webkit.org/results/10616294

[Carlos Garcia Campos]

Would it be possible to use CoreIPC for all the IPC stuff, instead of custom code and parsing stdout output?

[Balazs Kelemen]

(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.

[Balazs Kelemen]

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.

[Balazs Kelemen]

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... :)

[Simon Hausmann]

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.

[Simon Hausmann]

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.

[Balazs Kelemen]

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