I am filing this bug as per Eric's instructions. After mozilla installation, a PLUGINS folder can be seen. Trying to view the contents of the folder shows that it is empty. Whenever a user tries to load any plugin file through mozilla, it does not work. Only when the empty PLUGINS folder is deleted manually, the browser looks for the essential plugin files (.dll's or shared libraries) in the 4.x browser installation(if one has any) and plays that file. Am adding Erick's comments to this bug as to how the logic should work: What I personally think the final Mozilla code should do: 1) look in the Mozilla plugins directory; if the plug-in is found there, use it; otherwise ... 2) on Win32 and Mac: if there's a Nav4 installation, look in its plug-in directory, and if the plug-in is found there, use it (Note: We shouldn't do this on Linux because Nav4 Linux plugins are Motif and won't work in GTK. Whether we should do this on other UNIX platforms depends on whether those platforms stick with Motif or switch to GTK. If they stick with Motif, we should look; if they switch, we shouldn't.)

Thanks Shrirang! Setting to M13. Edited description. Marking [DONTTEST] as no test case is needed.

Do we have unanimous decision on this?

i think we are unanimous to give it a go and see what happens, it is the best way to test backwards compatibility.

When you modify the plug-in search path code, could you do so in a way that is easy to change back again to not search Nav4 plugins directory? (e.g. #IFDEF SEARCH_FOR_PLUGINS_IN_NAV4_DIRECTORY macro that enables or disiables going on to the Nav4 directory when not found in Nav5 directory, etc.) Reason: we still have to wait and see how many plug-ins are really backwardly compatible before we make a final decision about which way we do it for final release. The other thing is that on Linux, we definitely *shouldn't* look in the Nav4 plugins directory as all Nav4 Linux Motif plug-ins are expected to break under Nav5. So could you make sure that on Linux this macro is always set to FALSE?

Bulk moving old [donttest] code to new donttest keyword. Sorry for the spam!

I have a code to check in. Any volunteers to be specified as a code reviewer?

I'm pretty certain no one on this cc:list is qualified to act as a code reviewer.

Eric (Pollmann), could you please look at it?

Thanks, Eric. Checked in, marking fixed. I enabled it temporarily for Windows only.

Marking fixed.

Somehow Shockwave plugin does not work unless I manually place the 'npswf32.dll' in plugins folder under the mozilla installation. Other plugins like realplayer and quicktime (installed under 4.x) work just fine.

Strange... Works fine for me. Probably we need to compare our envs and versions.

I have windows NT version 4.00. Used the seamonkey build(2000020108).

Marking this bug verified since it is fixed on windows. Another bug has been opened for fixing plugin logic on other platforms, bug 31872.

(In reply to comment #7) > char * filename1 = PL_strrchr(name1, '\\'); > if(filename1 != nsnull) > filename1++; > else > filename1 = name2; Shouldn't that be: filename1 = name1; I tried to find this function using "http://lxr.mozilla.org/" to see it this was updated at a later stage in another bug, but couldn't find any reference. How should I try to do that next time I encounter something like this?

Added myself to CC list.