Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 77 users
Status: Available
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

issue 68200

Sign in to add a comment
Chrome does not launch Java automatically for JNLP resources
Reported by, Aug 14 2011 Back to list
This bug has been reported earlier as  Issue 10877 , which has been marked as fixed, but is still occurring. Please reopen the originally reported bug and merge this report with it.

Chrome Version       : 13.0.782.112
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 4:
  Firefox 3.x: OK
         IE 7: OK
         IE 8: OK

What steps will reproduce the problem?
1. Access any JNLP file
2. Chrome downloads JNLP file as if any other resource
3. Chrome does not start Java
4. User must click on JNLP file to start Java and associated app

What is the expected result?

Chrome should start Java automatically for the JNLP resource

What happens instead?

Chrome downloads the JNLP file to the file system

Please provide any additional information below. Attach a screenshot if
Comment 2 by, Sep 25 2011
Labels: -Area-Undefined Area-Internals Feature-Downloads
See also  issue 10877 .
@marco.tiemann: To confirm, you have set "always auto-open files of this type" for .jnlp files?  

Also, what OS are you on?  Chrome's opening behavior delegates the actual open of the file to the OS; does your OS know how to open .jnlp files?

Works in IE9 but not in Chrome. Enough said!
If I get no response to my question in c#3 I'll close this bug.  The way this behavior is supposed to work is a) If you have auto-open files of this type set for .jnlp files, and b) if your OS knows how to open .jnlp files, those files should be auto-opened on download.  If that isn't what's happening, we'd love to work with you to understand and fix it.  If it is what's happening, that's working as designed, and while you're welcome to make an argument for changing the behavior, it'll be an uphill battle (as two of Chrome's three core values are involved here: security, and simplicity).  

Does anyone have the experience that their OS knows how to open JNLP files, that those files are marked to auto-open in Chrome, and they aren't being auto-opened?

@rdsmith I can confirm that this bug indeed is present in both Windows and Mac version of chrome. Jnlp files are downloaded instead of being opened in Chrome even though the default OS behavior is top open jnlp when Java Web Start. 

It will work if after the jnlp is downloaded, you click on the arrow then select "Always open files of this type". But that open should be selected by default otherwise chrome default behavior is different than OS default behavior.

Another bug is that even when "Always open files of this type" is selected it seem to first "download" the jnlp and then open it which would cause the current directory to be set to "downloads" folder. But in IE it opens jnlp in such a way that the currently directory is the http website address that hosts the jnlp. The IE behavior is the correct behavior and chrome should behave the same way.

So please do not close this bug. This is indeed a bug and needs to be fixed.
> It will work if after the jnlp is downloaded, you click on the arrow then select "Always open files of 
> this type". But that open should be selected by default otherwise chrome default behavior is 
> different than OS default behavior.

I'm sorry; that's the intended behavior and we will not be changing it.  There are serious security implications of always opening .jnlp files.  If the user explicitly requests the behavior, we'll do it for that.  But we won't pre-open that security hole.

> Another bug is that even when "Always open files of this type" is selected it seem to first 
> "download" the jnlp and then open it which would cause the current directory to be set to 
> "downloads" folder. But in IE it opens jnlp in such a way that the currently directory is the http 
> website address that hosts the jnlp. The IE behavior is the correct behavior and chrome should 
> behave the same way.

That's interesting behavior; we probably won't be able to match it (it sounds like IE is opening the jlp file itself) but I'd like to understand it.  What does "the current directory to is the http website address" mean?  That if you open files, that activity goes to the network and by default accesses file on the website from which the application came?

Yes, if for example my test.jnlp file resides in and inside of the jnlp file I refer to a library files with relatives paths for example lib/mylibrary.jar then IE understand that I am referring to the remote jar file where as chrome thinks that I'm referring to C:\Users\snourian\Downloads\lib\mylibrary.jar which of course doesn't exist.

Another bug is that even after selecting "Always open files of this type" the file test.jnlp is downloaded once per click. So given a url link that refers to test.jnlp, if the user clicks on that link 100 times he/she will notices the "downloads" folder filled with these files:


This behavior will be annoying to users because they never intend to download the files yet they get a messy downloads folder.
Comment 9 by Deleted ...@, Oct 18 2011
The main problem is, that it does not work even if i select "Allways Open".

Case Dell iDrac 6.

I try to open a remote console and chrome does download files named like "viewer.jnlp(,+PowerEdge+R310,+User-root@1318962734584)"
the number does change with each request and it does not open at all - no request on how it should open it.

Chrome 14.0.835.202 m
Comment 10 Deleted
@m.bos it seems to me that your problem is due to the filename not have a jnlp extension. Instead it has a jnlp(192....( extension. 

Try this jnlp:
In the above page click on "Web Installer" link which points to a jnlp file and see if it downloads and opens after clicking on the downloaded file.
Comment 12 Deleted
Comment 13 by, Oct 18 2011
To add to this discussion, when using web launch, if "Ask where to save each file before downloading" is selected, Chrome will prompt the user to save the .jnlp file to a directory. Is this the intended behaviour? I don't want to "save" the file-- I want to launch it and not worry about my local file system. Does the Chrome team distinguish this use case?

Chrome 15.0.874.832 beta-m
@rdsmith I'm not sure if I agree with this statement:

> I'm sorry; that's the intended behavior and we will not be changing it.  There are 
> serious security implications of always opening .jnlp files.  If the user explicitly 
> requests the behavior, we'll do it for that.  But we won't pre-open that security 
> hole.

Java webstart and jnlp has some of the strictest security sandbox that you can find anywhere. If the jnlp needs to perform any tasks that even slightly jeopardize security or privacy then it needs to be signed and the security risk will be prompted to the user.

It also doesn't make any difference if it gets downloaded first and then ran by a click or if it runs by clicking on a link on the website. Either way if poses a same security risk. That is it will only be a risk if the use decided to ignore the risk warning and allow risky operation by explicitly trusting the signature.
Responding to a couple of different threads:

+ The .jnlp program "seeing" the directory environment of its original web page rather than that of the directory into which it's downloaded: That's fascinating and useful behavior, but it needs to be implemented by the program actually executing the .jnlp file.  It "feels" like something that IE might implement by hosting the .jnlp execution itself; has anyone seen this behavior outside of IE?  If it's executed in an external program (Java WebStart) maybe the browser communciates with the external program in some way that we're not aware of.  So I'd be interested in any details people have about that behavior such as what browser/OS combinations it's been seen in.

This is a use case I wouldn't mind supporting in chrome if someone can tell me how it works/offer patches.  But please check in on the approach before offering patches--I don't want anyone wasting their time on something we're not going to put in.

+ The .jnlp files being downloaded with "(a-whole-lot-of-stuff)" appended to the filename preventing the auto-execution: I neither understand this nor know how to fix it, but I'm open to doing both.  I'm wondering if these two points are related--if maybe WebStart figures out the web context via the extra content at the end, and other browsers can do the .jnlp(*)->WebStart mapping when chrome can't?  

+ Chrome asks where to save the .jnlp file before opening (if the appropriate box is checked).  Chrome doesn't currently have the behavior of "don't save this file; just open it" (which translates to downloading to a temporary directory, opening, and deleting later), though we'd like to add it.  So yes, the behavior of choosing a directory for download, and putting files in the download folder, is intentional, though it may change in the future.
+ Java WebStart is very secure: All I can say is that our security team is more paranoid than you are :-}.  We've seen many problems with Java applets and applications taking advantage of security holes, so we require explicit user interaction to run Java, no matter what runs it.  I'm told that this is the most robust position among the browsers, but security is one of Chrome's top priorities.  There are ways for websites to get .jnlp files downloaded without the user actually clicking on the .jnlp file, or social engineering to get them to click on something that they don't realize is a .jnlp file, so by default we require the user to explicitly accept the file and give more expert users a way to get around that if they want.

You can find the information of how java web start is supposed to get the default codebase url from the browser here:

In particular look here:

Codebase Computation Rules
In a JNLP file, the codebase is an optional parameter to the <jnlp> tag. It is used both to locate resources described in that JNLP file, as well as to find the JNLP file itself. For technical reasons, Java Web Start is not able to refresh the contents of the JNLP file from the server unless an absolute codebase is specified.

In the new Java Plug-in introduced in the Java SE 6 update 10 release, a codebase is always provided by the browser, either because it was explicitly specified, or implicitly obtained from the location of the HTML document. This allows relative URLs to be used in JNLP files, which is very useful for moving an entire tree of content from one server to another.

JNLP files reference other JNLP files in a tree structure. The root JNLP file for a JNLP applet is referenced by an <applet> tag. The applet tag's codebase helps define the location of the root JNLP file.

The rules for codebase computation are as follows:

If an absolute codebase is specified in the JNLP file, it is used. This is required for backward compatibility reasons.
If the JNLP codebase is not specified, the directory containing the JNLP file is used.
Otherwise, merge the JNLP's codebase into the directory containing the JNLP file.
In simple Java terms, this can be expressed as

   URL new_codebase = new URL(current_jnlp_dir, current_jnlp_codebase);
This codebase computation is not an extension of JSR-56. JSR-56 does not restrict the codebase to be absolute, and therefore it may be relative.
Status: Untriaged
Not autolaunching jnlp files is a recent behavior change that I noticed several weeks ago in the beta channel and now shows up in the stable channel.  In fact I switched back to stable because of this bug.

The previous behavior is much preferred.

I'm on Mac OSX Lion
Comment 19 by, Nov 3 2011
Now, in Chrome 15 the behavior is even worse.
Maybe it's a new bug, you tell me.
Previously the user downloaded the jnlp file every time. 
Now, starting from second download attempt the jnlp is not actually downloaded!!!
For example go to
click "Launch" button -> JNLP file will be downloaded, don't open it. Let's pretend that we closed chrome and reopened it again.
Now click the "Launch" button second time and try to run "notepad (1).jnlp" - > it won't.
Try to "Show in Folder" -> nothing happens - the file was not downloaded at all.
IMHO it's a showstopper regression.

Blocking: 68200
Status: Assigned

It does actually download, but to get it to launch, you have to open the first download.  Chrome is overwriting the first download with the subsequent downloads.

I am experiencing the same issue.
> Try to "Show in Folder" -> nothing happens - the file was not downloaded at all.

Nor does the hyperlink work from the "Show All Downloads" page.  You can only launch jnlp when completely outside of chrome.  This issue arose for me in the same month on both Mac OS Lion and Windows 7(64 bit), on direct .jnlp link, residing on LAN or Web.  Could have been caused by either a java update or a chrome update.
Comment 24 Deleted
> It does actually download, but to get it to launch, you have to open the first 
> download.  Chrome is overwriting the first download with the subsequent downloads.

If this is true then I like this. I rather it override the first file than to make hundreds of files and numbering them.
It is true, but you have to open your downloads folder, through windows explorer or finder / outside of chrome, to launch the file.

In the chromium interface, it is showing the file listed as "Program (1).jnlp" when in actuality there is no "Program (1).jnlp" in the downloads folder, it has overwritten the "Program.jnlp" file.  

(1) is an example.  It could be (29) and it would still overwrite the non-numbered file.
the issue of the jnlp file being misnamed after the initial launch is causing us huge problems. Obviously causing others problems as well - see issues  101979 , 102519 , 103284  which are all duplicates of this issue.
@mbut which version of chrome are you using? In my older version and now after upgrade to latest version 15.0.874.121 m I don't see such problem. Program (1).jnlp would be created in Downloads and is clickable in chrome.

Go to this page:
And click on "Web Installer" and see if it works properly.
I'm running 15.0.874.121 currently.  Not sure what I was running when I made the report.  I am still able to reproduce it, with your site as well.  I am running Windows 7 Pro 64bit if it matters.  I previously tested it with Windows 7 Pro 32bit and Mac OS 10.5 with the same result.

What I have found that works is if you check "Always open files of this type" on the options next to the button, then it does create the (X) file in downloads and it automatically opens the .jnlp file.  This is a "work around" and may not be a solution for some because of potential security risks.  I haven't tested the automatically launch work around on any other OS but 7 Pro 64bit.
Yes you're absolutely correct. After clearing auto open I now can reproduce it. It downloads energy3d(21).jnlp but it doesn't really exists and nothing happens after I click on it to open.

@rdsmith Will this issue be part of the fix for this bug or do we need to open a new bug issue for this problem?
Dell iDRAC issue persists
Windows XP Chrome 16.0.912.77
Files get saved as viewer.jnlp(,+PowerEdge+R710,+User-root@347989s)
Session # at the end changes on each click so the "always open" trick does not work.
Please fix this, all other browsers that I tried seem to work fine.
@eduard I wonder if this is a Windows XP problem because in my Windows 7 64bit I never had this issue. Files download normally as view.jnlp(1) for example and then open upon clicking on it. My current chrome version is: 17.0.963.46

Comment 33 by Deleted ...@, Apr 13 2012
This is not only an XP-related issue. 
I'm using Ubuntu 11.04 with chromium-browser 17.0.963.79~r125985-0ubuntu0.11.04.1 and 18.0.1025.142~r129054-0ubuntu0.11.04.1. 

Drac JNLP files are weirdly downloaded and can't be opened by a simple clic. But maybe this should be an other bug task
Comment 34 by Deleted ...@, May 14 2012
Though this is claimed to be the intended behavior, it is obviously a problem and should be fixed. Or at least give the user the option to always open jnlp files or download them. It should not be up to the browser to decided for us.

Comment 35 by, May 15 2012
This problem is fixed now. At least in Windows 7 64 bits. The problem used to exist for me but google seem to have fixed it few months after. My current chrome version is the latest version 18.0.1025.168 m and at Windows 7 64 bits it does create say file(2).jnlp , file(3).jnlp, file(4).jnlp correctly and opens them correctly.

If you still having issues you should mention your chrome version and your OS.
Comment 36 by Deleted ...@, May 24 2012
I still having this issue: Windows 7 Professional, 64 bits; Chrome 19.0.1084.52 m. 
Comment 37 by Deleted ...@, Jun 22 2012
The issue persists: Windows 7 Home-Premium 64 bits, Chrome 19.0.1084.56 m
Hi, I'm also having issues with this when opening iDrac remote windows. This is because the file is jnlp but then it has addition configuration information within the string eg who to logon as:


FF and IE are able to parse the jnlp extension and allow Java to deal with the config string. Why can't Chrome?

OS is Windows 7 64 with Chrome 20.0.1132.47 m

Only workaround I've found is to use the IE Tab app but that defeats the object!
Comment 39 by Deleted ...@, Jul 20 2012
FreeBSD 9.0/amd64

same problem
I think someone should post a different bug since the original poster was simply talking about automatic launch of jnlp whereas the bugs being discussed in comments is related to problem downloading a same file multiple times. I don't have the latter problem that's why i'm not posting it. someone who's still having that issue should.
Comment 41 by Deleted ...@, Jul 27 2012
I am using Chrome 64 bit Version 20.0.1132.57 m and still having this problem. this is for use on iDRAC... 

Comment 42 by, Aug 10 2012
+1 on this issue, using Windows 7 64-bit, Chrome 21.0.1180.75 m

For some reason the "Always open files of this type" option is not available at all. You get two buttons: "Keep" and "Discard". You also have no configuration options via the Download page. 

As others have stated, other browsers are able to to open un-prompted, once the user has opted to open files of .jnlp type. The issue is with Chrome's implementation. 
Comment 43 by Deleted ...@, Aug 11 2012
+1 on the iDRAC portion of this issue. I'm running Windows 7 64-bit, Chrome 21.0.1180.75. 

The behavior we're seeing seems like Chrome isn't recognizing jnlp files by their mime type, but by their file extension. The "Always open files of this type" option adds an "extensions_to_open" line in the preferences file for the user. Every time you click on one of these jnlp files with the extra parameters in parenthesis, it adds the entire part in the parenthesis with the jnlp extention to that list. It seems like a better way of handling this particular issue would be to recognize these jnlp files by their MIME type, and I'm not sure why that isn't the way it works in Chrome. As a work around, maybe that extensions_to_open field in the preferences file could be made to accept either wildcards or regular expression. So, in it's simplest form you would be able to make this work by changing this:

"extensions_to_open" : "jnlp(,+PowerEdge+R310,+User-root@1318962734584)",

to this: 

"extensions_to_open" : "jnlp*",
Comment 44 by Deleted ...@, Aug 27 2012
+1 regarding iDRAC 6. Win 7 64, Chrome 21.0.1180.83. This is effectively preventing us from using this browser in IT.
It sounds like there are lots of things going on here. Let's try to tease them apart so that we can see what chrome can and can't do better.

Can somebody link me to an iDRAC JNLP file?

Why does iDRAC put parameters in the filename? It sounds like the JNLP file is capable of containing them.
Somebody who knows more about JNLP could write an extension to detect iDRAC downloads, fetch the JNLP contents using XHR, move the parameters from the filename into the JNLP, rewrite relative paths to be absolute, write the resulting modified JNLP into an HTML5 File, pass that to, and (when I implement automatically open the fixed JNLP.

If all the other browsers contain special code to pass the URL of JNLP files to javaws instead of the filename, then there may be an argument to be made for chrome doing the same. Can somebody who understands JNLP explain why this should be necessary?
In the mean time, if users are willing to run a simple local daemon, then an extension could detect JNLP downloads and ask the daemon to pass the URL to javaws. Or the daemon could watch the downloads directory and detect JNLP downloads itself.
Alternatively, since chrome now associates the URL of a downloaded file with the file on all platforms, it might be possible to write a script that shadows /usr/bin/javaws, uses getfattr on linux (or equivalent on other OSs) to see whether the filename argument was a download, and pass the url to the real javaws instead of the filename.

Linux users: please configure xdg-open to associate application/x-java-jnlp-file with javaws.
Chrome does not know anything about any applications, it allows OS-specific tools like xdg-open to choose which applications to run.

I agree it seems like an awful user experience when xdg-open says "Error: no "view" mailcap rules found for type "application/x-java-jnlp-file" and chrome fails to relay that error to the user. I'll see if we can at least display an error message suggesting configuring xdg-open.

 Issue 145453  has been merged into this issue.
Ben, have emailed you a JNLP file
Blocking: chromium:68200
Comment 49 by, Sep 10 2012
I am having the very same problem, for a long time already, Firefox opens the .jnlp file perfectly, but chrome just keeps downloading it again and again.

I am using chromium x86_64 for Linux Version 23.0.1263.0 (155718).
Comment 50 by Deleted ...@, Sep 18 2012
OK SO the Google tech said "I'm sorry; that's the intended behavior and we will not be changing it.  There are serious security implications of always opening .jnlp files.  If the user explicitly requests the behavior, we'll do it for that.  But we won't pre-open that security hole."

The problem being that we "explicitly" as for the open behavior but it does not work. If Chrome can not support standard functionality then why should we use it. I'm at the point of dropping it all together because many things that work in IE and FireFox do not seem to function in Chrome. So either fix the problems we report or we will simply use a different browser.

Regarding the file naming issue: Can someone post (or email to me) a net-internals dump showing the headers that are sent when downloading a .jnlp file? I want to verify  that we aren't missing a file naming hint.

Instructions for doing so can be found at

Thank you andrew.wippler for the log. Unfortunately it confirms my suspicion that in the case of the iDRAC file, we aren't getting any filename hints other than the URL. The response headers are:

                               --> HTTP/1.1 200 OK
                                   Date: Thu, 27 Sep 2012 08:21:55 GMT
                                   Server: httpd
                                   Content-type: application/x-java-jnlp-file
                                   Content-length: 1547
                                   Connection: keep-alive
                                   Keep-Alive: timeout=60, max=1991
                                   Last-Modified: Thu Sep 27 08:21:54 2012

Comment 53 by, Sep 27 2012
what should the response header be?
#53: I wanted to verify that we aren't skipping over a (possibly malformed) Content-Disposition header that may contain a filename we should use.

Comment 55 Deleted
Suggestion: take the file as it is named right now an add the .jnlp extention at the end.
File saved as today: viewer.jnlp(IPADDRESS@0@idrac-TAG,+PowerEdge+T410,+User-root@1341480501981)
File saved after fix: viewer.jnlp(IPADDRESS@0@idrac-TAG,+PowerEdge+T410,+User-root@1341480501981).jnlp



Other browsers save the file as my last suggestion if you don't set them to auto execute.
 Issue 154793  has been merged into this issue.
Comment 58 by Deleted ...@, Oct 10 2012
#56: what's viewer.jnlp? is it just an example jnlp or is it a utility that starts jnlp programs instead of just downloading them? If so where can we find the documentations for it? Currently I just make a HTML link to my jnlp and hope that the browser will start the webstart when the user clicks on the link to energy3d.jnlp file.
Hello !
is an internal system.
when running in chrome, the browser asks to download the page.
I downloaded, then asked to perform using Java and scored the combo box to
do this automatically.
it worked!



Cel: (11) 98077-7935

The viewer.jnlp is streamed/generated by the Dell out of band management software (see details in earlier posts to this bug). The expected behavior is for the file to be fed to Java for execution. Due to security concerns Chrome saves the stream instead of feeding it to Java. Once the file is downloaded you can click on it and the OS will use its associations to execute/interpret it (hopefully with Java).
The standing bug is related to the fact that the file that Chrome downloads is not named properly (add the .jnlp extention) so that you can click on it or set rules for auto execution.
See comment 56 for suggested fix and comment 52 for header returned by Dell webpage. 
Comment 61 by, Feb 25 2013
So any news about this? It still doesn't work in Version 27.0.1423.0 (184404), even if I download and click on it, chromium tries to download it again instead of feeding it to java. (in Linux with KDE 4.8)
It's working for me.  When this does crop up, I notice that the user
generally has 100 of the same launch files in the download folder.
 Clearing it out causes it to work properly again.
The auto open does work for me too. The issue I have is, that I first have to tell chrome to download the file. Is there any way to mark either the extension jnlp as safe, so it won't ask, or implement a way to allow downloading and auto opening it from a named Website?
We are using these jnlp files to print barcodes from a supplier. Right now we are using Firefox, which is working as expected, but I would like to move over to chrome. But having to click continously to save these files is a no go.
My issue seems to be resolved. The supplier has some issues with his certificate. I assume due to that chrome sees the file as a security issue. If the issue still exists after they fixed their cert I will update again. Sorry
This extension API allows extensions to change download filenames and will be landing on the dev branch shortly:
Perhaps an extension could use it to append '.jnlp' to idrac filenames?
Project Member Comment 66 by, Mar 10 2013
Labels: -Area-Internals -Feature-Downloads Cr-Internals Cr-UI-Browser-Downloads
I am forced to stop using Chrome due to this issue - hundreds of copies of my jnlp files in the download folder. Constants nag messages that this file may be dangerous before running, etc.. Firefox and IE both work correctly - this should be reason enough to fix it.
Comment 68 by, Mar 21 2013
I am also facing this issue. It is quite annoying.
It happens in Windows and Mac (tested MacOsX 10.8, and WindowsXP)
the filename is "launch.jnlp", so with the proper extension
It is set "always open files with this type"
Status: Available
Owner: ----
Comment 71 by Deleted ...@, Apr 9 2013
This is back with Version 26.0.1410.43 m, and there is no way to disable the 3 step process for the first jnlp. I work in a production environment, and use jnlps for remote console access, so they are new EVERY time. Even though I have selected 'Automatically open files of this type' for jnlps, I must click 'Show Downloads', 'Keep', and 'Keep Anyway' EVERY time. If I do return to a prior console, I only have to select 'Accept' but this is not the norm. 
Comment 72 by Deleted ...@, Apr 9 2013
Also... not only do the jnlp files linger, and additional browser window is left open with every launch. 
Comment 73 by Deleted ...@, Apr 18 2013
OK, goodbye Chrome. Firefox takes 2 clicks to get it to open jnlps automatically from then on. 
 Issue 105478  has been merged into this issue.
Labels: -Pri-2 Pri-3
Trying to run appinventor.  Chrome refuses to run AppInventorForAndroidCodeblocks.jnlp.    Looks like the same problem.
Comment 77 by Deleted ...@, Jun 28 2013
From post #52
Content-type: application/x-java-jnlp-file

Based on this line why can't Chrome open .jnlp(*****) files like every other browser. Post #43 suggested that chrome is using filename instead of Mime type to associate a default program.

I use remote launch windows on a regular basis and it makes it hard opening these.  You have to tell it which program everytime.

Chrome Version 27.0.1453.116 m
Comment 78 by, Jul 22 2013
Well, as stated by users above, the problem should be fixed if Chrome is able to save the jnlp file into a file named "viewer.jnlp(XYZ....blah).jnlp"  . The reason for the iDrac case to fail to launch is just because windows cannot recognize the file extension as Chrome saves it with a different extension name each time when the session id changes. It does not introduce any security risks if Chrome just saves the name better, with the correct extension.

Chrome should parse the filename to recognize that this is a jnlp file and append a .jnlp extension to the filename.

Attached is a viewer file downloaded by chrome from dell management console. I changed the IP, username and password to fake numbers.

I also attached the html file that Dell management console will execute when we want to launch the KVM console jnlp. It does not directly link to a pre-generated jnlp file but instead it uses some scripts to add user parameters into it dynamically.

Hope these helps developers here to solve this problem that made thousands of IT officers stick with Firefox and IE when they are doing server management.

Chrome 28.0.1500.72 m
28.3 KB View Download
1.9 KB Download
Comment 79 by, Sep 28 2013
For what it's worth, Firefox under MacOS downloads these jnlp files from Dell management consoles with the exact same name format, yet it is still able to tell the OS to open the file properly, based on the http server's provided mime-type.  It may be important to note that applications can query the OS for the application associated with a mime-type by using LSCopyApplicationForMIMEType().
Comment 80 by, Sep 30 2013
yes I also noticed that chrome doesn't respect server specified MIME Type. Perhaps another bug report should be opened just for that problem.
Comment 81 by Deleted ...@, Oct 21 2013
Also awaiting a fix for this so I can push Chrome to 850 workstations.
There is a UI issue here that has not been clearly addressed above. Saving the file gives an incorrect impression to the user, in particular, that jnlp files are unsupported. If Chromium wishes to provide strict security, and make sure that the user truly intends to launch a Java Web Start application, then it should do so by explicitly warning or consulting the user. But, the current behaviour does not do that. The current behaviour communicates "unsupported", not "unsafe". 
Comment 84 by Deleted ...@, Mar 4 2014
This issue also affects IBM's IMM2 viewer console. When clicking the link in IE or Firefox, java launches. However in Chrome it is downloaded as viewer(<ipaddress>@<port>@0@<#############>@0@1@0@jnlp@<Username>@0@0@0@0) So....
Windows thinks it's file exention begins at the end of the IP address (last . ) and worse, if you just append a jnlp extension on the end it explodes when trying to authenticate/log in, because I'm assuming the way it was looking for your server admin credentials in that file (stuff in the parenthesis) isn't getting passed to the JRE in the right way when you tack a jnlp on the end of it.
Having this same issue with VMware Orchestrator client.  I need a group policy setting to administratively allow jnlp launch for all chrome deployments in the domain.
Chiming in, also happening when trying to manage a Cisco UCS-E blade server.  I get a file named "viewer.jnlp(" or similar, and the console does not launch.  Works as expected in IE 11.

This has been sitting largely untouched for over 2 years.  If you need more information, please ask!  I'm sure we'd all be happy to provide anything you need.  It's affecting multiple enterprise platforms across some of the biggest manufacturers in tech (Cisco, Dell, VMware and IBM just from this thread).
The "Always open files of this type" is a workaround which works ok but has these disadvantages:
 * requires unnecessary extra effort. The users must be instructed how to start a web start application which defeats the whole idea of a simple single-click install + launch.
 * unnecessarily clutters the Downloads folder
 * may not work after 100 times as noted here
Comment 88 by, May 20 2014
The "Always open files of this type" workaround may work for some applications; in the case of Dell iDRAC 6 (and likely others) the filename arguments are part of the file extension and checking that box makes no change: we need about 4-5 clicks (select application, click ok, choose application, click ok...) for every launch.

So not only does it clutter the Downloads folder, it also takes many extra steps to launch an app and I suspect it pollutes the registry for every new file even when un-checking the "Always open files of this type" box.
Comment 89 by Deleted ...@, Aug 1 2014
rejoice all ye plagued with ip KVM issues for dell (and other) servers!  A chrome extension has been released that fixes this viewer.jnlp issue:

pay attention to the comments, as if you have a c2100 or c1100 you will need to modify the JS file to check for the VM.jnlp (virtual media) files too!
asanka@: What's the next step for this issue?  Are you waiting for some feedback?
When is this issue going to be fixed?

This bug is further compounded by  bug 135428 . After 100 JNLP files, the 101st one gives a problem - because Chrome has a limit of 100 files of the same name. Our users run our Web based JNLP application 3-4 times a day. So in a month's time - they can no longer run this because the 100 file limit is exhausted. And our users are non-technical - who won't even be able to find the download directory and delete files. We aren't left with any other option now other than blocking Chrome for our application and asking the users to use Firefox or IE. 
Comment 93 by, Mar 24 2017
This issue is so annoying... please just allow us to autorun!
why this is taking so looooooooooooooooooooooooooong and still not fixed? 
Comment 95 Deleted
Win7 Pro 64 using Chrome v60.0.3112.113 to access an iDRAC6 Enterprise with latest firmware - same issue. It appears that the person who this bug is assigned to has bounced.
Sign in to add a comment