Chromium

An example url: http://phet.colorado.edu/simulations/sims.php?sim=John_Travoltage -->
Run Now! (it was not specified)

Still does not work as of 3.0.190.4 (Official Build 19293). The original bug was filed
against 1.0.

This bug is very annoying because it prevents smooth launching of JavaFX applications:
you download jnlp first and then have to run it explicitly.

Yes.  I do a lot of online video game research and reviews, and I like checking out
Java games, because I feel they are a severe underdog in the category.  The people
that don't want to use applets use Java Web Start applications.  I love Google Chrome,
but this issue takes away the whole point of these applications being "Web Start;" to
the point where I have to have a Temp folder of JNLPs that I delete later.

This needs to be fixed - quickly - it really hurts the java community. please fix this,
it's been months now.

I agree, it is very annoying to go and launch a jnlp from wherever it gets downloaded
let alone the usability impact. I've noticed this problem for a while now as well and
thought I would agree with the bug submission.

Steps
-----
Navigate to http://phet.colorado.edu/simulations/sims.php?sim=John_Travoltage
Click on Run Now!

IE starts the app automatically.
FF prompts whether to open with Java Web Start Launcher or Save it. Opening with JWS,
stats the app automatically after downloading.
Chrome doesn't prompt and downloads the file. User has to run the file manually.

Happening with Google Chrome 4.0.221.6 (Official Build 28091)

this sounds a lot like https://crbug.com/chromium/2292, or https://crbug.com/chromium/333.  Chrome doesn't auto-execute some
specific file types.

Uhm, weird. This has always worked for me. But now, suddenly (_during_ a browsing
session) it stopped working, my .jnlp-files wants to be downloaded! I see no way of
reverting to the old behaviour?

sopues, what version of Chrome & Java are you running?  It's possible one or the other
was auto-updated and caused the issue...

My java should not have been updated, I am on JDK 6 update 17. Chrome is on a dev
channel I think, and the version is 4.0.249.11.

Is anything being done about this bug? It's so annoying to find my downloads directory
filled with various versions of jnlp file.

here's one more thing I'd like to check to confirm a suspicion I have:

1. go to "about:plugins"
2. search for "jnlp"

Do you see any plugin set to handle "jnlp" files?

Can someone from the chrome team please comment openly on intentions here?  Is this
long standing unresolved issue a deliberate snub of java by the browser in favour of
pure HTML apps that google favour?  It would seem trivial for chrome to link the jnlp
up correctly with Java 'out of box'.  

Thanks noah.podolefsky, that seems to do the trick for me.  Others may want to try the same steps.

From this, I think there are probably two separate issues here:
1. .jnlp files are not opened by default.  This seems like it should be up to the user whether these files
are opened by default or not, but automatically executing jnlp sounds like it has security implications.

2. the download shelf shows the download even though the file gets executed successfully.  Kind of
annoying, but seems like https://crbug.com/chromium/333 or https://crbug.com/chromium/2292.  I'm going to dupe this bug into one of those.

[Empty comment from Monorail migration]

The chrome team doesn't seem to give a damn from what I can tell.

This works fine, until chrome has saved 100 of these files. Seems it runs out of
renames then, and I have a directory with:

xxx.jnlp
xxx (1).jnlp
 ...
xx (100).jnlp

I just successfully used jnpl with my client-bank software. Chromium  4.0.266.0 under
linux.

Still not working Google chrome version 4.0.249.89 unknown (38071).

Google! Java isn't going away, fix this.

Chrome version 5.0.307.11 beta using Ubuntu Linux - same issue. Had to publish a
message asking users of my site to not use Chrome if they want to use my site
properly.

I can't imagine this being a complex bug to fix because a) it's easily reproducible
and b) associating JWS with a specific mime-type/extension is, from an outside
perspective, not too cumbersome.

It didn't work on Fedora 12 :-( The "xdg-mime install" command ran
just fine, and "xdg-mime query filetype somefile.jnlp" returns
application/x-java-jnlp-file as expected. However, gedit is still
the preferred to open .jnlp files.

I found sun-javaws.desktop under the jre/lib/desktop/applications,
and I ran

xdg-mime default /usr/java/latest/jre/lib/desktop/applications/sun-
javaws.desktop application/x-java-jnlp-file

and now

xdg-mime query default application/x-java-jnlp-file

returns

/usr/java/latest/jre/lib/desktop/applications/sun-javaws.desktop

However, "xdg-open somefile.jnlp" still opens gedit. Could this be
related to the fact that "file somefile.jnlp" returns "XML  document
text"? Any additional tips?

I agree, this has to be fixed, it's more than one year old!

[Empty comment from Monorail migration]

I guess I finally found out how to "fix" this, at least on Fedora 13 (credit goes to an answer on Fedora ML). It seems to be a GNOME bug after all.

If you try to associate JNLP files to javaws by

right-click on the file > Open With > Another Application ... > javaws

and checking "Remember this application ...", it doesn't work (next time you double-click the file it will open with gedit).

BUT if you set file association by

right-click > Permissions > Open With tab > javaws

it *DOES* work, file association sticks. If you open a JNLP file through Chrome, it will work =)

It's not gnome bug as it happens on all platforms.

Sure, I should have been more specific: what I believe to be a GNOME bug is the fact that you can't associate files to apps one way but you can another way.

@aimran50 : I just tried your URL and, at least here on Fedora 13, the modifications detailed on https://crbug.com/chromium/10877#c40 made it work as expected (the JNLP file was automatically executed by javaws).

@andre.ocosta does that really sound like a User friendly support for jnlp ?

This bug is annoying as hell, Chorme is basically not a java friendly browser if they don't support auto opening of JNLP cross platform.

IT call:
User: I'm pressing the link and your app doesn't start.
Tech: What browser?
User: Chrom.
Tech: We don't support Chrom, Use another browser please.

End of story.

Ironically, first time I ran into this bug was when trying out Google App Inventor... I think it's really sad if your own browser doesn't handle your own sites properly.

Sure you can set it to open automatically the JNLP file and you can have them  be automatically deleted using Ccleaner, but many users don't know how or don't want to go  to all(sort of sarcastic) that work.
It should be downloaded to a temporary location, opened, and deleted.

Please add application/x-java-jnlp-file to mimetypes supported by chrome.

I can't use cisco web start as it tests for mimetype :


<script type="text/javascript">
<!--
var appName = "";
var isWindowsOS = (navigator.userAgent.indexOf("Windows") >= 0);

var javawsInstalled = 0;
isIE = "false";

if (isWindowsOS) {
  if (navigator.mimeTypes && navigator.mimeTypes.length) {
    mimeEntry = navigator.mimeTypes['application/x-java-jnlp-file'];
    if (mimeEntry) {
      javawsInstalled = 1;
    }
  } else {
    isIE = "true";
  }
} else {
  javawsInstalled = 1;
}
//-->
</script>

This is still broken on Linux version. Specifically Ubuntu Lucid running 6.0.472.25 dev

Come on google, it's been over a year since this was reported, how hard can it be ?

It is more than a year this bug is reported, no action from Google! Is Google moving away from developers?

The really sad thing about this bug is that there are people who really want
to fix it and get absolutely nowhere with some of the chromium developers. I
bought Visual Studio primarily so I could start compiling chromium on
Windows to work on this bug (as well as getting into Windows programming). I
started an initial debate with the people I was told to. I drew up a design
document, it was discussed - by all except the one person who seems to be
responsible for making the decision. Nearly a month has passed since he was
asked to give the go-ahead on or comment on the proposal, and nothing. It
seems there are only 1 or two people who can have the final say on anything
that impacts the UI, and they are either completely overloaded or completely
disinterested in helping the community at large and only work on the stuff
thats in front of them, instead of giving developers such as myself a bit of
leeway or encouragement to help them help make chromium a better product. I
find it quite sad really.

So for the myriad number of people that this affects, don't hold your
breath. Alternately, I may just go ahead and fix this on my own branch of
the code and I will post builds from that branch which people can either
use, or not, as they see fit.

Like someone else noted, I'm trying to use Google's own App Inventor in Chrome and can't because of this issue. I switched to Chrome full time a couple months back, but if you REALLY want me to use another browser, I'll go back to Firefox. PLEASE FIX.

Yes, there is a problem with opening "jnlp" files in Chrome browser like Block Editor in Google App Inventor. I need to use other browser (like FF) for this :-/
It's very annoying because Chrome is my default browser :-( ...please Google FIX IT.

It doesn't work as expected on Linux, but it seems to be due to some weird GNOME bug (see https://crbug.com/chromium/10877#c40), at least on Fedora 13 and Ubuntu 10.04 (which both use GNOME 2.30.x).

Also discovered the bug when trying to test App Inventor.

Yeap same as many above, Google App Inventor / Chrome will NOT be used together by many people when other more popular browsers (firefox) work as expected.
If you cant be bothered to fix it at least post a simple work around...

Should the app be opened standalone or just inside browser? You can easily run it with "javaws file.jnlp" btw.

There should be a configurable association between .jnlp files and some
version of javaws on the local system.

Other browsers appear to obey the new window/new tab config entry for
whether it's in a new window or in a tab.

@phlogi1, we are application developers and Java Web Start is a platform developed by Sun to distribute Java applications. All Java developers knows how to run a Java WS app, but not the end users.

@jmmcreynolds Just because you can download and click on it, it doesn't mean that it works as it should.  First off if the user keeps trying to run the JNLP/Webstart on a daily basis from the site, you don't want them to keep re-saving the jnlp.  You want it to run just as it would run if it were an embedded applet.

I am also unable to get Chrome on linux to launch Curl applets ( Curl as in www.curl.com and not cURL)

Curl applets had been an alternative to Gears and JavaFX - but used mostly in a few corp's in Japan and discretely elsewhere in some large corp's ( clients of Thomson Reuters Tax div GRC customers via acquisition of paisley.com of MN, USA)

Curl in Japan (curlap.com) has work underway on a Java ORB so this issue in Chrome on linux is annoying ... - the issue is Linux only TTBOMK

Curl in banking is about as well-kept a secret as VW Smalltalk in banking prior to some chatter from NY.  Smalltalk was big at a telco with some mobile over-charging issues - it will be amusing if those came from an app that had replaced Smalltalk ...

Hope these bugs get fixed before Chrome leaves beta ...

I have a feeling that with Oracle suing Google, this probably won't get fixed any time soon or at all now. http://news.cnet.com/8301-30684_3-20013546-265.html

The way I see it, this behavior isn't a Chrome bug, it's rooted in the fact the Chrome consciously does not manage its own set of file extension -> launcher application associations. Instead, it relies on the operating system / desktop environment to provide those associations for it. This means that you have to configure your system (e.g. Windows or Gnome) such that it opens .jnlp files with javaws (the webstart launcher). From then on, Chrome will use that setting and open .jnlp files with javaws (after clicking "Open" in the download bar, or automatically after you check "Always open files of this type" there). This is the way to "fix" this issue. Google cannot really "fix" this themselves because Chrome deliberately doesn't contain any code that makes (configurable) decisions on what application to use to run what downloaded files -- they deliberately  use the OS settings for that.

@olaf.klischat, have you tried downloading a jnlp file (where a file association is already there) before making this comment?

There has to be a way to pass URL as argument to associated application instead of downloading and then executing.

Actually, Firefox has the same bug, see https://bugzilla.mozilla.org/show_bug.cgi?id=115041 and bugs it depends on.
It's a bit less dramatic there though, because it stores files in $TEMP and most of the time removes them after use.

@sunilmnambiar, yes I have. I use Xubuntu (xfce under Ubuntu 9.10), and I had to configure the association once in the system (I did it from the file manager I think, but I don't remember for sure, it's been too long). Chrome has been opening .jnlp in Webstart automatically ever since.

@olaf.klischat, a file association will be created at the OS level if you install jre 6.0(not sure about previous versions). Still we  have to manually associate/open jnlp files in Chrome, which is not the case with IE or Firefox. The main reason why developers choose Java Web Start is to make the end users life easy, just click on a link and start/install the application. We can just deliver a jar file with main class, then associate it with java and run the program, no need to go for Web Start(ignoring other features).

Now the developers has to give special instructions to the end users(who uses Chrome) to download the jnlp file, then open it from the downloaded location.

Guys, we are looking for a permanent solution, not workarounds.

I'll join what sunilmnambiar is saying... as developers it's easy for us to look for the workaround and associate stuff... if my end users have to do it to use my application I'm just creating another barrier for adoption. Users will prefer an installable exe file rather then deal with this wierd jnlp file that they don't know. The main idea behind JWS is the one click install and run. Chrome just doesn't do it.

@Chrome developers wake up!

We've been going round-n-round this issue for about a year. Enough.
Here, in my not so humble opinion is how web start on chromium should
work - You click a JWS link and 1) It just flat launches the software
like it's supposed to, and 2) Chrome needs to be smart enough to NOT
treat a .jnlp as a downloadable file. It should transparently suck the
.jnlp down the pipe, not cache it, not 'save' it etc. - Simply suck it
down and do whatever is required to launch the java application. As it
is, A) JWS apps DON'T usually launch, and B) the .jnlp is treated as a
download. The handling of JWS in chrome just sucks. And Oracle/Sun
obviously don't have the clout with Google to 'make it so'. And that
is bad news, because again, and again,  and again, the java launching
process has been anything but 'double-click' from the user
perspective. Thanks for listening.

[Empty comment from Monorail migration]

It does not work on Linux :( If you don't fix this bug, I will advise my users to go back to Firefox!!!! I'm fed up! I have just paid to upload my game and now I'm stuck.

I think that I have found a bug fix. I have looked at the source code of Chromium, especially the MIME handling and there is only one line to add to fix it :) I will try to commit it. Java rocks, long life to Java and to free open source softwares!!

Please find enclosed the file /trunk/src/net/base/mime_util.cc that I have modified to try fixing this bug. application/x-java-jnlp-file was never returned for a jnlp file, it was not returned by the platform-specific mime type handler and it was not returned by the platform-agnostic mime type handler. As it is not a platform-specific mime type, it has to be put in the platform-agnostic mime type handler. I'm not sure it fixes completely this bug BUT it improves the situation on Linux as the correct mime type is returned to the application used to open a JNLP file, for example Konqueror. Please use it as soon as possible.

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

@supagene's https://crbug.com/chromium/10877#c66 resonates with me. If a website is serving a .jnlp file directly, different browsers will obviously react to the download in different ways.

.jnlp files are typically handled by a plugin which recognizes the MIME type. What's wrong with using the <embed> tag? The <embed> tag also permits a specific MIME type to be enforced regardless of the file extension of the resource indicated by the "src" parameter.

Why do you speak about <embed>? I'm not speaking about the use of JNLP inside an applet, I'm speaking about using Java Web Start directly.

The workaround (i.e. Always open file) NOW works UNTIL you get to 100 starts of the same application. This didn't work when I first raised the bug report. Testing the Draw app from http://java.sun.com/javase/technologies/desktop/javawebstart/demos-nojavascript.html today (OSX 10.6.5, Chrome 8.0.552.231) I end up with "draw (1..100).jnlp" files in my Download directory. The next attempt I get the dialog to ask me where I want to save the file.

craigday, this workaround does not work on Linux without my fix.

gouessej, I believe you. I will do this test on Windows later today just so we know where this is all at in the current Chrome releases.

Thanks. Some file browsers used by default on Mac OS X and Windows may detect the file type without using the mime type or they do not take into account the wrong mime type sent by Chrome/Chromium, that is why your workaround works on some platforms but not on some Linux distros. My fix only sends the right mime type for Java Web Start applications.

What happens if the file is not a .jnlp extension?
It does not work if I run a .asp file with a jnlp mime-type.
This has stopped working on the 8.0.552.215 update of chrome.

iparraa, I have the same problem with a .php file that forces the JNLP mime type but I didn't know it had worked in the past. Thank you very much for this piece of information. However, I don't advise you to use php or asp to do this in the future as my fix only concerns files with a .jnlp extension. I do my best. Rather write a bigger JNLP file containing more conditions concerning the OS, the architecture, etc...

Yes, in earlier versions, Chrome download the file as a .jnlp file and let the user execute the file.
In the last version, Chrome download the .asp file and open it as a text file.
Making a bigger jnlp file is not a solution (at least for me), because I generate a jnlp code with different parameters created on the web before launching the jnlp.
My 'temporal solution' is renaming the .asp file to .jnlp but this is not a solution for the final users, which are using now IE and FF.
Firefox renames the file automatically when detects the jnlp mime type and let you launch it with Java Web Start.
On the other hand, IE launches Java Web Start directly without prompt anything to the user.

What is the status of this ? Why you guys making it so complicated ? Jnlp is a method of easy package deployment to reduce the hell of package mess.

- Why dont you guys just fix this ?
- How long Java will be suffering hate and hate and hate ???

- Why not put bug for Flash player and Silverlight ?

gouessej, please follow this process:
https://sites.google.com/a/chromium.org/dev/developers/contributing-code
if you'd like your change reviewed and commited.

Changing the feature component since this is really about download handling, not plugin hosting.

Several people has already reviewed my change, I have already committed my bug fix. Now it is up to Google to make its job.

Please, fix it. My product is launched by "per-client" JNLP generated via ASP pages. It works fine with IE, Firefox and Opera. Only Chrome and Safari fails (may be because both them share WebKit)

[Comment Deleted]

FWIW, fails in Ubuntu too.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=73080

------------------------------------------------------------------------
r73080 | cevans@chromium.org | Fri Jan 28 21:06:17 PST 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/download/download_util.h?r1=73080&r2=73079&pathrev=73080
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/download/download_util.cc?r1=73080&r2=73079&pathrev=73080
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/download/download_manager.cc?r1=73080&r2=73079&pathrev=73080

Tweak the auto-open algorithm to permit JNLP to auto-open iff the user has
set auto-open on JNLP, and the JNLP file arrives courtesy of a user click.

BUG=10877
TEST=http://phet.colorado.edu/simulations/sims.php?sim=John_Travoltage

Review URL: http://codereview.chromium.org/6324020
------------------------------------------------------------------------

Ok -- on trunk, it's now possible to set JNLP to "auto-open" and it will bypass the warning iff a user gesture (such as a button click) caused the JNLP to be served.

Put another way, you can set JNLP to "auto-open", and the John Travoltage demo app works with just the button click: http://phet.colorado.edu/simulations/sims.php?sim=John_Travoltage

This will filter into Chrome dev channel in a couple of weeks and then onwards to stable!

This is good news, and will be handy, however I feel the real fix is to have the ability built into Chrome preferences , that allows you to associate applications to specific file types, like you can do in Firefox.

Not sure if this has been suggested or is being worked on, but fixing these one at a time seems to be a waste of developer time, in my opinion.

Thank you for the fix. A lot of final users will be happy with your time.

Thanks!

Re: https://crbug.com/chromium/10877#c107: I believe http://crbug.com/55566 tracks the behavior you want.  I can't give you a time estimate on it, unfortunately, but I do expect it to go in "at some point".

The hard part about this issue was figuring out what the right behavior should be given the complex of constraints we were under, not actually implementing it.  So I don't actually think fixing it separately wasted much time.

@swcodfather: this is not a one-off fix. It applies to any "dangerous" file type for which a MIME type handler is registered at the system level.

Thanks for the update chaps, I will follow the bug report 55566 and help with testing when it is available.

I have the exact same problem under Windows 7 64bit, Chrome 9.0.597.98. What I would like to point out is that the steps listed above by a few people to click the down arrow and tell Chrome to 'always open files of this type' does not work. It does absolutely nothing. I tried re-starting Chrome and same thing. It automatically downloads but then does absolutely nothing. I am using this to try and access my DRAC (Dell Remote Access Console) on a server remotely. Under IE 7,8,9 works without issue. Under Chrome, it just downloads the file and sits there. It would be nice to just have this work out of the box or to at least provide end users with a simple warning if you do not want this on by default. But at least don't make it hard to have this work seamlessly.

BTW, I had the same problem on my Mac and there I had to follow some other instructions and actually register the file association with an executable in a directory. After that it worked like a charm. But on Windows, it does not work for me.

EJK

The fix that is currently used does not change anything in the MIME type, mine would be complementary, wouldn't it?

but how do I set it to auto-save AND Open automatically?  I remember it works OK before the recent upgrade..Pls advice.

There is no way to manually add the MIME type "application/x-java-jnlp-file" ??

I don't reproduce this problem anymore. I use Google Chrome 10.0.648.204 on Mandriva Linux 2010.

PLEASE USE GOOGLE CHROME 10.

[Comment Deleted]

I just verified that it didn't auto launch my jnlp after clicking it in dev chrome 11.  This should ideally work just like an applet where the menu above pops up and asks if you want to run java application.  My concern is that it still is dumping the jnlp to Downloads and is numbering it file(1).jnlp, file(2).jnlp, etc. which will continue to take up space and never get cleaned up as it is not going to the temp directory and not getting cleaned up once the browser is closed.  I understand that customers can set auto-open of jnlp, but that is not what I'd like to happen.

google, i thought you didn't suck.

I haven't checked that with Google Chrome 11.

Maybe James Gosling can fix it for us now.

Kenneth Bradley Russell and James Gosling are able to fix this bug but the problem does not rely in any Java source code as Chrome is written in C++. However, the fix already used in Chrome 10 works even though some people do not like its behavior and I provided another fix. If the code has not been deeply restructured, a new fix is not really necessary, otherwise I will give it a quick look.

This bug should not be marked as fixed.

BTW it is possible to achieve desired behavior by writing NPAPI plugin (there are download managers that integrate with Chrome this way).
Unfortunately sun/oracle never really cared. Even their Firefox integration is rather bad, yet Microsoft managed to integrate .NET ClickOnce properly.

Below ASP code works fine within IE & Firefox
Chrome just save the target ASP file !!

Please fix it, no workarounds

Pedro

<%@  language="VBSCRIPT" codepage="1252" %>

<%
Response.ContentType="application/x-java-jnlp-file"
Response.Write("<?xml version=""1.0"" encoding=""ISO-8859-1""?>")
Response.Write("<jnlp spec=""1.5+"" codebase=""http://www.SERVER.com/"" href=""file.jnlp"">")
...
Response.Write("</jnlp>")
%>

Hi guys,

you need to set JNLP files to auto-open. To do this:
1.) Download a JNLP file
2.) In the download bar, right-click the item
3.) Choose "Always open this type of file"

After that, this should work.

No, it doesn't work. If you do that then file is still downloaded to you Downloads directory.

@thakis I don't think it is expectable behavior for jnlp where the user has to select open or auto-open.  Most users do not even know what a jnlp file is or what to do with it.  For example, nobody expects to open a file when you launch an adobe air program.  Here is an example.  http://chessjam.com/ clicking install does not prompt you to save a file to open. It just launches the air installer.  I believe the same thing should happen for the jnlp.  All the other browsers perform in such a way.  If google is worried about launching something harmful then it should probably display something like what I suggested in https://crbug.com/chromium/10877#c123.

@mwisnicki I don't agree with you, Firefox integration of the plugin 2 of J2SE 1.6 is excellent, there had been numerous problems with the plugin 1 but these problems did not affect Java Web Start as far as I know. .NET ClickOnce works only on a single family of operating system, you cannot compare this thing with Java Web Start. Can you tell me which version of Chrome you use please?

@thakis It works for me. However, I agree with the previous comment. The treatment of Java in Chrome is unfair, I see the (bonus) dangerous file warning whereas there is already the scary warning of Java Web Start for signed applications requiring some authorizations. If you want to discourage the final users from launching Java applications, keep the same behavior :(

@supag The default scary warnings of Java are enough, don't they? On which operating system did you try Chrome 11?

Please, do you know why chrome is not handling "ContentType" (last tested version 10.0.648.204) ?
See comments #130, #102

@goues...
It's certainly less than excellent (unlike ClickOnce). Firefox basically treats JNLP exactly the same way as Chrome except it downloads this file to $TMP and I already mentioned that in https://crbug.com/chromium/10877#c73. Such treatment causes JNLP files to not work if codebase is not hardcoded into them, yet codebase is optional according to jnlp documentation.

That ClickOnce works only on windows does not really matter as its Firefox plugin is pure javascript and very simple, it just catches download of clickonce file and passes the url to clickonce launcher. With 3 simple changes it could be used for JNLP.

Anyway this is mostly Oracle's problem. They can easily provide working WebStart solution for Chrome and Firefox if they want. Instead they (and Sun before them) choose to ignore bugs and other deficiencies of WebStart. In fact they don't even accept such bugs into their bug system (which is moderated).

I'm using Chrome 11 if you really need to know.

Oh and one more thing. There is a javascript jnlp deployment script which you are supposed to use at http://download.oracle.com/javase/tutorial/deployment/webstart/deploying.html, or more precisely http://www.java.com/js/deployJava.js.

Unfortunately it uses 'application/java-deployment-toolkit' mime type handled by special deployment plugin 'npdeployJava1.dll' that:
 1. is not registered with Chrome
 2. even though it's present in Firefox it does not seem to work there

And webstart deployment toolkit does not work by design ;)
From http://java.com/js/deployJava.txt:

   launchWebStartApplication: function(jnlp) {
       // This methos is disabled for the time being
        return false;
   },

Been that way since forever. Typical shit like you would expect from Sun.

Under XUbuntu Linux (with both Thunar and Nautilus properly opening the .jnlp files), this still does not work under Google Chrome version 13.0.761.0 dev.
I'm noticing that it's silently downloading the file to my Downloads folder, as mentioned in https://crbug.com/chromium/10877#c132.

original bug was files for chrome version 1 (!)
at version 13, two years later, still no solution or fix.

nice job :(

I don't understand, how come it says status Fixed. It's not.
I use browser based application, for stock trading that requires Java Platform to run.
But Java doesn't start, so application doesn't work. I tried re-installing both
Java 6u26 and Chrome 12.0.742.100, no luck. It all works fine under IE9.

Good job Google for not fixing it!

Hello - I'm sorry that my earlier fix didn't fully fix the issue.

I'm starting to suspect that there might be a few different bugs in the same area.

Could someone who is still seeing a problem give a clear set of instructions to reproduce this? (Preferably involving an URL that can be visited to demonstrate the problem).

Make an account in http://www.fumbbl.com, create one team, buy the players and try to go PLAY with it.

Tutorials and stuff here: http://www.fumbbl.com/help:

@efreak2004: forgive me for not running a random piece of Java on the internet, but I had a quick look at the HTTP headers at least.
Does it not work if you select "always open files of this type" from the Chrome download shelf?

@scarybeasts. We appreciate your work on this. Could you clarify what version of chrome to use to test your changes? Also, with your changes, what is the expected flow now for jnlp files?

I am running chrome 12.0.742.100. Here is what I am currently experiencing:

1. Click 'Clear auto-opening settings' in chrome://settings/advanced downloads section.
2. Click on a .jnlp link. The .jnlp file will be downloaded to the Chrome download shelf.
3. From the download shelf, select "always open files of this type"
4. From the download shelf, select "open".
5. Java webstart successfully launches.
6. Click on link from step 2. again. Webstart successfully launches.

I think what the community is requesting is the following

1. Click 'Clear auto-opening settings' in chrome://settings/advanced downloads section.
2. Click on a .jnlp link. Webstart successfully launches.

check comment:
  8. http://code.google.com/p/chromium/issues/detail?id=10877#c8
131. http://code.google.com/p/chromium/issues/detail?id=10877#c131
132. http://code.google.com/p/chromium/issues/detail?id=10877#c132

regarding:
144. http://code.google.com/p/chromium/issues/detail?id=10877#c144
tomorrow I'll try to contact application developers for demo/test account,
since I'm kind of reluctant to give you mine ;)  

Also not interested in the cluttered download folder
See http://code.google.com/p/chromium/issues/detail?id=10877#c26

sorry, jircii is an irc client. more info @ jircii.dashnine.org

It's extremely frustrating! The only thing, I can't use Chrome right now, is accessing IP Console for our servers. This URL can not be open with chrome:
https://managementhost/viewer.jnlp(managementhost@0@1310216803551)

It would be nice if you would support this, Every time I think I can move to chrome the inability to kick off JNLP programs makes me move back to firefox.

I just ran into this bug with Google's App Inventor. Though I pass the tests for having Java installed, when I click on 'launch' on this link:

http://appinventor.googlelabs.com/ode/JWSTest/AppInvJWSTest.html

Chrome downloads the jnlp rather than running it.

14.0.835.94 beta
OS X 10.7.1

This issue is still occurring for me as well using Chromium 15.0.866.0 (Developer Build 98596 Windows)

Same problem here [13.0.782.215 (Build 97094 Linux)].
Switching to Firefox/Seamonkey until this gets fixed...

This was working great, until 15.0.874.5 dev-m broke it, click on downloaded.jnlp now nothing happens.

This problem is not fixed!
Java webstart should automatically run jnlp upon clicking on the link.
It should not be downloaded first and then run!
Google, please fix this or you will lose many chrome users.