For the gtk2 plugin support in a gtk3 build we need to build two libxul libraries.

Mike, can you look at it please? I'm sure more parts can be removed (at least those in #ifdefs) but it involves code changes.

Comment on attachment 820306 [details] [diff] [review] libxul_gtk2 patch Review of attachment 820306 [details] [diff] [review]: ----------------------------------------------------------------- This is going to be a maintenance pita. As in, you can be pretty sure toolkit/library/gtk2/Makefile.in will be outdated very quickly. See what we do for gtest, which is awfully hacky, but avoids that maintenance hell. With that being said, I'm still not convinced by the whole libxul_gtk2.so thing. I'd rather see this discussed in e.g. dev-platform (and in fact, i kind of started some discussion in https://groups.google.com/d/msg/mozilla.dev.platform/XMfXfxjSDpo/GlcFKSeeRfYJ , but that should probably be its own thread, also mentioning what you're trying to do here)

It's possible to remove libxul from plugin-container. It would be something like nspluginwrapper (http://nspluginwrapper.org/) which is a small (~150KB) wrapper library which translates NPAPI calls over RPC. Actually nspluginwrapper already works with the Gtk3 Firefox so it can be used instead of the plugin-container and we're going to deploy such solution in Fedora if mozilla does not provide gtk2 plugin-container.

Please don't run nspluginwrapper in the browser process, as I suspect plugin calls during windowless drawing would create security problems.

Karl, can you be more specific about the nspluginwrapper security issues?

See bug 552512. A simple out-of-process plugin implementation makes such situations likely as it will run an event loop in the plugin process that allows the plugin to call into the browser process at the next opportunity, which might be during the browser asking the plugin to paint. Running nspluginwrapper out of process will avoid such issues, but there have been other non-security sensitive issues with nspluginwrapper that I don't recall right now.

I don't quite understand what do you mean by running nspluginwrapper "in the browser process" and "out of process". The nspluginwrapper package has two parts - one is just a NPAPI plugin which sends NPAPI calls to its counterpart via. RPC. The second one is run in separate process, launches the target NPAPI plugin and receives NPAPI via. RPC from/to the browser. So nspluginwrapper can run plugins with different architecture (i386/x86_64) and different libraries. I guess it's the same model as Firefox uses for plugin-container, right?

nspluginwrapper is similar to the RPC OOP plugin model that Firefox uses, but AFAIK doesn't handle painting in the special way necessary to avert security problems. Provided the NPAPI plugin part of nspluginwrapper runs in a process started by plugin-container, the browser/plugin-container communication will take care of bug 552512. That is what I mean in comment 4.

(In reply to Mike Hommey [:glandium] from comment #2) > This is going to be a maintenance pita. As in, you can be pretty sure > toolkit/library/gtk2/Makefile.in will be outdated very quickly. See what we > do for gtest, which is awfully hacky, but avoids that maintenance hell. > > With that being said, I'm still not convinced by the whole libxul_gtk2.so > thing. I'd rather see this discussed in e.g. dev-platform (and in fact, i > kind of started some discussion in > https://groups.google.com/d/msg/mozilla.dev.platform/XMfXfxjSDpo/ > GlcFKSeeRfYJ , but that should probably be its own thread, also mentioning > what you're trying to do here) I believe the libxul_gtk2.so is a realistic approach. The NPAPI plugins are going to die anyway (frankly the only reason for it is a flash plugin) so I don't want to put much effort to it - like a minimized gtk2 plugin container or so. Mike, would you accept a solution similar to 32-bit MacOS build? To build FF twice, one for gtk2, one for gtk3?

Closing as per bug 929408. The one-pass build seems to be too difficult to maintain.

Just as a side note, for interested people, we are implementing an alternative to this solution, implying un-linking plugin-container from libxul and adding another shared object in order to let plugin-container build for GTK2 or GTK3 depending on our plugin needs. That new effort is being tracked in bug 624422