User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007091705 Minefield/3.0a8pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007091705 Minefield/3.0a8pre Since the landing of Bug 395308 executable files are renamed with a dual extension, .exe.exe. Other file types seem unaffected. Reproducible: Always Steps to Reproduce: 1. download .exe file 2. 3. Actual Results: .exe file is renamed filename.exe.exe Expected Results: File should be saved as original file name.

This also happens with other file types, at least under Windows. To make things even worse: If you try to save a file overwriting an existing file with the same name, Firefox asks if the existing file should be replaced but instead, the downloaded file is renamed and it is given the double extension. See my attachment (Screenshot).

Still present under Vista and Vista SP1 on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a8pre) Gecko/2007091904 Minefield/3.0a8pre

Just to clarify - is this windows only? If so, I think I see what *may* be the problem, but I'm not 100% sure still. For my reference: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp&rev=1.345#2096

Looks like it is windows only since I cannot reproduce this on my mac.

What other bugs landed in this window? I'm not really sure if Bug 395308 actually caused this...

Regression window: http://tinyurl.com/2jpte5

It's present on Linux. Happened a few times for me. I just downloaded a gzip archive and ended up with .tar.gz.gz. Interestingly, it also appends .exe to any binary file -- for example, .iso.exe.

I'm seeing something odd here: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpcom/io/nsLocalFileOS2.cpp&rev=1.96&root=/cvsroot#2167 There once was a return there, maybe that's the culprit. If I'm correct, this file is not only about OS/2 filename stuff?

This is about in general, though I haven't been able to reproduce it on the mac (I haven't tried a tar.gz file however).

Definitely regressed with bug 395308 because now tempFile.isExecutable() doesn't work.

Don't use this.mLauncher.targetFile.isExecutable because it'll give us the wrong information. Append the primary extension only if it doesn't already have it.

These tryserver builds have bug 396477 and bug 396701 potentially fixed. win32: https://build.mozilla.org/tryserver-builds/137-edward.lee@engineering.uiuc.edu-firefox-try-win32.installer.exe macosx: https://build.mozilla.org/tryserver-builds/130-edward.lee@engineering.uiuc.edu-firefox-try-mac.dmg linux: https://build.mozilla.org/tryserver-builds/130-edward.lee@engineering.uiuc.edu-firefox-try-linux.tar.bz2

Comment on attachment 283067 [details] [diff] [review] v1 r=sdwilsh

Testing with WinXP Pro SP2, with Mardak test build. As far as I can tell, it's fixed.

Checking in toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in; /cvsroot/mozilla/toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in,v <-- nsHelperAppDlg.js.in new revision: 1.54; previous revision: 1.53 done

Seems to break double extension file downloading. Try to download firefox-3.0a9pre.en-US.linux-i686.tar.bz2 from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ And you'll get this in error console : Error: [Exception... "Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIMIMEInfo.primaryExtension]" nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)" location: "JS frame :: file:///home/fred/Applications/firefox/components/nsHelperAppDlg.js :: anonymous :: line 219" data: no] Source File: file:///home/fred/Applications/firefox/components/nsHelperAppDlg.js Line: 219 Reopening and backing out the patch could be a good idea ? Because it is a big regression :(

WFM with 2007100304 and 2007100405 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Minefield/3.0a9pre

(In reply to comment #18) > Error: [Exception... "Component returned failure code: 0xc1f30001 > (NS_ERROR_NOT_INITIALIZED) [nsIMIMEInfo.primaryExtension]" nsresult: > "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)" location: "JS frame :: > file:///home/fred/Applications/firefox/components/nsHelperAppDlg.js :: > anonymous :: line 219" data: no] > Source File: > file:///home/fred/Applications/firefox/components/nsHelperAppDlg.js > Line: 219 This error is garbage and is safe to ignore (see bug 393627).

But the problem stays the same. I CANNOT donwload any file ending with tar.bz2 or tar.gz :(

I'm assuming you're running linux? WFM Windows and Mac OS X -- I can't get trunk running on Linux.

sdwilsh: that isn't the handlerservice error...

I've seen that since that code landed - I was under the impression that it was the same cause...

Erh... I thought it was related to gcc 4.2 under Gutsy AMD64. But with gcc 4.1, same problem. No file could be downloaded if it is ended like tar.bz2 / tar.gz. Could be a AMD64 bug ?!

sdwilsh: You can't assume that a mime info has a primary extension

Sorry to say that reversing the patch makes downloading working fully and completely again. Strange !

Frederic: Can you confirm that you're running firefox on linux -- and would you happen to be saving to a mounted drive that has the executable bit incorrectly set? (Or perhaps your umask has things created with executable set.) biesi: If we can't grab the primary extension, we should probably still try putting on some extension to prevent the user from accidentally creating an executable? E.g., saving a .torrent file as .exe. But then what extension should we use if we couldn't get the primary extension? Take the source's? And I suppose we could make this Windows only for bug 270159.

I am using Ubuntu Gutsy Gibbon AMD64. $ uname -a Linux fredo-gutsy 2.6.22-12-generic #1 SMP Sun Sep 23 20:03:18 GMT 2007 x86_64 GNU/Linux I want to save every single download on my main partition, in a directory named download. Here are the sets of my download directory : $ ls -al download total 12 drwxr-xr-x 2 fred fred 4096 2007-10-04 21:06 . drwxr-xr-x 50 fred fred 4096 2007-10-05 10:22 .. -rw-r--r-- 1 fred fred 1039 2007-10-04 19:59 exe.exe.patch

I'm confused; is it safe to verify this, since it's now working fine on Windows using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007101905 Minefield/3.0a9pre, (and do we need to then spin off a bug for comment 29 and others), or are we going to address Frederic's issues here?

(In reply to comment #30) > I'm confused; is it safe to verify this, since it's now working fine on Windows > using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) > Gecko/2007101905 Minefield/3.0a9pre, (and do we need to then spin off a bug for > comment 29 and others), or are we going to address Frederic's issues here? He needs to file a different bug if he didn't already. This bug can be verified.

Verified FIXED on Windows Vista; see comment 30.

This bug is fixed, mine is 398551. And it is kinda pain-in-the-*** to say the least :(

in-litmus+ https://litmus.mozilla.org/show_test.cgi?id=4994