fix Plugin detection logic to first check Plugins folder, then if Plugin not found, the Nav4 folder next

VERIFIED FIXED in M14

Status

()

P3
normal
VERIFIED FIXED
19 years ago
13 years ago

People

(Reporter: shrir, Assigned: serhunt)

Tracking

Trunk
All
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [DONTTEST])

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
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.)
Summary: Empty 'Plugins' folder in Mozilla → fix Plugin detection logic to first check Plugins folder, then if Plugin not found, the Nav4 folder next
Whiteboard: [DONTTEST]
Target Milestone: M13
Thanks Shrirang!

Setting to M13. Edited description. Marking [DONTTEST] as no test case is
needed.
Blocks: 21943
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 2

19 years ago
Do we have unanimous decision on this?

Comment 3

19 years ago
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?
(Assignee)

Updated

19 years ago
Target Milestone: M13 → M14
Bulk moving old [donttest] code to new donttest keyword. Sorry for the spam!
Keywords: donttest
(Assignee)

Comment 6

19 years ago
I have a code to check in. Any volunteers to be specified as a code reviewer?
(Assignee)

Comment 7

19 years ago
Created attachment 4764 [details]
Changes in NS_IMETHODIMP nsPluginHostImpl::LoadPlugins()

Comment 8

19 years ago
I'm pretty certain no one on this cc:list is qualified to act as a code 
reviewer.
(Assignee)

Comment 9

19 years ago
Eric (Pollmann), could you please look at it?
(Assignee)

Comment 10

19 years ago
Thanks, Eric. Checked in, marking fixed. I enabled it temporarily for Windows 
only.
(Assignee)

Comment 11

19 years ago
Marking fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Reporter)

Comment 12

19 years ago
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.
(Assignee)

Comment 13

19 years ago
Strange... Works fine for me. Probably we need to compare our envs and versions.
(Reporter)

Comment 14

19 years ago
I have windows NT version 4.00. Used the seamonkey build(2000020108).
(Reporter)

Comment 15

19 years ago
Marking this bug verified since it is fixed on windows. Another bug has been 
opened for fixing plugin logic on other platforms, bug 31872.
Status: RESOLVED → VERIFIED

Comment 16

13 years ago
(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?

Comment 17

13 years ago
Added myself to CC list.
You need to log in before you can comment on or make changes to this bug.