User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.8) Gecko/20050427 Camino/0.8.4 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.8) Gecko/20050427 Camino/0.8.4 When attempting to save an attachment from Yahoo Mail to my computer, the correct file is not downloaded. It downloads a file that has no meaning and when clicked, performs no function. Reproducible: Always Steps to Reproduce: 1. Sign up for a Yahoo Mail account at http://mail.yahoo.com 2. Send yourself a file 3. When the message is recieved, open it and attempt to save the attachment Actual Results: Incorrect file downloaded Expected Results: File attached to message should download to computer
WFM, Camino 2005081408 (v0.9a2+), 10.3.9. Please check with Camino 0.9a2 or a current nightly build.
Tried it with a tree I pulled from only a couple of days ago here are my results: Sending plain text files: -Works just fine when you "download file" saves with correct extension .txt -Tried sending myself a .xls excel file and can confirm the results of the bug, file saves without the extension.
Nick, did your test file have a space in it? I just tried "foo.xls" and "2005 Rounds Grid_11_rounds.xls" (note the space between "2005" and "Rounds"); the former downloaded fine, and the latter downloaded as simply "2005". The truncated filename in the latter is a generic Gecko problem with "dynamically served" content whose filenames contain spaces (not sure if there's a core bug on it; I didn't searched thoroughly on it before)--a recent DeerPark exhibits the same problem as this morning's Camino branch. I don't think most files/downloads exhibit problems, just ones with spaces. You can also see this in the attachment to the following bug in the NeoOffice bugzilla http://bugzilla.neooffice.org/bug.php?op=show&bugid=905 Reporter, did the file you attempted to download contain a space in its filename? If you add the appropriate extension, does the file then become useable?
In response to comment 3: My file was name 2002_parts_list.xls -> Note that I tried this in Deer Park Alpha 2, and had the EXACT same results as what happened in my Camino build. So this is a core bug.
I believe the problem arizes from not escaping or quoting the |filename| property of the Content-Disposition header. From NeoOffice bugzilla: Content-disposition: attachment; filename=Campione di NeoOffice:J.txt which should be: Content-disposition: attachment; filename="Campione di NeoOffice:J.txt" Can someone do a "curl -I <yahoo download url"> and see what the Content-Disposition header is like? If the filename is unquoted, please mark this as Tech Evangelism (c.f. bug 235476, bug 293880, etc.).
Looking again, the NeoOffice one is definitely Tech Evangelism, but I'm not so sure about the extension-stripping.
(In reply to comment #6) > Looking again, the NeoOffice one is definitely Tech Evangelism Bug filed at the source; thanks. > but I'm not so sure about the extension-stripping. I still can't repro this; I renamed one of my .xls with Nick's name from comment 4 and still get the proper filename, extenstion included, when using "Save to Computer". curl -I 'url' doesn't return normal headers here (no Content-Disposition, to begin with); do we have to feed it our yahoo cookies somehow to get the proper results?
I just tested this in beta 1, and i cannot reproduce, can someone else confirm as well?
I can't repro either, but then I never could.
Can anyone still reproduce this? If not it should be closed.
Closing WFM. If anyone can reproduce this and give exact steps to do so, feel free to re-open it.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.