151047 - Implement single click download and helper app launch

Status: VERIFIED FIXED

(Camino Graveyard :: Downloading, defect)

Description

[Albert Kammerer]

I am using Mac OS X (10.1.5) and Navigator 0.3.0 (11 June). Downloaded files do
not activate the applicable helper application - most notably Stuffit Expander.

Comment 1

[saari (gone)]

->sdagley

Comment 2

[Steve Dagley]

This isn't external protocol related.  It depends on the nsLocalFileMac rewrite
for the helper app dispatching.

Comment 3

[sairuh (rarely reading bugmail)]

another case of this: clicking a PDF file does nothing. it should launch Preview
(or Adobe Acrobat, if that's being used instead). here's a sample link:

http://hopey.mcom.com/tests/helper-apps/crcflame.pdf

Comment 4

[Greg K.]

Confirmed using Chimera/20020708.

Comment 5

[Steve Dagley]

My assertion that the nsLocalFileOSX landing would fix this wasn't entirely
correct, we still have problems under OS X in uriloader which I'm working on.

Comment 6

[Simon Fraser [no longer active]]

Not critical, putting to major.

Comment 7

[Frank J. R. Hanstick]

Build ID: 2002072308 - Selecting advance in the application request window
enables auto-select of help applications for subsequent downloads of the
associated type; however, the application requesting continues for each
subsequent download even though the "Ask me before down loading this type" check
box is not checked.

Comment 8

[Steve Dagley]

Updated bug summary to describe re-purposing of this bug.  As we have discussed
in the Chimera meetings a single click on a link that invokes a download will
automatically download the file to the user's specified download folder and
invoke the appropriate helper app.  If the user desires UI to prompt for a
different location for the link to be downloaded they'll use the contextual menu
download option

Comment 9

[Steve Dagley]

*** Bug 163687 has been marked as a duplicate of this bug. ***

Comment 10

[john]

Would this also apply to option-click downloads? 

Comment 11

[Steve Dagley]

option-clicking on a link will still bring up the Save As... dialog for the link
target

Comment 12

[john]

Then there is still no single-step way to download and save image, movie and
text files, as well as .dmg & .gz files on misconfigured servers, which is the
functionality I was missing from OmniWeb. Perhaps option-shift-click could
bypass the dialog and route to the downloads folder?

Comment 13

[Steve Dagley]

Is option-click and pick a folder _that_ difficult?  The problem is in the
misconfigured servers, not Chimera.  Which BTW, I'm running into a lot less
these days - YMMV.  Since one of Chimera's goals is to simplify the browsing
experience we do _not_ want to pollute it with all sorts of different ways to
download a file.

Comment 14

[Steve Dagley]

Attachment: makes files automatically DL and helper app launch

With this patch links that would normally be downloaded, e.g. .bin or .gz, will
be downloaded automatically to the user's specified download folder and the
appropriate helper app invoked

Comment 15

[RalphNumbers]

I would advocate making option-click download to the default downloads folder,
without the save as dialog.
That way you could set your destination once for all files, and save a step
every time you download.  This is how I have all my other browsers set up.

Comment 16

[Steve Dagley]

RalphNumbers: File a seperate RFE bug, your request has nothing to do with this
bug (and it's a different code path but that's beside the point :-)

Comment 17

[Steve Dagley]

Removing dependencies: 118203 has been landed in the Chimera branch and the
patch from 162700 is incorporated in the patch for this bug.

Comment 18

[Steve Dagley]

Attachment: Revised patch to address /chimera dir reorg

Same patch as before but updated for new Chimera dir structure.  Makes single
click on a DL link now automatically download thelink to the user's specified
download folder (from the Internet pref pane in System Preferences) and invoke
the appropriate helper app.

Comment 19

[Steve Dagley]

Setting milestone so it'll show up in the right place in my bug queries

Comment 20

[Simon Fraser [no longer active]]

Most of the patch has been checked in, except for the CHBrowserService::Show
part. I'm worried both about how the download dialog UI now matches up with the
behaviour, and about the security implications of launching downloaded files
without user intervention.

Comment 21

[Steve Dagley]

In our more security conscious world I wouldn't disagree that we could test the
DL'd file to see if it's execuatble and not open it if that's the case.  Since
most Mac downloads aren't going to be executable files I don't think this will
be a hinderance to Mac users.

Comment 22

[Winnie Lam]

are we still targetting this for 0.5?

Comment 23

[Steve Smart]

*** Bug 167301 has been marked as a duplicate of this bug. ***

Comment 24

[Steve Dagley]

*** Bug 163886 has been marked as a duplicate of this bug. ***

Comment 25

[Steve Dagley]

This is now fully landed but controlled by the pref implemented for bug #169044

Comment 26

[Chris Petersen]

Verified in the 2002-11-22-04 NB. Helper app automatically launchs when DL is
finished.

Comment 27

[Thomas Castiglione]

Only partially fixed for me in 2002112204. At
http://homepage.mac.com/castiglione/ clicking on "Source Code: ServicesMenu.sit"
downloads ServicesMenu.sit and launches Stuffit Expander; however, clicking on
"Download FocusLayer v1.2" downloads FocusLayer.dmg but does not open it with
Disk Copy or anything else.

Comment 28

[Steve Dagley]

That could actually be considered a security 'feature' as automatically mounting
a disk image could result in an application being run from the image without the
user's awareness.  Not that we're doing this on purpose so I do need to find out
what's happening in uriloader to cause it.

Comment 29

[Jon Baumgartner]

This doesn't work for me at all with 2002112204. Files get downloaded, but no
post-processing occurs. I added the browser.download.autoDispatch line to my
user.js file.