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.

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.

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] ************************************************************

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

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?

dmose, can you have a look?

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.

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.

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.

I meant to say "the RDFXML parser".

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

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).

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 on attachment 163381 [details] [diff] [review] partial fix, v1 r+a=ben@mozilla.org

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

so far the fix looks good on linux fc2 2004102609-0.11. thanks, dmose! marcia is looking on mac now...

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

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

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.

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

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.

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

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

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?

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.