Closed Bug 21881 Opened 25 years ago Closed 25 years ago

[DOGFOOD][M12][URGENT] all plug-ins "broken" in M12; remove plugins directory from installer script to fix

Categories

(SeaMonkey :: Installer, defect, P3)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: ekrock, Assigned: ssu0262)

References

()

Details

URGENT: I believe this bug should be fixed for M12! In the latest builds (I tested using Commercial 1999121320 on Win NT 4.0 SP3) plug-ins such as RealPlayer that worked in prior builds appear to the user to be "broken" (the user sees only a grey "embed" rectangle). The reason: unlike previous milestone builds, the latest builds are creating an empty "Plugins" directory. Because Mozilla is now detecting this directory (where it found none before), the current application logic is checking *only* in that directory for plug-ins and not going on to check the Nav4 plug-ins directory as well. This was a well-intentioned change intended as a convenience for plug-in developers to save them the trouble of creating an empty Plugins directory themselves. However, it overlooked the subjective user experience result that "Hey, all plug-ins are broken in M12/the Mozilla alpha!" This could create a negative reaction to the Mozilla alpha and would be difficult to explain. Plus, users have no convenient way to install plug-ins into the Mozilla Plugins directory right now. To avoid negative user reaction on M12/the Mozilla alpha, please change the installer script so that it, as before, does *not* create an empty Plugins directory. For M12, the small number of plug-in developers can continue to create this manually, and the large number (70k) of download testers will not be inconvenienced. Post-M12, we can discuss and implement our long-term solution without the time pressure of M12 upon us. Andrei Volkov and I have discussed this and (subject to open discussion and review in the newsgroups) agree that the long-term fix is for us to modify the logic to check the Plugins directory first (if it exists) and then if the needed plug-in is not found there, to look in the Nav4 plug-ins directory.
Target Milestone: M12
Oh, I talked to chofmann and he agreed to accept this change for this milestone (although his personal opinion is that long-term, Mozilla *shouldn't* be checking in the Nav4 builds--something that will need to be resolved in newsgroup discussions).
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
The installer no longer creates the plugins folder. As a side effect, it will also not seek out jre on the system and copy its npjava*.dll to the seamonkey\plugins folder. This means that seamonkey will not know that there's a jre installed on the system where there is one there. Does this problem also exist on the mac platform?
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: RESOLVED → VERIFIED
Plugins folders not being created in latest builds M12 final for Mac and Win
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.