User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0

Steps to reproduce:

The last FF version ignore the option "Open with java web start" for JNLP files.

Actual results:

The browser always shows "save file" dialog for jnlp files. Others users report the same bug.

Expected results:

JNLP files shoud be start, the previous FF version work fine

The Bugbug bot thinks this bug should belong to the 'Firefox::File Handling' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

can you run https://mozilla.github.io/mozregression/
It should help us figure out which change broke this behavior.
Thank you.

In two SUMO threads, users found that they could restore the previous behavior by changing the file association for .jnlp in the Windows Default Apps settings or in Firefox's Application handling settings. For reference:

• First user (detailed steps): https://support.mozilla.org/en-US/questions/1368109#answer-1484095
• Second user (confirmation): https://support.mozilla.org/en-US/questions/1367528#answer-1484143

I think this is an expected side effect of bug 1752159 where we now refuse to automatically run executable files. JNLP is deemed to be an executable file (bug 1392955), and so if the filetype is set to be opened automatically, we save to disk instead. You can still open the file from the download panel.

The alternative would be that anybody who redirected you to a random JNLP file would automatically run code on your machine. That is bad.

(Yes, in theory there are signing reasons why this might not happen for all users - but Firefox has no control over those and can't check them, so we err "on the safe side".)

I don't think there is much we can do here on a short-term basis, but if there are reasonable suggestions that don't reopen that security bug, I'm all ears.

But if you don't trust the program opening (and thus:runnin) the downloaded metadata-file (and a jnlp file is not more) you'd need to do the same thing with .docx files or even html which contains JavaScript.
I strongly suggest to allow downloading and running or jnlp; there are still a lot of business apps out there that rely on jnlp. And the end users are often confused if automatic opening doesn't work.

Because the other bug report is closed: https://bugzilla.mozilla.org/show_bug.cgi?id=1756539

That bug is a bit different because the file that is saved is not a *.jnlp-file but a file named jnlp.
No filename extension. And that is the real problem (Windows). The user has to download the file, rename the file and start it.

(In reply to johannes.michler from comment #6)

But if you don't trust the program opening (and thus:runnin) the downloaded metadata-file (and a jnlp file is not more) you'd need to do the same thing with .docx files

By default docx files don't run script; MS Word will prompt you.

or even html which contains JavaScript.

We do the same for JS files (it's in the same list, cf. https://searchfox.org/mozilla-central/rev/9ca193b4233957439583f2eadabbd3cfb4cd9fed/xpcom/io/nsLocalFileCommon.cpp#61-62 ), yes, and we have separate bugs on file about how to treat downloaded HTML files and how to deal with the relevant security risk.

But otherwise this is basically whataboutery. Yes, it's difficult to have a complete list of executable files, and yes people disagree about whether jnlp should count as such. But practically:

I strongly suggest to allow downloading and running or jnlp; there are still a lot of business apps out there that rely on jnlp.

This fails to address my point:

(In reply to :Gijs (he/him) from comment #5)

The alternative would be that anybody who redirected you to a random JNLP file would automatically run code on your machine. That is bad.
I don't think there is much we can do here on a short-term basis, but if there are reasonable suggestions that don't reopen that security bug, I'm all ears.

That is, your "strong suggestion" just reopens the security issue. We should not do that.

I think the only plausible way out here is finding a way to improve the handling, that is pretty much Bug 1576762, thus duping there.