Closed Bug 201291 Opened 23 years ago Closed 22 years ago

Inappropriate 'Desktop Folder' created for helper-opened downloads and email attachments.

Categories

(SeaMonkey :: General, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 200289

People

(Reporter: llaughridge, Assigned: asa)

Details

(Whiteboard: dupme)

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030408 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030408 Mac OS X uses ~/Desktop as the location of items for the GUI desktop. 'Desktop Folder' was a similar construct used under Classic (7.0 - 9.2.2) Mac OS. Mozilla 1.3, 1.4a, 1.4b create a ~/Desktop Folder directory under the following conditions: - Clicking on a PDF link in a web page with the PDF opened externally in Acrobat Reader (same goes for other files opened automatically with helper apps). - Clicking on an attachment in an email message This is a very problematic situation. One winds up with both a ~/Desktop and "~/Desktop Folder" which is confusing for end-users, and not compliant with the established OS X user interface. Reproducible: Always Steps to Reproduce: 1. rm -rf ~/Desktop\ Folder 2. click on a link to a PDF file. The file will download and open in the helper 3. OR, click on an attachement on an email message to open the attachment Actual Results: ~/Desktop\ Folder was created, and now contains the file. Expected Results: Preferably, placed the file in /tmp/<whatever> and deleted it when finished. Alternately, placed the file in ~/Desktop ~/Desktop Folder should NEVER be created if it does not exist.
Len, can you reproduce this problem using another Mozilla user profile?
Summary: Inappropriate 'Desktop Folder' created for helper-opened downloads and email attachments. → Inappropriate 'Desktop Folder' created for helper-opened downloads and email attachments.
Absolutely. I just tried it again to make sure (quit Mozilla, mv ~/Library/Mozilla ~/moz-original, rm -rf ~/Desktop\ Folder, launch Mozilla which creates a clean profile, go to website, click on pdf file, select to open with (acrobat reader or preview), ls ~ and verify that ~/Desktop\ Folder/ has been created and contains the pdf I just clicked on.) Any and all email attachments behave the same way. I'm not a developer, but could this be solved in the code with a simple s/Desktop\ Folder/Desktop/g ;-) ?
Len, Mozilla appears to use the default download location specified in System Preferences/Internet/Web for new profiles (at least it did when I just tested it). What do you have defined there?
Greg - You're right, but there's a catch: The catch is that I had *not* specifically entered anything there. If I explicitly choose any location (e.g. ~/Desktop) Mozilla then respects it. If nothing is chosen, the ~/Desktop\ Folder/ behaviour previously described occurs. Even with nothing defined in the OS X Internet Configuration preferences, when selecting a file to download the normal way (with a dialogue box prompting to save...), it defaults to ~/Documents initially, then whatever my last choice was. That's what threw me with why it would select a *different* location for email attachments and other unprompted downloads. I assumed (incorrectly) that Mozilla took care of that itself and did not require the OS-level download location settings. When there is no explicit selection for a download location in Internet Config, how does Mozilla make the determination to use ~/Desktop\ Folder/ ? Is that internal to Mozilla, or is that a (bizarre) default passed from Internet Config? Could there not be some logic-checking in Mozilla to say "if Internet Config says ~/Desktop\ Folder then it's retarded, use ~/Desktop instead"? Thank you for pointing that out, at least I have a work-around for now. Len
Len, what OS X version are you running? This could be related to or be a dup of bug 200289.
Greg - I think you have two different things going on here. Looking at the comments on that bug, the second paragraph in comment #3 leads me to believe that guy is using a UFS filesystem instead of a HFS+ one (...on volume "/"...) Either that, or his OS is just AFU. Comment #5 seems related to my bug, though. Len
My experience with this, using Mozilla 1.3 (release) version has been that a ~/Desktop\ Folder is created if I download anything that doesn't prompt for a save location. eg: if I option-click an item and choose a save location, the download goes where I tell it. However, if I click a link to download, say, a .bin or .sit file, the file is downloaded, but it appears in ~/Desktop\ Folder. This is also true for PDFs, as mentioned by Len. My Internet prefs say "Your Desktop" - they have since I installed Mac OS X. I have never changed my download location. I am also using the same Mozilla profile as I have used for Mozilla 1.1, 1.2, 1.2.1 and 1.3. I have never had this problem under previous Mozilla versions. The problem was resolved by opening the Internet prefs and re-selecting my Desktop folder (~/Desktop). System Preferences still lists it as "Your Desktop". The net effect is no change. Every other browser that I use has been downloading to ~/Desktop. It seems like Mozilla 1.3 doesn't know how to handle the default download location until something is changed. Certainly, since Mozilla 1.3 and above will not run on Mac OS 9 or below, if Mozilla uses a default setting in the cases where it isn't sure what to do, the default should be ~/Desktop instead of "Desktop Folder", because Mac OS 9 no longer needs to be accommodated.
BTW, I believe "System Preferences/Internet/Web" was meant to be an indicator of the clicking sequence ("click System Preferences, then Internet, then Web"), not a directory path. Personally, I use the "greater than" symbol (not going to type it here cos it might be interpretted as an HTML tag), but that's just me.
This is still happening. Is there any resolution in the works? Haven't seen any activity here recently... Thanks.
this behaviour is addressed for camino in bug 204548. should we merge the two bugs or keep them separate?
This still happens for us in the latest moz browser suite nightly builds, and it's pretty annoying. It appears the patch referenced in bug 204548 comment 2 was never applied to seamonkey. I'd found the bug in nsDirectoryService.cpp a couple weeks ago before I'd bothered to search bugzilla enough to find this issue; in any case, I'm fairly certain this is also a Mac OS X bug in FindFolder. See also bug 200289 comment 28 -- this bug happens all the time with shared preferences and roaming profiles.
Let me repeat others to clarify a couple of things to help with troubleshooting. 1. On a fresh user account, opening Apple Menu --> System Preferences... --> Internet icon --> Web tab says "Download Files To: Your Desktop". If you just leave this alone, the incorrect behaviour described here occurs. That is, Internet Config is passing bogus info to Mozilla, which then creates ~/Desktop\ Folder as a target upon first downloading something where you DON'T SPECIFY the exact target. The basic fault is with MacOS X Internet Config, but Mozilla is blithly relying on that data and so exhibits incorrect behaviour to the user. 2. If you go to the preference setting as described above, and *explicitly choose* ~/Desktop as the download location, Internet Config passes that info to Mozilla which respects it and acts accordingly ON THIS MACHINE. If you log in as the same user, with the same network home directory on a different machine, Internet Config doesn't respect its own preferences. I know why it doesn't, it's a very stupid reason, but it's a MacOS problem not a Mozilla problem. 3. Once you've made the setting in Internet Config as described above, it may lead one to think that the bug cannot be repeated. That is false. Simply remove ~/Library/Preferences/com.apple.internetconfig.plist and logout/login (Darin: if you're testing on my box, reboot it. It should auto-login and restart the VNC server). With everything back to defaults now, the bug should be repeatable. Question: WHY is Mozilla getting any info from here? It ignores every other Mac system thing, but looks at this?!? Since the MacOS Internet Config isn't robust and passes bogus data, why does Mozilla rely on it? Rephrasing my suggestion from Comment #4, is there any way to do an on-the-fly s/Desktop\ Folder/Desktop/g or something similar, to correct for the known bogus data coming from Internet Config? Thanks,
Flags: blocking1.5?
> It ignores every other Mac system thing No, it does not, actually. We get a great deal of info (fonts, helper apps, etc) from the OS. We can't do a string replace, since we're not working with strings but with FSRefs here; a string doesn't even uniquely identify a file on MacOS (though it may on MacOSX, if you use the Unix APIs....) ccing some Mac people to comment; any fix that happens here should be in the directory service, not in the helper app code, of course.
>> It ignores every other Mac system thing > No, it does not, actually. We get a great deal of info > (fonts, helper apps, etc) from the OS. You're absolutely right. I overstated that out of my longing for Moz to integrate with AddressBook.app or iSync, but that's a different issue... ;-) > We can't do a string replace, since we're not working with > strings but with FSRefs here; a string doesn't even uniquely > identify a file on MacOS (though it may on MacOSX, if you > use the Unix APIs....) AH HA! You've exactly hit on the root of why this doesn't work with a network homedir on multiple machines. ~/Library/Preferences/com.apple.internetconfig.plist is an xml file which stores this preference. Instead of doing it the *nix way and storing /path/to/Desktop, it stores: <key>DownloadFolder</key> <dict> <key>ic-data</key> <data> (ABOUT 12 LINES OF BINARY DATA) </data> </dict> ...that 12 lines of binary stuff is the pointer to the folder, which is I assume, what it's passing as the FSRef? If it's set for ~/Desktop on $THISHOST, when you login to $THATHOST it doesn't resolve correctly. This is IMNSHO an error on Apple's part, and Mozilla is basing it's behaviour on that erroneous data. I wish that I could force Mozilla (e.g. in user.js) to use a specific folder regardless of what InternetConfig says.
I think we have bugs (possibly filed against camino) for download folder issues for users with non-standard home dir locations.
Whiteboard: dupme
If this gets a patch we'd consider it for 1.5 but we're not going to hold the release for it.
Flags: blocking1.5? → blocking1.5-
*** This bug has been marked as a duplicate of 200289 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.