239948 - The open button (link) doesn't work for old Downloads in Mac OS X / Linux

Status: RESOLVED FIXED

(Toolkit :: Downloads API, defect)

Description

[Asaf Romano (gone)]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040405 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040405 Firefox/0.8.0+

There in no response for clicking the Open Link on the Download Managesr when
trying to open a one which wasn't downloaded at a previous launch of Firefox.

Note the the "Open containing folder" doesn't wotk too (at the same cases).

Reproducible: Always
Steps to Reproduce:
1. Download a file
2. Relauch Firefox (Quit first :) )
3. Go to the Download Manager
4. Click on the "Open Link" for the file you downloaded at step 1

Actual Results:  
Nothing happen....

Expected Results:  
The file should be opened as for downloaded files from the same launch.

Comment 1

[Asaf Romano (gone)]

I found some direction:
When a download is finished, it's file name is saved in the format of
"/folder/folder....", in this status I can open/show the file.

BUI when I relauch firefox, the address of the file (in its properties window)
is attached with "file://". At this point, even if I copy the link into the
browser addrees-bar, Firefox fails to locate the file.

It seems that this bug is a result of bug 189350, and it depends on it.
 

Comment 2

[Asaf Romano (gone)]

After a little research:
 1. The problem is a result of the "file://" issue, but it's not related to bug
189350.
 2. "file://" is added only in the mac version of firefox.
 3. When nsLocalFile::InitWithPath method (which is called by
nsILocalFile.initWithPath) is called with  "file://" address, it will ALWAYS
return NS_ERROR_FILE_UNRECOGNIZED_PATH - I reported a separate bug for this
issue - see bug 240269 and the following log (a result of this bug):
************************************************************

* Call to xpconnect wrapped JSObject produced this error:  *

[Exception... "Component returned failure code: 0x80520001
(NS_ERROR_FILE_UNRECOGNIZED_PATH) [nsILocalFile.initWithPath]"  nsresult:
"0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH)"  location: "JS frame ::
chrome://mozapps/content/downloads/downloads.js :: onDownloadOpen :: line 271" 
data: no]

************************************************************

Comment 3

[Asaf Romano (gone)]

Bug 240269 wont be fixed. Do anybody have an idea why mac-firefox add the "file://"?

Comment 4

[sairuh (rarely reading bugmail)]

now that bug 249654 is fixed for linux, I think this bug is cropping up on that
OS as well. tested with 2004102109-0.9+ on fc2.

to repro:

1. save a web page (I do so to my Desktop; don't think the location matters).

2. when the download is finished, click the "Open" link next to the file in the
Downloads dialog. (click "launch application" in the resulting External Protocal
Request dialog, if prompted.) as expected, the page is opened in Firefox, since
that app handles .html files on my system (I had set it as my default web browser).

3. quit and restart Firefox.

4. bring up the Downloads dialog. the web page I had saved is still listed
there, as expected.

5. click the "Open" link.

expected: the page should open in Firefox.

actual results: nothing happens. alas, nothing appears in the JS console either.

would it be possible to get this fixed in time for aviary1.0?

Comment 5

[chris hofmann]

dmose, can you have a look?

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

What I _think_ is going on is this (I haven't verified every chunk of this yet):
nsIRDFService allows for resources to be non-canonicalized URIs.  The download
manager code depends on this, and asserts raw pathnames into the datasource. 
Then, at quit time, nsRDFXMLSerializer causes the raw pathnames to be
canonicalized into full file: URLs.  So when the datasource gets read in at the
next startup, it gets the file: URIs, which is not what the download manager
code is expecting.

I suspect the right fix for this is going to be make the download manager use
and assume fully canonicalized URIs everywhere, extracting paths by hand where
necessary.

If I'm right, I wonder if, long-term, RDF shouldn't refuse to accept
non-canonical URIs.

Comment 7

[Axel Hecht]

This is one of the more tricky things in getting RDF to conform to the current
specs. We heavily abuse the fact that we don't require real URIs for resources
in mozilla, namely, for persistance in XUL. We just copy over the attr name, 
which bails in RDF conformance tests. (In localstore.rdf, I'm not too clear 
about this here.)

I have no idea if we want to fix it, how much of a performance hit in 
persistance we'd take, if we stick to localstore.rdf for that at all and 
whatnot.

Anyway, if we have clients of RDF that can be moved over to real URIs, I'm all 
for it. Esp in this particular case, which is much less performance critical 
than localstore.

Comment 8

[Benjamin Smedberg]

FWIW, we should *not* require any knowledge of real URIs. I run across problems
using ISAVIS all the time where we use chrome:// URIs as resources and java
complains that it's not a valid URI.

Where does the XMLRDF serializer canonicalize? That sounds odd to me. I would
actually expect the XMLRDF to be the culprit.

Comment 9

[Benjamin Smedberg]

I meant to say "the RDFXML parser".

Comment 10

[chris hofmann]

if we can get a low risk change we will probably take it.

Comment 11

[Dan Mosedale (:dmosedale, :dmose)]

bsmedberg was right; the normalization was happening the first time the RDF/XML
datasource was read in, though I was not able to track down exactly where (not
in rdf_MakeAbsoluteURI, which is where I would have expected).

Comment 12

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: partial fix, v1

As mentioned earlier, the right fix is probably to use fully-qualified
resources URLs all the time.  However, since time is short, and risk-tolerance
is low, the best we can afford now is a hack fix: when we get a "path" that we
need to open, first check to see if it's really a URL, and then deal with it
appropriately.

One potential problem is that I'm passing a null charset to
nsIIOService::NewURI(), and I don't have a high degree of confidence that
that's the right thing to do.  If someone has a better suggestion, I'd be
interested in hearing it...

Comment 13

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 163381 [details] [diff] [review]
partial fix, v1

r+a=[e-mail]

Comment 14

[Dan Mosedale (:dmosedale, :dmose)]

Partial fix checked into both the branch and trunk.  Leaving open because we
need to do better for the trunk going forward...

Comment 15

[sairuh (rarely reading bugmail)]

so far the fix looks good on linux fc2 2004102609-0.11. thanks, dmose!

marcia is looking on mac now...

Comment 16

[Marcia Knous [:marcia]]

fix looks good on Mac, using 2004-10-26-06-0.11/

Comment 17

[Asa Dotzler [:asa]]

moving blocking1.0mac bugs to Firefox1.1 Target Milestone.

Comment 18

[Dan Mosedale (:dmosedale, :dmose)]

Talked to asa, unset the blocking-aviary1.1 flag because the existing fix is
good enough to not block.  Reassigning to nobody, as I'm not gonna have time to
work on it anytime in the near future.

Comment 19

[Tracy Walker [:tracy]]

This is broken on current Linux Deer Park builds.  The Open link in download
manager does nothing.

Notes: using context click to "Open containing folder"  does work as expected.
Mac Open link works as expected.

renominating for 1.5

Comment 20

[Mike Connor [:mconnor]]

WFM on FC4, minusing, please provide details on what fails and environments on
Linux tested and nominate for b4 if there's a clear problem.

Comment 21

[Tracy Walker [:tracy]]

hmmm, this is working for me now with linux DP build 2005-08-10-05-trunk (FC3)

Comment 22

[Tracy Walker [:tracy]]

bizarre, this is not working with Linux (FC3) DP build 2005-08-11-05-trunk

Comment 23

[Shawn Wilsher :sdwilsh]

WFM on Windows Vista on trunk
WFM on Windows Vista migrating from 2.0 to 3.0
WFM on OS X 10.4 in Firefox 2.0
WFM on OS X 10.4 in trunk

Was this fixed?

Comment 24

[Shawn Wilsher :sdwilsh]

This was certainly fixed by Bug 388517 when we started to use commands and check if the file exists for open to determine if the command is enabled.