Does Not Support Alias to Central Plug-ins Folder.

VERIFIED FIXED in mozilla0.9.3



18 years ago
17 years ago


(Reporter: Bill Hofius, Assigned: Brian Nesse (gone))


Mac System 9.x

Firefox Tracking Flags

(Not tracked)



(1 attachment)



18 years ago
I am using Mozilla 5.0M18 Build 2000111608.  This version does not support the
use of an alias to a central plug-ins folder.

I use a central plug-ins folder on my systems.  I do so because: 1.) It saves
disk sapce; 2.) It simplifies the installtion of plug-ins; 3.) the iCab web
browser uses a central plug-ins folder.

Mac OS 9.0.x creates a special "Internet Plug-ins" folder within the System
Folder.  This is the plug-ins folder that iCab accesses.  I therefore have
placed all  of my web browser plug-ins into this folder.  I then make an alias
of this folder, re-name it as appropriate, and place the alias within my web
browser application folders.  This has worked so far with MS Internet Explorer
4.5 & 5.0, Netscape 4.7.x, and iCab.

When I place an alias in the Mozzila application folder, Mozilla does not
recognize the plug-ins folder.  Should I navigate to a site that requires the
use of a plug-in, Mozzila reports something to the effect of, "The Netscape
Automatic Download Plug-in Could Not be Found."   Replacing the alias with a
genuine folder with genuine plug-ins solves this probelm.

Comment 1

18 years ago
Confirmed 2000112608 - moving the "Plug-Ins" folder to the desktop and creating
an alias to it in the Mozilla folder, the plugins become unavailable. This is
probably a bad thing as both Mac OS 9.x (QuickTime is actually what creates it)
and Mac OS X have central plugins folders which can be handy to use for users
with more than one brand/version browser.
Ever confirmed: true

Comment 2

18 years ago
Having Mozilla support the System Folder's "Internet Plug-ins" folder 

would be useful. IE5 and iCab check for and use plug-ins from this 

directory on both MacOS and OS X. <Folders.h> defines a constant that 

can be used with FindFolder(): kInternetPlugInFolderType	= 


Comment 3

18 years ago
Reassigning to bnesse and moving to m0.9.1
Assignee: av → bnesse
Target Milestone: --- → mozilla0.9.1

Comment 4

17 years ago
Adding patch to resolve alias on Plug-ins folder. Any work specific to the 
"Internet Plug-ins" folder will be addressed in bug 78751. cc'ing beard and 
attinasi (our new Mac guy :)) to request review and super review.

Comment 5

17 years ago
Created attachment 33595 [details] [diff] [review]
Patch to resolve alias on plugins folder

Comment 6

17 years ago

Comment 7

17 years ago

Comment 8

17 years ago
Wait. What happens with a broken alias? Will we bail later? Or should you test 
the result of ResolveSymlink(), and set some kind of flag here?

Comment 9

17 years ago
moving to 0.9.3 (if it is checked-in before that time that's fine). 
Target Milestone: mozilla0.9.1 → mozilla0.9.3

Comment 10

17 years ago
It should set the mError member and fail where ever it currently fails if no 
actual folder exists. I'll step through both processes and report back.

Comment 11

17 years ago
If the real folder is missing, the SetLeafName function returns with mError set 
to noErr (because that's what it does when it gets a fnfErr). Upon returning to 
the caller (LoadPlugins()) which then calls Valid() (which returns true even 
though it's not) and then it eventually fails (silently) in 
ScanPluginsDirectory() when it can't make a valid nsDirectoryIterator.

When the alias is bad, the mError member is set to fnfErr, which causes the 
Valid() test to fail, thus eliminating the call to ScanPluginsDirectory() which 
would eventually fail anyway.

So, yes, we will bail later, and no, there is no need to handle the error 
condition from ResolveSymLink().

Comment 12

17 years ago
Darn, forgot to add Simon to the 'cc list so he would actually see my response.

Comment 13

17 years ago
Fine. my sr stands.

Comment 14

17 years ago
Fix checked in.
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 15

17 years ago
fixd long time ago.verif.
You need to log in before you can comment on or make changes to this bug.