53976 - on Mac, change name of 'plugins' folder to 'plug-ins' for backward compatibility

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect, P1)

Description

[ekrock's old account (dead)]

See bug 36089 for a full explanation of why we have to do this. In brief, we 
must provide a "plug-ins" folder to provide backward compatibility with 
installers for legacy Mac plug-ins. The folder for plug-ins on the Mac was 
always named "plug-ins" rather than "plugins" as on Win and Linux.

av has already modified the code so that it will recognize the "plug-ins" folder 
on the Mac and load any plug-ins found therein, but we can't rely on legacy Mac 
plug-in installers creating the folder if it doesn't exist. To be safe, we need 
to create that folder ourselves as a standard part of the install.

Creating an empty directory as part of the install is of course a trivial fix. 
This is also a P1 bug because it will affect high profile partners (Adobe 
Acrobat, Macromedia Flash, Macromedia Shockwave, RealPlayer, etc.) if not fixed. 
It is also high profile backward compatibility. Nominating nsbeta3 and rtm as 
correctness and 4xp.

Comment 1

[Sean Su]

reassigning to Samir.

Comment 2

[Samir Gehani]

Eric,
Ummm, so just renaming "Plugins" to "Plug-ins" should work, right?  Please 
change the summary to confirm that this is the case.  Thanks.

Comment 3

[ekrock's old account (dead)]

Andrei: If they change the "plugins" folder name to "plug-ins" on Mac, will your 
revised code still work? (For example, we wouldn't want to eliminate the current 
"plugins" folder if that would cause your search code to crash.)

Plug-in partners: Should we (1) change the "plugins" folder on Mac to 
"plug-ins," or (2) have both a "plugins" and "plug-ins" folder?

I think that (1) is the best solution if it won't cause problems for Andrei's 
code which currently looks for both "plugins" and "plug-ins". (2) might be a 
least-risk solution given limited time before ship--but carries the downside 
that we might be stuck with two directories for plug-ins forever on Mac. 
Comments?

Comment 4

[Daniel Veditz [:dveditz]]

Waiting final verification from ekrock that this is exactly what he wants. The 
code change is just a "typo"-like fix once given the go ahead. (note: we need 
nsbeta3 double-plus approval from PDT to make this change. Ekrock please lobby 
for this if you want it)

Comment 5

[av (gone)]

I thought the idea was to reach the uniformity across the platform and 
encourage plugin makers to use 'Plugin' folder. Having 'Plug-ins' folder beside 
it was supposed to solve backward compatibility problem. As plugin makers update 
their plugins there should less plugins going to 'Plug-ins' and more going 
to'Plugins'. Please correct me if I am wrong. And we can stop making 'Plug-ins' 
folder in the distribution in one of the next releases.

Having only 'Plug-ins' folder should be OK with my code, but I am not sure this 
is what we want.

Comment 6

[ekrock's old account (dead)]

Spoke with Andrei. Here's the verdict: in an ideal world, we would indeed want a 
single uniform plug-ins folder name across all platforms. But this is the real 
world, not the ideal world. In the real world, we will have to support the 
"plug-ins" folder name on the Mac *forever* in order to provide backward 
compatibility with existing plug-in binaries and their installers. Adding a 
second "plugins" folder would only confuse the situation by introducing new 
issues like "What happens if different versions of a plug-in are installed into 
the two folders?" and confusing users who look there. So in this situation, 
backward compatibility and ease of administration are more important than 
cross-platform consistence of naming. The best solution is to have a single 
"plug-ins" folder on the Mac.

Andrei believes that his code that searches for plug-ins will work fine if 
there's only a plug-ins folder, but he hasn't tested it. So:

1) shrir -- In a recent daily build, would you please rename the plugins folder 
to plug-ins and see if all still goes well?
2) sgehani -- Please go ahead and make the installer change as soon as shrir has 
tested.  

Changing summary from "on Mac, installer must create "plug-ins" folder in same 
directory as "plugins" folder" to "on Mac, change name of 'plugins' folder to 
'plug-ins' for backward compatibility". Clearing [need info]. Thanks all!

Comment 7

[shrirang khanzode]

I tried today's branch build on mac renaming the 'plugins' folder to 
'plug-ins',launched the build and tried a few plugins. They work fine.I can 
confirm that renaming the folder to 'plug-ins' is working fine.Thnx!

Comment 8

[shrirang khanzode]

Just got the info from builds release team that today's bits are the trunk bits 
and not branch. Will wait for tomorrow's branch build to check this again.

Comment 9

[Samir Gehani]

Once we have nsbeta3++ status, I'll execute the change.

Comment 10

[ekrock's old account (dead)]

michaell: At the next PDT meeting, would you please make sure this is marked 
nsbeta3++ so we can get this no-brainer off the radar?

PDT team: please provide nsbeta3++ status immediately so we can close this bug 
out. This bug is the follow-through on bug 36089 (which itself was already 
approved nsbeta3++ and checked in). In bug 36089, Andrei modified the plug-in 
detection code to look in the "plug-ins" directory on Mac; now we just need to 
modify the installer script so that we create a directory by that name instead 
of the old "plugins" directory name.  This change is also practically zero risk 
as (a) we're talking about a one-line change to an installer script, (b) the 
code is already written to detect both directories, and (c) shrirang will 
doublecheck that plug-ins are indeed found and work correctly before we make the 
change. It would make no sense to have approved changing the plug-in detection 
code to look in a "plug-ins" directory but then deny approval for creating such 
a folder for plug-ins to install into, so please mark nsbeta3++. Thanks!

Comment 11

[Daniel Veditz [:dveditz]]

CC'ing mac folks to get buy in from them. Giving preliminary rtm+ in case the
PDT shoots this down for PR3.

Comment 12

[Samir Gehani]

The change for this is in the mac build system (which is not checked in).  I can 
work on this while jj is on sabbatical.

Comment 13

[Michael La Guardia]

Marking nsbeta3++.  Please get this change in ASAP to avoid slipping pr3.

Comment 14

[shrirang khanzode]

Still waiting for a mn6 (m18 release) build to verify this on..

Comment 15

[shrirang khanzode]

verified that changing name of plugins folder to 'plug-ins' does not hamper 
working of plugins on mac branch build 2000092711.

Comment 16

[ekrock's old account (dead)]

OK Samir, all clear--please check in ASAP to make nsbeta3! Shrirang, many thanks 
for helping verify that this works!

Comment 17

[Samir Gehani]

Build system change for Shockwave done.  Need to change the developer build 
scripts that deliver the MRJ plugin now.  

Comment 18

[Samir Gehani]

Attachment: Update developer build scripts to deliver to "Plug-ins" instead of "Plugins"

Comment 19

[Samir Gehani]

sfraser,
Can you super review the above patch?  ssu has already reviewed them.  Thanks.

Comment 20

[Simon Fraser [no longer active]]

patch looks good; r=sfraser. Did you run with Plug-ins? Does it work?

Comment 21

[Samir Gehani]

Attachment: Addendum[1/2] to above patch: ns packages-mac. sfraser, please review this too.

Comment 22

[Samir Gehani]

Attachment: Addendum[2/2] to above patch: mozilla packages-mac. sfraser, please review this too.

Comment 23

[Samir Gehani]

sfraser,
See shrir's comments above where he confirmed that running with "Plug-ins" works
on both branch and trunk builds.

Comment 24

[Simon Fraser [no longer active]]

r=sfraser on those last two.

Comment 25

[Daniel Veditz [:dveditz]]

This is a scary change, and kind of a big thing to drop on Samir at the last 
minute. I'm also concerned that just fixing the plugin loader (36089) and the 
installer (this one) seems insufficiently thought through. It was trivially 
easy for me to find several other cases of dependence on or use of "Plugins" in 
the Mac -- how many more did I miss?

Does mozilla/build/mac/build/build_scripts/MozillaBuildList.pm line 2474 have 
to change as well?

What about nsAppFileLocationProvider.cpp in modules/appfilelocprovider/src?
(and the possibly obsolete xpfe/appshell/src/nsFileLocations.cpp)

mozilla/xpinstall/src/nsInstallFolder.cpp needs to be changed to match or else 
XPInstalled plugins will get installed into the old "Plugins" name incorrectly 
anyway.

Comment 26

[Samir Gehani]

MozillaBuildList.pm is not part of the build (still under construction or some 
such, I believe) and Simon will merge these changes at some point before this 
script goes live. 

Comment 27

[Samir Gehani]

Attachment: Patch addendum: dir svcs and xpinstall explicit references to "Plugins" -> "Plug-ins"

Comment 28

[Samir Gehani]

Two glimpse searches ("Plugins" and [^a-z]Plugins[^a-z] with dveditz's help: 
thanks!) yielded the need for the last patch above.  Hopefully this is thorough 
although admittedly trunk inspection, not branch since we don't have a branch 
lxr that I know of.

sfraser, ssu, 
Please super review and review the last patch above, respectively.  Thanks.

Comment 29

[Samir Gehani]

Sean gave this r=ssu.

Comment 30

[Simon Fraser [no longer active]]

sr=sfraser

Comment 31

[Samir Gehani]

Fxi completely check into branch.  Last patch still needs to get checked in to 
the trunk which is not currently open.  

Comment 32

[Samir Gehani]

Fix merged to trunk.

Comment 33

[Grace Bush]

verified on build 2000092911MN6