293858 - better handling of files downloaded from a webdav server

Status: RESOLVED WONTFIX

(Camino Graveyard :: Downloading, enhancement)

Description

[hg]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.6) Gecko/20050331 Camino/0.8.3
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.6) Gecko/20050331 Camino/0.8.3

if i download a file via a link from a HTML page whos URL (or part of it)
is mounted as a WebDAV Server in the Finder (via DAVfs) the file should not
be downloaded using the downloadmanager. Instead the file should be opened
via a shellexecute in the mounted path.

Reproducible: Always

Steps to Reproduce:
1. Mount a WebDAv Server in the Finder (e.g. iDISK)
2. Download a file from a WebDAV-Server via Camino



Expected Results:  
Shell-Execute on the file in the mounted path

Comment 1

[Mike Pinkerton (not reading bugmail)]

how does one download a file in a web browser from a mounted disk? can you
provide steps to do this?

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

IIRC, this is in essence a dupe of an old bug/discussion about how to deal with
URLs on local filesystems (can't find it now): open the Finder window, or show
the directory listings as a "webpage"/load the file (if the file is
Camino-readable) in Camino.  I believe the debate was resolved in favor of the
latter behavior :-)

Camino behaves the same way with true local volumes as with mounted WebDAV
(iDisk) volumes; it displays the folder hierarchy in the window, loads any
selected file if it's loadable, and downloads stuff it (or plugins) can't handle.

I think this is WONTFIX or INVALID.

Comment 3

[hg]

I think this is different.
If you have a browser-based-grupware (there are tons on sf)
and you have documents assigned to an event or an address (e.g. a
word-file or an excel-sheet as invoice or contract) and you click that link 
to the document, because you want to change the document, todays handling of 
camino is just downloading the file (by default to the desktop) and open it 
with the assosciated application (e.g. ms word / ms excel). If I now change
the file, I change the copy, not the original.

You can imagine IDisk in the above example for the document-server-part.
Mount an apple-IDsik (e.g. http://idisk.mac.com/yourname) put a file on it 
(e.g. a .psd (photoshop-file).
Now create a HTML Page with the file as a link on it e.g.:
<h href="http://idisk.mac.com/yourname/picture.psd">my file</a>

No browser handels this IMHO simple task today.
MS$ tried something with behavior in an anchor, but that does not solve the 
problem either.

Comment 4

[Mike Pinkerton (not reading bugmail)]

so when you click the link, what *exactly* do you want to happen? make an alias
on the desktop to the file on the webdav server?

Comment 5

[hg]

no, an alias would still make a mess on the desktop.

best would be: if part of the URL I am clicking on is in the mount table
(hostname without "http://" - normally just the hostname, in case of iDISK 
"idisk.mac.com/yourname" ), replace "http://idisk.mac.com/yourname" of the URL
with the mountpoint and open the file directly by a shell execute as you do it
on normal downloads, if the checkbox in the settings is checked.
In the iDISK case a URL of "http://idisk.mac.com/yourname/picture.psd" would 
become "/Volumes/idisk.mac.com/yourname/picture.psd"
This means - you need not to care about downloading, because this does macos 
itself now. 
Maybe in conjunction with a checkbox for this behavior in
the settings, so not everybody gets confused :-)

Comment 6

[Mike Pinkerton (not reading bugmail)]

how do we know that idisk.mac.com is a mounted volume short of hardcoding the url?

Comment 7

[hg]

I said nothing about hardcoding the url.
I meant looking up the mount table e.g. via the "mount" command on a shell.
If you have mounted iDisk, open a shell and type mount and you will see,
what I mean. (you can try iDisk for free for 4 week or more, I think)

Comment 8

[Torben]

AIUI, this would have to be done in mozilla code
(nsExternalHelperAppService.cpp) since the download will be started from there
before Camino knows about it. I guess the best solution would be to skip the
download and just show the icon in the download manager (for the unknowing it
would just look like the download was extremely fast). Then we can do whatever
is the user's choosen pref (open or just show the icon and let the user open by
double-clicking or reveal in Finder by clicking the icon). The hard part is
probably how to figure out wheter a file is mounted on the local file system. I
will try to play around with this when I get time (assuming it doesn't get
WONTFIX'ed).

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #8)
> AIUI, this would have to be done in mozilla code
> (nsExternalHelperAppService.cpp) since the download will be started from there
> before Camino knows about it. I guess the best solution would be to skip the
> download and just show the icon in the download manager (for the unknowing it
> would just look like the download was extremely fast). 

Won't this confuse the user when he goes to look in his downloads folder?  Or are we expecting every user is going to then manipulate the file only via the Download Manager buttons?

Comment 10

[Juergen Ebert]

Maybe it is possible to let Mozilla known that the file comes from a WebDAV server? One solution I could image would be sending an OPTIONS request for every downloaded file. If the server acnowledges support of WebDAV than the file should be treated differently from "normal" downloads. It might be stored temporarily but needs to be monitored so it can be sent back to the server when the user application changes the file.
It might be ok to add support of webdav:// urls instead of sending the OPTIONS request.

Comment 11

[Gordon P. Hemsley [:GPHemsley]]

This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX.

[Mass-change filter: graveyard-wontfix-2014-09-24]