User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040927 Firefox/0.10 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040927 Firefox/0.10 The Null plugin is now useless, since there is a much nicer thingy when plugins are not present in Firefox. It could be removed from the default builds. Reproducible: Always Steps to Reproduce: 1. 2. 3.

It is staying for now, who knows what security hole pfs has that can be plugged using the pref to revert to the old behavior.

*** Bug 309219 has been marked as a duplicate of this bug. ***

tweaking summary, hardware/os, and component It's been about a year since this was filed, not sure if doron's concerns over the plugin finder has changed any or if there's any major bugs that force people back to nullplugin.

I'm interested in working on this bug. The track I want to take is basically to alter the makefiles such that if Firefox is being built, this isn't. Am I right in my understanding that Seamonkey is the only program depending on npnull still?

Feel free to take it

Camino might be using this too

Yes, Camino still uses the Default Plugin.plugin.

OK, talking with KaiRo on IRC about this, he kindly brought to my attention that only Camino unsets MOZ_XUL_APP, so adding a check for that should make this bug trivial to fix. Patch coming in a bit.

This is an old version of the patch from back in the CVS days. I'm just attaching it here so it doesn't get lost. I've got a few more things I need to do before I'm ready to post a review-ready patch.

Robert, I'm not really sure how to include the suite changes for this in the new Mercurial world. Any help would be appreciated.

Ryan, it's probably best to wait a few days until we have the comm-central repo up and post a separate patch against that new repo then. The patch will probably largely be identical to what it looked like against cvs (which SeaMonkey and Thunderbird will only abandon someday this upcoming week).

OK, so now that MOZ_XUL_APP is dead, did this bug just get as simple as I think it did? No toolkit-based apps need this, correct? So at this point, no checks are needed and this can just be removed outright.

Well, technically, the non-MOZ_XUL_APP-case is dead and so the flag can get removed, which means, that everything you would have made |ifndef MOZ_XUL_APP| here can just be deleted. AFAIK, the only browsers we're caring about on hg for the moment are Firefox and SeaMonkey and both are using the new plugin finder service that might not need this old null plugin any more. Of course, Camino just has not been ported to the new hg-based stuff yet, but I think we should just let old cruft die and require new apps to do things the new way. As long as we have platform-level support for finding not-yet-installed plugins, I think it's enough to have one (new) way and kill of the additional (old) way to do the same.

jst, Josh and I were talking about this on IRC and he expressed reservations about whether or not this is something we want to do or not, given that some may choose to disable PFS and would then have no alternate options available to them. He suggested we get your opinion on this. If this is destined to be a WONTFIX, I'd like to find out before I spend any more time on this. Thanks.

One other thing to keep in mind, oh browser-centrists, is that so far Thunderbird hasn't (yet) disabled plugins for 3.0, and it doesn't (yet?) use PFS.

Is disabling PFS something that's common enough to worry about here? I could see us leaving the default plugin in the tree for others (Thunderbird et al) to build and include, but I for one think we should stop shipping it in Firefox, unless there's common usage patterns relating to actually needing this plugin that I'm unaware of.

My plan was to completely remove the lines related to building this from the makefile, but maybe a suitable ifdef could be used instead? Not sure which that would be, though...

Feel free to invent one, and set it in browser/confvars.sh (and config/autoconf.mk.in).

What about a disabled by default --enable-nullplugin .mozconfig option?

No need to junk up configure and mozconfigs with an option that should only be set on the application level.

Note that since this bug was filed, the Default Plug-in was rewritten to no longer offer PFS-like services, so even if Tb is still shipping it, it performs no useful function (we've stopped shipping it in 1.9.2-based Camino builds for that exact reason and now have no embedding-friendly way of doing plug-in finding).

I don't see any reason to keep this bug open with all the work going on in bug 533891.