27755 - Mozilla looks for OJI plug-in first in old Navigator's plugins directory

Status: VERIFIED FIXED

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

Description

[stanley.ho]

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.

Comment 1

[edburns]

This is really a plugin bug.

Comment 2

[drapeau]

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.

Comment 3

[av (gone)]

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.

Comment 4

[leger]

Putting on PDT+ radar for beta1.

Comment 5

[ekrock's old account (dead)]

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.

Comment 6

[ekrock's old account (dead)]

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).

Comment 7

[av (gone)]

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?

Comment 8

[av (gone)]

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

Comment 9

[av (gone)]

Nobdy responded so I close it.

Comment 10

[stanley.ho]

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.

Comment 11

[av (gone)]

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?

Comment 12

[stanley.ho]

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.

Comment 13

[stanley.ho]

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.

Comment 14

[Jim Roskind]

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-

Comment 15

[stanley.ho]

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

Comment 16

[av (gone)]

Checked in.

Comment 17

[shrirang khanzode]

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

Comment 18

[stanley.ho]

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.

Comment 19

[av (gone)]

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

Comment 20

[av (gone)]

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.

Comment 21

[shrirang khanzode]

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 !!