JDK-6508888 : Desktop.browse("file:///C:/Foo.txt") does not work on Windows
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6,6u3
  • Priority: P3
  • Status: Closed
  • Resolution: Other
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-01-02
  • Updated: 2016-03-08
  • Resolved: 2016-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6-poolResolved
Related Reports
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

EXTRA RELEVANT SYSTEM CONFIGURATION :
Tried with both Internet Explorer 7 and with Firefox 2.0. Same results.

A DESCRIPTION OF THE PROBLEM :
The method java.awt.Desktop.browse(URI) does not work for "file:" URI's on Windows XP.

I have the following line of code in my program (a standalone Java application):

        Desktop.getDesktop().browse( new URI( "file:///C:/TestMe.html" ) );

I expect that this should launch my default browser, and open a web page containing the contents of the file "C:\TestMe.html". It does not. No exceptions are thrown, but the browser is not opened (or if it is already open, then the browser is not affected by the Java code's execution). Note that if I open the browser manually and paste the "file:///C:/TestMe.html" URI into it, it opens the page correctly.

I have tried this with IE7 and with FireFox 2.0 set as my default browser and in both cases, the behavior is the same: nothing happens when the 'browse' method is called.

Note that I get the same results for the URI "file:/C:/TestMe.html" as I do for the URI "file:///C:/TestMe.html".

If I name a file that does not exist, such as "file:///C:/TestMe2.html", then the browse method throws an IOException indicating that the file does not exist. So the JDK clearly can find the file. It just is unsuccessful at launching the browser on it.

If I use the browse method to launch a web page on the Internet via a URI such as "http://java.sun.com", then the 'browse' method works as expected. So the JDK clearly can launch the browser correctly for _some_ URI's, as long as they are not using the "file:///" protocol.

It is severely annoying not to be able to open a web browser to browse local files! Please fix this ASAP!!!

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1) Create a file, C:\TestMe.html, containing a typical HTML web page, on a Windows XP system, with one of the two browser types described above set as the default.

2) Execute the following line of Java code:

        Desktop.getDesktop().browse( new URI( "file:///C:/TestMe.html" ) );

3) Observe that no exception is thrown, and no browser is showing the indicated file.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The browse method should open a browser as it is documented to do, or should throw an exception explaining why it didn't. .
ACTUAL -
Nothing happens as a result of the method call.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
No error messages occurred, and no log file was created.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.net.URI;
import java.awt.*;
import java.io.IOException;

public class Main
{
    private Main()
    {
    }

    public static void main( String[] args ) throws IOException
    {
        Desktop.getDesktop().browse( new URI( "file:///C:/Temp/TestMe.html" ) );
    }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
None so far.
Just got a report from a CAP member that this problem comes back again on certain machines -

J2SE Version (please include all output from java -version flag):
  java version "1.6.0_03"
  Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
  Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing)

Does this problem occur on J2SE 5.0.x or 6.0?  Yes / No (pick one)
  Yes

Operating System Configuration Information (be specific):
  Microsoft Windows XP [Version 5.1.2600]

Bug Description:
  Desktop methods have stopped working on some computers

This is a Duplicate of 6508888 which was closed as not reproducible.

On my computer these methods were working with Java Versions 1.6.0-b49 
to 1.6.0_03-b05 until today.

Note: I have tested on another computer which is also running Microsoft 
Windows XP [Version 5.1.2600] and the tests still work on that computer
I have gone back and tested with each of these versions (using the same 
code and test files) and now the Desktop methods are no longer 
working on any of them.

It worked with 4 different JDKs and JREs, both running normally and also 
running from custom launchers all on a certain computer, and then since 
Sunday(11/25) it has not worked with any of them. On another computer with 
the same configuration they all still work. As noted the url.dll still works, 
so I am guessing that Sun is using some other dll or relying on some registry 
settings which have been changed by something else on my computer - I think 
Windows automatically updated itself between the last time it worked and when 
it stopped working - in which case I am concerned that it will start happening 
on our Customers computers. As the problem is on my computer (and it happens 
every single time) I can do any tests or check anything in the registry that 
the Sun Engineer would like for me to check for. 

Tests that were working that now fail: (no exception, the methods just return and don't do anything)
browse(file.toURI()); where file points to any file .txt or .htm
open(file); where file points to any file .txt or .htm
edit(file); where file points to any file .txt or .htm

The following tests still work:
Runtime.getRuntime().exec("rundll32 url.dll,FileProtocolHandler " + file.toURI());
browse(new URI(website)); where website is an http address
CAP member just report that the same problem still exist with 6u4 build12.

Comments
Not applicable anymore.
08-03-2016

SUGGESTED FIX Suggested fix from the CAP member: assume that Sun is natively calling shell32.ShellExecute. I have run some tests on the computers where the open(), edit() etc are not working and discovered the following results: *calling shell32.ShellExecute(null, verb, file.toURI().toString(), null, null, SW_SHOWNORMAL); // works fine for when verb is null, however if verb is not null then it returns 42 and does not do anything (the specification of this method says that any number greater than 32 indicates that it worked fine, however when it actually does work fine [like in the case below]) it returns 33 * calling shell32.ShellExecute(null, verb, file.getPath(), null, null, SW_SHOWNORMAL); // works fine for each of the verbs with an association and also using null as a verb (it returns 33 and opens, edits or prints the requested file) According to the specification: 'A pointer to a null-terminated string that specifies the file or object on which to execute the specified verb', it looks like Sun should be using file.getPath(). Due to the results I am seeing I believe that Sun is using file.toURI().toString() instead. Assuming this is the case then all they would need to do is replace file.toURI().toString() with file.getPath(). If for some reason they need to use file.toURI().toString() then best would be to use file.getPath() and if that returns an error code (32 or less) then to try file.toURI().toString(). Not ideal but would solve the problem on this computer would be using file.toURI().toString() checking for the result of 42 and if it is 42 then trying with file.getPath().
10-02-2009

EVALUATION This looks very close to what described in 6599987.
29-11-2007