Closed Bug 398551 Opened 14 years ago Closed 14 years ago

Cannot download tar.gz or tar.bz2 files from the "Open with" dialog

Categories

(Toolkit :: Downloads API, defect)

x86
Linux
defect
Not set
major

Tracking

()

VERIFIED FIXED
mozilla1.9beta1

People

(Reporter: fredbezies, Assigned: Mardak)

References

Details

(Keywords: regression)

Attachments

(1 file, 2 obsolete files)

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 !
Depends on: 396477
Flags: blocking-firefox3?
Keywords: regression
That error is garbage and can be ignored.  See bug 393627.
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.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
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
Keywords: qawanted
Flags: blocking-firefox3?
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 :(
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
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 ?
oh - 64 bit :/

cc'ing some file handling people who might know what's up...
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.
Remove patch and downloading works again !

Sigh !

I was - unfortunately - right since the beginning for the guilty patch :(
Duplicate of this bug: 398917
Edward - can you take a look at this since your bug is the one that regressed this?
Flags: blocking-firefox3?
Target Milestone: --- → Firefox 3 M9
Attached patch v1 (obsolete) — Splinter Review
Try/catch it, ignore exception and make it windows only -- this will also fix bug 270159.
Assignee: nobody → edilee
Status: REOPENED → ASSIGNED
Attachment #283923 - Flags: review?(comrade693+bmo)
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?
Attachment #283923 - Flags: review?(comrade693+bmo)
Attachment #283923 - Flags: review?(gavin.sharp)
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...
Flags: in-testsuite?
Flags: in-litmus?
Flags: blocking-firefox3? → blocking-firefox3+
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'.
(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.
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).
Flags: in-litmus? → in-litmus+
(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.

Summary: Since checkin for bug 396477 it is impossible to download tar.gz or tar.bz2 files. → Cannot download tar.gz or tar.bz2 files from the "Open with" dialog
Version: unspecified → Trunk
Whiteboard: [has patch][need review gavin]
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" :)
Attachment #283923 - Flags: review?(gavin.sharp) → review+
Whiteboard: [has patch][need review gavin] → [has patch, review]
Attached patch v1.1 (obsolete) — Splinter Review
(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. :)
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
Status: ASSIGNED → RESOLVED
Closed: 14 years ago14 years ago
Keywords: qawanted
Resolution: --- → FIXED
Whiteboard: [has patch, review]
Attached patch as checked inSplinter Review
Attachment #283923 - Attachment is obsolete: true
Attachment #285491 - Attachment is obsolete: true
Blocks: 270159
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).
Status: RESOLVED → VERIFIED
Works flawlessly. Ubuntu Gutsy Gibbon AMD64 FYI :)
Product: Firefox → Toolkit
Regressions: 1558251
No longer regressions: 1558251
You need to log in before you can comment on or make changes to this bug.