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)
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.
| Reporter | ||
Comment 2•23 years ago
|
||
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?
| Reporter | ||
Comment 4•23 years ago
|
||
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.
| Reporter | ||
Comment 6•23 years ago
|
||
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
Comment 7•23 years ago
|
||
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.
Comment 8•23 years ago
|
||
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.
| Reporter | ||
Comment 9•23 years ago
|
||
This is still happening. Is there any resolution in the works? Haven't seen
any activity here recently...
Thanks.
Comment 10•23 years ago
|
||
this behaviour is addressed for camino in bug 204548. should we merge the two
bugs or keep them separate?
Comment 11•23 years ago
|
||
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.
| Reporter | ||
Comment 12•23 years ago
|
||
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?
Comment 13•23 years ago
|
||
> 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.
| Reporter | ||
Comment 14•23 years ago
|
||
>> 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.
Comment 15•23 years ago
|
||
I think we have bugs (possibly filed against camino) for download folder issues
for users with non-standard home dir locations.
Whiteboard: dupme
| Assignee | ||
Comment 16•23 years ago
|
||
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-
Comment 17•22 years ago
|
||
*** This bug has been marked as a duplicate of 200289 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Updated•21 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•