Closed Bug 21943 Opened 20 years ago Closed 20 years ago

have installer create empty Plugins folder and copy in npjava*.dll

Categories

(SeaMonkey :: Installer, defect, P3)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: ekrock, Assigned: ssu0262)

References

Details

(Whiteboard: [DONTTEST])

To avoid breaking plugins in M12, we decided not to create an empty plugins
folder.

For M13, the plug-in detection logic will be fixed so that it *first* checks the
Mozilla plugins folder (if it exists) and uses the plugin there (if found), and
then if it hasn't found the needed plug-in, goes on to check the Nav4 folder.
Making this fix is bug #21938.

Once #21938 is fixed, we should change the installer so that it creates the
empty plugins folder and copies in the npjava*.dll files from the JVM (if
available). That way, both plug-ins and Java will work smoothly from M13.

Thanks to ssu for the fast work on M12!
Depends on: 21938
Whiteboard: [DONTTEST]
Target Milestone: M13
Setting to M13 & noting dependency: we don't want to fix this bug until 21938 is
fixed.

When this bug is fixed, make sure to take care of the Mac-specific problem of
the empty plugins folder being created in the wrong place. See this comment from
21881:

    -- Additional Comments From sgehani@netscape.com  1999-12-15 23:36 ---
Even if it is an issue on the Mac the "Plugins" folder is being created in the
wrong place -- parallel to the "Mozilla Folder" (yes, that's broken behavior).
So, Mac M12 plugin loading should use the 4.xx plugins area in its search
path if this was former behavior. But, I'd be interested to know the final
desision on the behavior so I can rectify this horkage correctly.
Status: NEW → ASSIGNED
adding michaell and dveditz to the CC list.
Need a meeting with Eric -- we've been told both to create and not to create
the plugins directory. Plugin search path needs to be rethought perhaps.
No longer blocks: 22463
No longer depends on: 22463
For now please do as this bug specifies for M13. Waiting to understand
suggestion that we would not want to create a plugins directory at all for beta.
Depends on: 22463
Apparently if we do not create the plugins directory mozilla looks for a
communicator installation and uses *that* plugin directory, thus enabling all
the plugins the user has already collected.

This is a bad way to solve this problem. Either installation/migration should
give the user the option of copying these plugins over, or plugins should
support a pref that points at a different plugins directory or a set of
directories.
Why do you think this is a "bad" way to solve the problem? Benefits:
1) maximum ease of use and testing during milestone builds & betas
2) no extra development work for engineering

If we modify installation/migration to give the user the option of copying these
plugins over, you're creating extra work for engineering. If the user copies
*all* the plugins over, then the net effect is the same as just falling back to
the Comm4 directory.  And if the user has to decide for *each* plugin, how is
the end user going to know which plugins will/won't work within Nav5?  So I
don't see what the benefit to the user of this extra work for engineering is.
Please cost-benefit justify the proposal to copy over plugin binaries.

Likewise, please explain the cost-benefit of adding a user-control pref. Why do
we want plug-in search path to be under the control of each user and to depend
on user preferences?  To minimize user confusion and site admin costs, I'd argue
that Nav5 plug-in search should behave in the same way (whatever our final
resolution is) for all users.  Either it looks in the Nav5 plugins directory
only, or it looks in the Nav5 plugins directory and, if nothing's found there,
looks as a fallback in the Nav4 plugins directory if it exists.  Either way,
this provides consistent user experience and plug-in behavior to all users.

For now, for the milestones, the simplest, easiest, fastest,
least-work-for-engineering, least-confusion-for-users solution is to look first
in Nav5 plugins and then in Nav4 plugins.
Eric, you hit it in the second half of your post.  I think it would be good to
fail over from the 5.0 plug-ins directory to look in the 4.x directory, but I
believe that what Dan was referring to as "bad" was the idea that we would copy
plug-ins from one directory to the other.  It's a bad idea to have two versions
of software on the user's disk (especially when they don't know we're creating
two) when one will suffice.
What I think is bad is:

1) if a user installs mozilla without java they get all their Communicator
plugins, if they install mozilla *with* java that get none of their
communicator plugins.

2) users install plain mozilla and get all their Communicator plugins. Later
they XPInstall another plugin and mysteriously lose all the other plugins they
were using.

Both are plain wrong.

Better choices would be:

- don't ever look anywhere other than bin/plugins (like old navigator). You
install, you have no plugins, tough -- find 'em yourself.

- copy 4.x plugins over if found. Could offer a choice during install.

- Search multiple places for plugins. This is already done in Unix and needs to
be added for locked down WinNT/Win2K systems too. Add other places to a plugin
search path, one of which is an old Communicator directory. This could be a
hardcoded search path, or a non-UI preference set during profile creation or
something, but *consistent*. Either we look in the 4.x place or we don't, all
the time, regardless of whether a 5.x plugins directory was found or not.

I assume the current behavior stems from trying to avoid the first option. No
one likes the idea of copying all the plugins. So why are you dead set against
the last option?
To bring this up to date: Dan and I chatted directly and we agree that:

1) the installer should create an empty plugins folder (including whatever is
necessary/appropriate for OJI as well)
2) the search code, at whatever time it is executed (startup? on the fly? I
don't even know) should look for a given plugin *first* in the Mozilla plugins
folder, and if it is not found there, look next in the Nav4 plugins folder.
[Another way of achieving the same result/saying the same thing: it should
register in its list of available plugins all those plugins found in Mozilla
plugins directory, and then should register any additional plugins found in Nav4
plugins directory without overwriting those already found.]

So: then consensus for the installer is: for M13, please create empty Plugins
folder and copy in npjava*.dll.

Andrei will update the plugin search logic for M13 per a separate bug as soon
as this is done. (Please make the change ASAP so Andrei has some time to checkin
and test before the tree closes.) Thanks!
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
fixed.  It now creates the Plugins folder and attempts to copy npjava*.dll files
to it.
Status: RESOLVED → VERIFIED
This bug is fixed in the 2000011108 build but java still does not work.  Will create a new bug for the new problem.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.