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.
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.
Created attachment 116357 [details] WIP patch WIP patch for feedback. I set the r? just to not miss your attention :)
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 on attachment 116357 [details] WIP patch Attachment 116357 [details] did not pass gtk-ews (gtk): Output: http://queues.webkit.org/results/10616294
Would it be possible to use CoreIPC for all the IPC stuff, instead of custom code and parsing stdout output?
(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.
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.
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... :)
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 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.
*** This bug has been marked as a duplicate of bug 72121 ***