Created attachment 385386 [details] [diff] [review] Don't load XPT files from plugin directories, rev. 1 Now that plugins can't access or implement XPCOM interfaces, we should stop loading XPT files from plugin directories.
Flash has an xpt file on my Mac OS X 10.5 machine but I can't imagine it is used for anything and either way that's not really going to fly for Gecko 1.9.2.
So this is actually a different issue than supporting XPCOM plugins. Last I looked (though it's been a while and I hope I'm wrong) Quicktime still exposed a scriptable interface for scripting Quicktime, and if we remove support for this as well I suspect more plugins will break. I'd love to see support for scripting plugins through XPCOM go as well, but I'm nowhere near as sure we're ready for that as I am about removing support for XPCOM plugins.
Well... we removed the ability for plugins to ask for arbitrary XPCOM interfaces from the browser. Did we not also remove the ability for the browser to ask for an XPCOM implementation from the plugin? I don't think we will be able to do those with out-of-process, since we're definitely not planning on remoting arbitrary XPCOM... unless we somehow do all the work on the plugin-process side and remote via the NPAPI, but that sounds amazingly horrible.
Comment on attachment 385386 [details] [diff] [review] Don't load XPT files from plugin directories, rev. 1 I think my suspicions here are unfounded, and I certainly want to see this go as much as anyone. Brandon was kind enough to install Quicktime in a system that didn't already have it installed and verify that they in fact do not ship an xpt file any more, and that's the only plugin I've seen in a *long* time do it, so I think we should just go ahead and do this now and see how it goes. And yes, supporting this out of process would be *really* nasty, of course.
And, besides, support for scripting through XPCOM has already been removed. Not sure when, but it doesn't really matter any more...