261751 - Null plugin could be removed from the default builds (nullplugin, npnul32.dll)

Status: RESOLVED DUPLICATE of bug 533891

(Firefox Build System :: General, enhancement)

Description

[Mike Hommey [:glandium]]

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.

Comment 1

[Doron Rosenberg (IBM)]

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.

Comment 2

[logan]

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

Comment 3

[logan]

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.

Comment 5

[Ryan VanderMeulen [:RyanVM]]

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?

Comment 6

[Doron Rosenberg (IBM)]

Feel free to take it

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

Camino might be using this too

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Yes, Camino still uses the Default Plugin.plugin.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Attachment: v0.1

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.

Comment 12

[Ryan VanderMeulen [:RyanVM]]

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

Comment 13

[Robert Kaiser]

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

Comment 14

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 15

[Robert Kaiser]

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.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 17

[Phil Ringnalda (:philor)]

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.

Comment 18

[Johnny Stenback (:jst)]

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.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

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

Comment 20

[(not currently active) Ted Mielczarek]

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

Comment 21

[Ryan VanderMeulen [:RyanVM]]

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

Comment 22

[(not currently active) Ted Mielczarek]

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

Comment 23

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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

Comment 24

[Ryan VanderMeulen [:RyanVM]]

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