From Bug Helper: User-Agent: Mozilla/4.51 [en] (X11; U; SunOS 5.7 sun4u) BuildID: 1999122808 When Mozilla is ran, it will look for OJI plug-in in old version of Navigator's plugins directory first, before looking into its plugins directory in Mozilla. This has big impact to OJI. Since older version of Navigator may have older version of Java Plug-in installed and they may not be compatible with latest Mozilla, the wrong version of OJI plug-in will be loaded, and it will fail. Although I have the latest OJI plug-in in Mozilla's plugins directory, it will not be loaded. Reproducible: Always Steps to Reproduce: 1. Install older version of Java Plug-in in older browser 2. Install newer version of Java Plug-in in Mozilla 3. Start browsing HTML page which has APPLET tag Actual Results: The older version of Java Plug-in installed with older browser will be loaded. Expected Results: The newer version of Java Plug-in installed with Mozilla should be loaded. Mozilla should look for OJI plug-in from its Mozilla's plugins directory first.

This is really a plugin bug.

This bug is blocking OJI/Java Plug-In from working correctly. With the current behavior, an older Java Plug-In will likely be found, which is not compatible with current Mozilla builds.

How old was the build? I checked in a new plugin finding logic on Jan 31 and fixed some problems on Feb 11. I stepped through the plugin list creation process and see nothing wrong: it looks for plugins in new dir first and adds plugins to the list, then goes to the old dir to add plugins from there but skips the filenames we already got.

Putting on PDT+ radar for beta1.

Increasing the severity from critical to blocker as this bug, if confirmed, prevents us from testing and QAing Java support in the browser. QA is of course free to change this back if I'm doing the wrong thing.

Note: if PDT team assigns a fix cut-off date to this bug, for consistency, it shouldn't be earlier than the fix cut-off date for bug 23672 (currently 3/03).

Stanley, is this still happening? I tried Mozilla with no java plugin in its own plugins dir and it does not work. Then I added three dlls and it works fine to me. With release build. On debug build it gracefully fails. What else should I do to determine whether old or new plugin is picked up?

I am going to close this one. Please respond if anyone thinks it is still here.

Nobdy responded so I close it.

I have the latest Mozilla bug (02/29/2000), and this bug still shows up. Basically, if there are older version of Navigator installed, when Mozilla starts up, it will look for the plug-in DLLs first in older Navigator's plugins folder instead of Mozilla's plugins folder. I am pretty sure about this because the console output of the Debug build Mozilla actually prints out the search location one-by-one, and the older Navigator comes first.

Stanley, the console output you see shows the order of creation of nsPluginDir objects and the output comes from their constructors. Actual scanning occurs later, Mozilla plugins dir being first. Can you confirm the bug is still here by trying actual configurations and seeing the result?

I tried the latest build 03/01/2000, and I put NPJava32.dll (WIn32 OJI DLL) into both old Navigator's plugins directory and Mozilla's plugins directory, I can see from the debugger that the one in old Navigator's plugins directory is get loaded, so this bug is not fixed yet.

I stepped through the code. The bug is in modules\plugins\nglsrc\nsPluginHostImpl.cpp. In nsPluginHostImpl::LoadPlugins, it will enumerate the Mozilla's plugins folder first, and then enumerate the Nav 4x plugins folder. However, in the enumeration, the plugin information is added to the head of a linked list one by one. Since Nav 4x plugins are enumerated after Mozilla's plugins, the plugins in the Nav 4x folder will be added to the head to the list -- so the Nav 4x plugins will be used instead of the one in Mozilla's plugins directory. The fix will be to add the plugins in the right order into the linked list, or reverse the order of enumeration.

The bug seems both understood, and straight forward. Can you add a landing date for this item to the status whiteboard. Note that if we don't have a fix in place before 3/10, this will become PDT-

I have talked to av and worked out a fix with him, and hopefully he will check it in soon.

Checked in.

Stanley, I do not have a debug build to verify if this logic works perfectly. Could you please verify this bug for me? Thanks !

I have tested out the fix, and it works!! However, we have other issues: the fix is to do a case insensitive comparsion of plug-in file name, so the proper file names are compared in Win32. However, this will break Solaris or other UNIX platform because their filesystem are case sensitive. Therefore, the fix need to be conditionly apply only to Win32 build.

The whole logic is currently turned on for Windows only. I'll keep this in mind when implementing it for other platforms.

By the way, anybody knows how Win2000 is doing in this department? The rumors are it allows filenames differing only by case in the same dir.

I had a talk with Andrei and he agreed that I mark this bug as verified. I will file a new bug for 'implementing plugin finding logic similar to Windows on other platforms'. Thanks !!