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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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 = FOUR_CHAR_CODE('ハet').
Reassigning to bnesse and moving to m0.9.1
Assignee: av → bnesse
Target Milestone: --- → mozilla0.9.1
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.
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?
moving to 0.9.3 (if it is checked-in before that time that's fine).
Target Milestone: mozilla0.9.1 → mozilla0.9.3
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.
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().
Darn, forgot to add Simon to the 'cc list so he would actually see my response.
Fine. my sr stands.
Fix checked in.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
fixd long time ago.verif.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.