Closed Bug 33584 Opened 26 years ago Closed 26 years ago

Mozilla is loading Plugins from Communicator folder

Categories

(Core Graveyard :: Plug-ins, defect, P3)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Windows 98
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 23856

People

(Reporter: trudelle, Assigned: serhunt)

Details

Win32 Mozilla is currently loading Plugins from the Communicator plugin folder, in addition to its own plugin folder. This is wrong, there should be no such tying of an open source product to a commercial product. There is no expectation that a newly installed product will share components in another product's directory. Plugins should be migrated for use in Mozilla, or made available in a common location. In either case, it should be possible to configure each independently of the other.
Eric, I don't think the bug report is a good place for discussion, but we can start here. Do you have any recent responses from the developer community? Peter, by doing this we meant to ease people's life when migrating to 6.x. I beleive that having installed a new browser one would expect it work at least no worse than the previous version. That is, user's favourite page with the Flash plugin should still work for him. That was the idea. IE does the same thing too.
Status: NEW → ASSIGNED
I agree that the migration experience should be seamless. As you can tell by bug 33536, mine isn't. Until we can guarantee that existing plugins work the same, it would be better to migrate them to the new plugins folder and keep them separate. I'm still wondering why we are leaving them in place, is there a reason? If they can/should be shared for some reason, then that should be done in a shared directory in the system space. What MS does with IE is not really comparable, since IE is by their definition an inseparable part of the OS, and they aren't forcing any open source apps to look into a third-party application's directory. What happens if someone removes a plugin from Communicator? What happens when someone upgrades to NS6, and then uninstalls Communicator?
As to the reason to keep plugins in place, I can easily imagine that some plugin installation process involves not only just bare copying a dll but also some registry settings, where e.g. plugin location may be specified. If somebody removes a plugin from Communicator he will loose it for Mozilla too. And I beleive uninstalling Communicator does not remove Plugins folder. Correct me if I am wrong.
Then we should either copy and dup registry settings, or put them in a common shared directory. I would not expect removing a plugin from Communicator to affect Mozilla any more than removing one from IE should. If uninstall left the plugins, then I'd consider that a leak.
To do registry is a private plugin business. We may not even know where it is. To do things clean we should ask a user to reinstall plugins after he upgrades to 6.x. Now we are in process to decide how much of burden it is.
I don't know what you mean by private (especially on an open source project), nor what you mean by 'where it is'. Aren't plugins generally offered to users as they need them, and installed without a restart? That doesn't seem like much of a burden.
Just to add to a couple of things that have been mentioned: 1. Regarding reinstallation of plugins: It IS a burden for users that have to download them thru slow modems (don't view this as justification for plugin sharing though). 2. some plugins have separate uninstallers - there is no way to tie the uninstallation of netscape with all the plugins a user may have installed. Simply blowing away the plugins dir does not uninstall a plugin (a plugin may have installed files to directories other than the netscape plugin dir). 3. For the same reason, copying legacy plugins from the netscape dir to the mozilla dir may break plugin uninstallers or cause other problems since the copied files will not get removed if the user uninstalls the legacy plugin.
I've still got an open mind on the question of whether or not Mozilla should look in the Nav4 plugins directory when a needed plug-in is not found in its own plugins directory. I could see us releasing either way. I'm waiting for more data about the extend of our backward compatibility: how many plug-ins will really work (sans LiveConnect) on Win32 and Mac? However, I *definitely* think that we should not attempt to copy plugin installations over. This would be new code development (a luxury we don't have at this point where there's an alternative) and we'd have to QA this with all the plug-ins out there across Win32 and Mac and across plug-in versions ... we can't afford the engineering time, we can't afford the QA time, and we're almost certain to fail in unpredictable ways even if we try. So unless someone can make a convincing case that they know off the top of their head how to install, migrate, and remove every version of every plug-in on the planet in a 100% reliable way across platforms and thathe code to do so will take one person day and need no QA ... I say we restrict the options we consider going forward to (1) falling back to the Nav4 directory when not found in the Mozilla plug-ins directory, or (2) not doing so, and accepting that users will have to re-download their plug-ins as they've done for previous releases.
About punkt (2) in Eric's comment -- reinstalling plugins. As far as I understand many plugin installers look in the registry for 'Communicator' as the place to install into. Is Mozilla installer going to take over this registry setting? I guess not. So plugin manufacturers will have to rewrite their installers to add Mozilla to the existing list of Communicator and IE. Untill they accomplish this, there is a good chance reinstalling a plugin will not help.
Regarding av's point about installers: Beatnik recently rewrote its installer, dropping netscape 3 support just to prevent the installer from having to search every directory of every drive on a user's system looking for ns 3 installations. Now it goes straight to the registry to find the ns 4 install dir - a much better and faster end user experience. Yes we expect to have to modify it for mozilla - but please don't make developers of new plugins have to search the user's drive for the right place to install the plugin. Regarding ekrock's 2 legacy plugin options: If you decide to go with the first (look in the ns 4 plugins dir), then plugin developers need to be able to 'opt out' - opt specific plugins out of that search. For example, a version of the Beatnik plugin ships with some versions of ns 4. The legacy Beatnik plugin is essentially useless in Mozilla due to the LiveConnect issue. If a Mozilla user wants to experience a page that uses Beatnik, then they MUST install a new plugin. Content developers use checks in their web pages to see if the Beatnik plugin is installed and enable/disable some features based on the presence of the plugin and/or notify the user that they should install the plugin. If Mozilla populates the plugins list with ns 4 plugins, then that will result in false positives as far as content developers are concerned - a version appropriate plugin is not installed but is improperly reported as being installed (similar to http://bugzilla.mozilla.org/show_bug.cgi?id=25003).
Erick, what should we do with this 'bug'?
Target Milestone: --- → M18
This is a DUP of bug #23856. Let's continue the discussion if this issue in that bug, to the extent that we discuss this issue in bug reports at all--I'll be opening a newsgroup thread on this in n.p.m.plugins ASAP. We need to decide for beta2. *** This bug has been marked as a duplicate of 23856 ***
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → DUPLICATE
verified duplicate.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.