Closed Bug 21943 Opened 20 years ago Closed 20 years ago
have installer create empty Plugins folder and copy in npjava*.dll
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
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 email@example.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.
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.
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.
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.
This bug is fixed in the 2000011108 build but java still does not work. Will create a new bug for the new problem.
You need to log in before you can comment on or make changes to this bug.