Frederic Bezies Reporter
	Description • 17 years ago

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9a9pre) Gecko/2007100414 Firefox/3.0a9pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9a9pre) Gecko/2007100414 Firefox/3.0a9pre

Simple to see. Grab an hourly or a nightly which have bug 396477 checked in.

Go to http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ and try to download a tar.bz2 file.

No download started, file saved is 0 bytes, and you can 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

Reproducible: Always

Steps to Reproduce:
1.See details
2.
3.
Actual Results:  
No download, report in error console.

Expected Results:  
Download !

	Shawn Wilsher :sdwilsh
	Comment 1 • 17 years ago

That error is garbage and can be ignored.  See bug 393627.

	Frederic Bezies Reporter
	Comment 2 • 17 years ago

OK. So it looks like this bug is related to gcc 4.2 x86_64.

gcc-4.2 -v
Utilisation des specs internes.
Cible : x86_64-linux-gnu
Configuré avec: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Modèle de thread: posix
version gcc 4.2.1 (Ubuntu 4.2.1-5ubuntu4)

Invalid bug, I suppose. Sorry for the mess I made with that bug report.

	Shawn Wilsher :sdwilsh
	Comment 3 • 17 years ago

Errr, is that comment meant for this bug?

Anyway, WFM with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a9pre) Gecko/2007100406 Minefield/3.0a9pre

	Frederic Bezies Reporter
	Comment 4 • 17 years ago

But can you try to verify this bug on linux ?

It seems to be a linux only bug !

Anyway, it is buggy with both gcc 4.1 or 4.2 :(

	Frederic Bezies Reporter
	Comment 5 • 17 years ago

Also, there is no association with tar file in application tab in preferences.

Or should I have to remove mimeTypes.rdf to see if it is related ?

	Shawn Wilsher :sdwilsh
	Comment 6 • 17 years ago

oh - 64 bit :/

cc'ing some file handling people who might know what's up...

	Dan Mosedale (:dmosedale, :dmose)
	Comment 7 • 17 years ago

sdwilsh: that exception looks to me as though it's real, and not part of the XPConnect lossage.  See biesi's comment in bug 396477.

	Frederic Bezies Reporter
	Comment 8 • 17 years ago

Remove patch and downloading works again !

Sigh !

I was - unfortunately - right since the beginning for the guilty patch :(

	Shawn Wilsher :sdwilsh
	Comment 10 • 17 years ago

Edward - can you take a look at this since your bug is the one that regressed this?

	Ed Lee :Mardak Assignee
	Comment 11 • 17 years ago

Try/catch it, ignore exception and make it windows only -- this will also fix bug 270159.

	Shawn Wilsher :sdwilsh
	Comment 12 • 17 years ago

Comment on attachment 283923 [details] [diff] [review]
v1

Hrm, seeing as how I missed the implications this code can cause last time, I don't think I'm the best reviewer for this.  Perhaps biesi and gavin should take a look at this?

	Boris Zbarsky [:bzbarsky]
	Comment 13 • 17 years ago

May I recommend actually adding some tests for this?  There's  a history of this exact thing being broken; this is the third or fourth time I've seen it getting fixed, only to get regressed again and again as some new rewrite by some well-meaning Windows user breaks it.

At the very least this needs to be a litmus test; ideally it would be an automated test of some sort.

Ideally, someone would go through the revision history of this file (and better yet the seamonkey version, which has more things in said revision history) and create tests for all that stuff...

	Hussam Al-Tayeb
	Comment 14 • 17 years ago

I got the same bug today on Linux with my gcc 4.2.1 builds. 
I was downloading some mathematica .nb files and they saved as 0kb.
Flushing the cache does not help.
Also, this seems to happen only when I left click on links to start a download and not when I right click on the link and select 'save as'.

	Ed Lee :Mardak Assignee
	Comment 15 • 17 years ago

(In reply to comment #14)
> and not when I right click on the link and select 'save as'.
Correct. The issue only shows up when the app needs to ask to open vs save [exthandler], so if you alt-click or rightclick+saveas [saveURI WBP], you won't run into the issue.

	Stephen Donner [:stephend] Not actively reading bugmail
	Comment 16 • 17 years ago

http://litmus.mozilla.org/show_test.cgi?id=3974

in-litmus+ (we've had this test forever, BTW; I just amended it to include a link Mozilla's FTP server, which it was missing before).

	hhh
	Comment 17 • 17 years ago

(In reply to comment #15)
> (In reply to comment #14)
> > and not when I right click on the link and select 'save as'.
> Correct. The issue only shows up when the app needs to ask to open vs save
> [exthandler], so if you alt-click or rightclick+saveas [saveURI WBP], you won't
> run into the issue.
>The bug title should reflect that.

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 18 • 17 years ago

Comment on attachment 283923 [details] [diff] [review]
v1

>diff --git a/toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in b/toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in

>+      // Try to append a file extension if it's an executable that doesn't have
>+      // one, but don't panic too much if it fails because this is just an
>+      // extra safety precaution for Windows users.

Please either refactor such that the try{} is only around getting primaryExtension, or add a comment explaining the presence of the try/catch (e.g. which part you expect might cause an exception).

>+      try {
>+        let ext = "." + this.mLauncher.MIMEInfo.primaryExtension;
>+        let leaf = aLocalFile.leafName;
>+        if (aLocalFile.isExecutable() &&
>+            leaf.substring(leaf.length - ext.length) != ext) {
>+          var f = aLocalFile.clone();

nit: use "let" :)

	Ed Lee :Mardak Assignee
	Comment 19 • 17 years ago

(In reply to comment #18)
> Please either refactor such that the try{} is only around getting
> primaryExtension, or add a comment explaining the presence of the try/catch
> (e.g. which part you expect might cause an exception).
Refactored and commented.

> >+          var f = aLocalFile.clone();
> nit: use "let" :)
Well, now that I shifted things out of the try block, I don't actually change those lines anymore. ;) I could make it a let if you really wanted. :)

	Ed Lee :Mardak Assignee
	Comment 20 • 17 years ago

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.56; previous revision: 1.55
done

	Stephen Donner [:stephend] Not actively reading bugmail
	Comment 22 • 17 years ago

I got both Ubuntu Fiesty and Fedora Core 7 to pass tar.bz2--through the Open With... dialog--and they all successfully opened with Archive Manager.

Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007102104 Minefield/3.0a9pre 

Verified FIXED (Frederic, please do, of course, chime in by reopening if this still doesn't work for you/your distro).

	Frederic Bezies Reporter
	Comment 23 • 17 years ago

Works flawlessly. Ubuntu Gutsy Gibbon AMD64 FYI :)