827164 - Double-click to open exe downloads not working

Status: VERIFIED FIXED

(Firefox :: Downloads Panel, defect, P1)

Comment 1

[Jim Jeffery not reading bug-mail 1/2/11]

Bug 826425 was supposed to add the function to double-click a download in the Library and open that file.  It does not work as intended. 

A downloaded zip file will open Winzip if installed on your system, but .exe files will not open and kicks errors as described below.


The 'double-click' to open seems to be intermittent.  I just downloaded another build file from a day or so ago (regression testing) and double-clicking did NOT open as expected and as I stated above about only working with 'New Downloaded Files'.

I also see these errors in Error Console2:

this appears on first open of the Show all Downloads:
Error: TypeError: view.selectNode is not a function
Source file: chrome://browser/content/places/places.js
Line: 64


This error appears when double-clicking a file:
Error: TypeError: this.dataItem is undefined
Source file: resource://gre/modules/DownloadsCommon.jsm
Line: 431

STR:
1. Download a file say from here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1357497244/  win32.exe file
2. When complete open the Library using the 'show all downloads' under the Download button.
3. Double-click that file - does not open
4. Open the Error console and observe the above errors.

Comment 2

[Marco Bonardo [:mak]]

Just as a clarification, are you saying only exe files show the problem or it's intermittent on any kind of file?
If you wait a couple seconds after opening the view before trying to open the download, does it work?

Comment 3

[Jim Jeffery not reading bug-mail 1/2/11]

(In reply to Marco Bonardo [:mak] from comment #2)
> Just as a clarification, are you saying only exe files show the problem or
> it's intermittent on any kind of file?
> If you wait a couple seconds after opening the view before trying to open
> the download, does it work?

Quick testing before I went to work I find the following:

1. .exe files will not open and kick the 
Error: TypeError: this.dataItem is undefined
Source file: resource://gre/modules/DownloadsCommon.jsm
Line: 431

2. pdf files open ok

3. zip files open ok 

Does not make any difference that I can detect on how long I wait before attempting to open the file.

Comment 4

[Marco Bonardo [:mak]]

makes sense, this is wrong:

439       if (showAlert) {
440         let name = this.dataItem.target;

it has been copied over and not updated, we can likely just use aFile.leafName

Comment 5

[Marco Bonardo [:mak]]

moved the selectNode warning to bug 827293 since looks like more complicated and in need of some view pseudo-api change.

Comment 6

[Marco Bonardo [:mak]]

Attachment: patch v1.0

Comment 7

[Asaf Romano (gone)]

Comment on attachment 698792 [details] [diff] [review]
patch v1.0

Review of attachment 698792 [details] [diff] [review]:
-----------------------------------------------------------------

oops.

Comment 8

[Jim Jeffery not reading bug-mail 1/2/11]

I stated in comment #3 that pdf's were working.  Further testing I have found it only will open from the Library via double-click IF tried during the session.

Closing the browser and then re-starting and opening the Library->Downloads the pdf will NOT open.  No errors in the console other the select-node error in bug 827923

Comment 9

[Marco Bonardo [:mak]]

(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #8)
> I stated in comment #3 that pdf's were working.  Further testing I have
> found it only will open from the Library via double-click IF tried during
> the session.

WFM, though it opens them with the system pdf handler, that is Adobe Reader in my case.  If you just have pdf.js it's possible won't find an handler in the system. something different from the original issue here.

Comment 10

[Marco Bonardo [:mak]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/de8c4a52722e

Comment 11

[Jim Jeffery not reading bug-mail 1/2/11]

Tested using the hourly build on m-i using build cset:
http://hg.mozilla.org/integration/mozilla-inbound/rev/77aed33eead5

which contains the this patch.  Now the double-click to open the file works as expected, and throws the warning 'dialog box' giving the usual warning about directly opening exe files. 

Great job, and thanks for the quick fix guys.

Comment 12

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/de8c4a52722e

Comment 13

[Marco Bonardo [:mak]]

Comment on attachment 698792 [details] [diff] [review]
patch v1.0

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Downloads panel feature
User impact if declined: Not working UI
Testing completed (on m-c, etc.): m-c
Risk to taking this patch (and alternatives if risky): Not working UI
String or UUID changes made by this patch: none

Comment 14

[Marco Bonardo [:mak]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/bef5ca4854d6

Comment 15

[Simona Badau, Desktop QA]

Verified as fixed on the latest Nightly and on the latest Aurora - double clicking on finished downloads opens them (exe, dmg, tar.bz2. webm, png, pdf, html, txt)

Verified on Mac OS X 10.7.5, Ubuntu 12.10 and Windows 7:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:20.0) Gecko/20130115 Firefox/20.0 20130115042018
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:21.0) Gecko/20130115 Firefox/21.0 20130115030936

Mozilla/5.0 (X11; Linux i686; rv:20.0) Gecko/20130115 Firefox/20.0 20130115042018
Mozilla/5.0 (X11; Linux i686; rv:21.0) Gecko/20130115 Firefox/21.0 20130115030936

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130115 Firefox/21.0 20130115030936