Chromium

sumancse@Could you please provide sample website with JNLP link in it with screencast for further triaging the issue.

[Monorail components: UI>Browser>Downloads]

Here is a simple example.
Please visit the below website
http://docs.oracle.com/javase/tutorial/uiswing/examples/misc/index.html

This will show a list of examples of JNLP. Please click on any example to launch the JNLP files.
Expected behavior: Since we are trying to open a JNLP file its should prompt for open else save. But Chrome offer only Save option.
Snapshort 1.png shows this

Please click on the Same link again. Chrome downloads the file again and again but does not allow user to associate the file with a JRE type so that it can be opened the next time user click on a similar file type.
Please see Snapshort2.png and Snapshort3.png

Thank you for providing more feedback. Adding requester "ssamanoori@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce the issue on Windows 7, Mac 10.11.5, Ubuntu 14.04 using 51.0.2704.84, latest stable 51.0.2704.106, canary 53.0.2782.0 as per steps in https://crbug.com/chromium/619933#c2.

This is regression issue broken in M-45.

Please find below bisect info:
Last good build:45.0.2433.0
First bad build:45.0.2434.0

CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/9927cd52db43823e2bc60e76f880725b17bee5d1..39841e54180e2583dffa16fbbb9b99fd293821d0

From above CL, suspecting below:
https://chromium.googlesource.com/chromium/src/+/39841e54180e2583dffa16fbbb9b99fd293821d0

asanka@Could you please look into this issue if it is related to your change, else feel free to assign it to an appropriate dev person.

Thanks,

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Please let me know what is the status of this defect. We also see another issue related to this.

Some JNLP files needs to be associated with a browser session or invoked via a browser after being authenticated workflow by the server.

By saving these file to disk, we do have an issue, as any other user who has access to the machine can open or launching these JNLP files being invoked and the application being launched.

Handling such cases will be difficult, the only option we would have is to block such browser from accessing the web site or session based on browser type.

Is there any chance this will be fixed. It's a blocker in moving from Applets to JNLP. This works fine on IE & Firefox, but is a bug in Chrome.  

Adding @rdsmith for perhaps closing this.

Asanka's the right person to decide what to do with this, not me.

This bug is further compounded by https://crbug.com/chromium/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.

This seems to be a dupe of 518170

https://bugs.chromium.org/p/chromium/issues/detail?id=518170

This bug needs to be corrected so that users can choose whether or not they want to save each time they hit such a URL or just have this file type just open automatically.

To the comment made by  jsivagt...@gmail.com regarding the file being created repeatedly, this is planned to be corrected by Oracle in a coming release.  With Oracle's change and until Google changes the Chrome behavior noted in this bug (and 518170), you will be prompted to save the jnlp file.  Once saved, a reference to it will appear at the bottom of your Chrome window. By clicking on this reference the jnlp will run. Upon start up, the jnlp file will be removed. This user can rerun it later by accessing it from the Java Control Panel.  You can get a beta of the new java version from here:

https://jdk8.java.net/download.html

#11: I believe the request here is to allow opening the .jnlp file, probably off a temporary location, without leaving an artifact on the disk. And should be considered a duplicate of the depressingly long lived https://crbug.com/chromium/333.

#6: Relying on the .jnlp file not being locatable for security is poor design. If users should be restricted from running a specific app, the authorization controls should be implemented elsewhere. This isn't the way to do it.

#12 - it looks like Java relies on the browser launching Java Web Start (or whatever) with the URL of the JNLP as its parameter instead of downloading it in the first place (Or just the headers in order to identify the content type).

[Empty comment from Monorail migration]

#12 Considering we modify our design not to depend on the JNLP file downloaded, we still end up downloading these file from each time the application is launched and the Downloads folder will be simply filled by these files.

User is forced to clean up this file each time its downloaded.
Since the mime type for JNLP file is also mentioned when JNLP files are served by the server. I think browser can identify the JNLP file and must launch the Java Web Start.

#15: Understood. There should be a way to identify "open-only" downloads and handle them appropriately so that folks don't end up with a bunch of useless files on their disks.

For your use case, would some means of whitelisting an origin + a file type work? I.e. if Chrome were to be able to detect that .jnlp files from https://foo.example.com should be opened without retaining the download file, would that suffice?

#16 The Open-only should be present, as mentioned if you are able to detect the JNLP file coming from a server and opening it with the associated application defined by the user should suffice.

Please for the love of god fix this soon

[Comment Deleted]

This issue was migrated from crbug.com/chromium/619933?no_tracker_redirect=1

[Monorail mergedinto: crbug.com/chromium/333]
[Monorail components added to Component Tags custom field.]