110660 - MOZ_PLUGIN_PATH not added to plugins search paths

Status: VERIFIED FIXED

(Core :: XPCOM, defect)

Description

[Conrad Carlen (not reading bugmail)]

This came from bug 77231.

Working on 2 patches because there are two ways to go about it:

1) for NS_APP_PLUGINS_DIR, use MOZ_PLUGIN_PATH if defined, else use bin/plugins.
That's what used to happen.
2) for NS_APP_PLUGINS_DIR_LIST, add MOZ_PLUGIN_PATH if defined *and*
bin/plugins. Then we could have both - bin/plugins for standard plugins
installed with app and MOZ_PLUGIN_PATH for user added extras.

Unix people can decide which they want.

Comment 1

[Conrad Carlen (not reading bugmail)]

Attachment: patch for option #1

This patch is for option #1 which is the old behavior.

Comment 2

[Conrad Carlen (not reading bugmail)]

Attachment: patch for option #2

This allows us to have both dirs in the search path.

Comment 3

[Conrad Carlen (not reading bugmail)]

dmose, blizzard - can you take your pick of which patch and r/sr=? 

Comment 4

[Peter Lubczynski]

If probably wouldn't hurt (and maybe even be helpful) if the environment
variable was XP?

Comment 5

[Conrad Carlen (not reading bugmail)]

True. It would work probably everywhere but Mac.

Comment 6

[Conrad Carlen (not reading bugmail)]

  Now I think the env var should just be Unix. I don't really like the idea of
having it in the first place but, since people have been using it on Unix, it
needs to be maintained.
  Is the reason that it exists is so that people without admin privleges could
install plugins in some directory of theirs and set the var to point to it? I
think a better approach is to do what's done on OS X: scan the "Internet
Plugins" dir in the user domain, followed by the "Internet Plugins" dir in the
global domain. Of course, OS X provides these dirs and a way to find them. On
other OSs, we'd have to do it by hand.
  Sound right? In the meanwhile, I think we should go with option #2 patch as-is.

Comment 7

[Peter Lubczynski]

Comment on attachment 58286 [details] [diff] [review]
patch for option #2

yes, it's the only way users can override admin plugins right now. Since not
every platform has an OS global user location for plugins, maybe we should have
mozilla profile-based plugins? Anyway, I still think an environment varible for
multi-user NT system could be useful and maybe even later in Mach-O. r=peterl

Comment 8

[Conrad Carlen (not reading bugmail)]

Attachment: new patch for option #2

Same thing as attachment 58286 [details] [diff] [review] except the env var is used everywhere except
Mac.

Comment 9

[Conrad Carlen (not reading bugmail)]

Peter - can you give a fresh r= on new patch?
jband - can you sr?

Comment 10

[Peter Lubczynski]

Comment on attachment 58575 [details] [diff] [review]
new patch for option #2

r=peterl

Comment 11

[John Bandhauer]

Comment on attachment 58575 [details] [diff] [review]
new patch for option #2

sr=jband.
I think I'm OK with the enumerator change. You do penalize anyone who makes the
mistake of just calling GetNext until it fails. We know this is not the right
thing to do, but it would work in most implementations, but not here.

Comment 12

[Conrad Carlen (not reading bugmail)]

Checked in.

Comment 13

[Conrad Carlen (not reading bugmail)]

Shrirang - can you verify this one so I can get it on 0.9.4 with bug 77231?
Along with this, bug 77231 should be verifiable on Unix now too.

Comment 14

[shrirang khanzode]

marking verif, confirmed with several people(devp/ moz qa) that this works too.