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

Steps to reproduce:

Download Java Web Start application from our Oracle EBS.

Actual results:

JNLP file extension is removed. The extension is removed, and it's just saved as "file"

Expected results:

When it is downloaded, it should keep the JNLP file extension

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.

(In reply to scott.bondy from comment #0)

Download Java Web Start application from our Oracle EBS.

Is there a publicly accessible link?

If not, please provide a screenshot of the server response headers. This type of issue could be caused by the Content-Disposition header.

1. Press Ctrl+Shift+J to bring up the Browser Console.
2. Enable nothing but Requests in the filters at the top.
3. Press either the trash can icon or Ctrl+Shift+L to clear the console if necessary.
4. Download the file.
5. Click the dropdown arrow next to the relevant entry to expand it, and make sure the Response Headers section is fully visible in the screenshot. Alternatively, you can switch on Raw in the top right corner and copy and paste the headers instead.

GEThttp://odlapp01.odl.pri:8000/OA_HTML/RF.jsp?function_id=70&resp_id=20420&resp_appl_id=1&security_group_id=0&lang_code=US&oas=jOlzqjDNPkNByK7s4Qe6ig..
[HTTP/1.1 302 Moved Temporarily 136ms]

GET
http://odlapp01.odl.pri:8000/OA_HTML/RF.jsp?function_id=70&resp_id=20420&resp_appl_id=1&security_group_id=0&lang_code=US&oas=jOlzqjDNPkNByK7s4Qe6ig..
Status
302
Moved Temporarily
VersionHTTP/1.1
Transferred486 B (5.48 KB size)
Referrer Policystrict-origin-when-cross-origin

Connection
	Keep-Alive
Content-Type
	text/html; charset=UTF-8
Date
	Wed, 09 Feb 2022 19:54:26 GMT
Keep-Alive
	timeout=15
Location
	http://odlapp01.odl.pri:8000/OA_HTML/runforms.jsp?resp_app=SYSADMIN&resp_key=SYSTEM_ADMINISTRATOR&secgrp_key=STANDARD&start_func=FND_FNDPOMPO&other_params=
Set-Cookie
	JSESSIONID=2145290f693d61f743fdf1d54b4f95561911b44e307bb4db9c9f59a5dfd45273.e34Tc34Tbx4Qci0QaNyRbNqKa40; path=/OA_HTML
Transfer-Encoding
	chunked
	
Accept
	text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Encoding
	gzip, deflate
Accept-Language
	en-US,en;q=0.5
Connection
	keep-alive
Cookie
	JSESSIONID=2145290f693d61f743fdf1d54b4f95561911b44e307bb4db9c9f59a5dfd45273.e34Tc34Tbx4Qci0QaNyRbNqKa40; oracle.uix=0^^GMT-5:00^p; prd=HZh6SrJbTaFHhKunf38flXOlyo
Host
	odlapp01.odl.pri:8000
Referer
	http://odlapp01.odl.pri:8000/OA_HTML/OA.jsp?OAFunc=OAHOMEPAGE&akRegionApplicationId=0&navRespId=20420&navRespAppId=1&navSecGrpId=0&transactionid=1634534174&oapc=4&oas=nst7ujetBadUS8XhShQHGQ..
Upgrade-Insecure-Requests
	1
User-Agent
	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0

GEThttp://odlapp01.odl.pri:8000/OA_HTML/runforms.jsp?resp_app=SYSADMIN&resp_key=SYSTEM_ADMINISTRATOR&secgrp_key=STANDARD&start_func=FND_FNDPOMPO&other_params=
[HTTP/1.1 302 Moved Temporarily 67ms]

GET
http://odlapp01.odl.pri:8000/OA_HTML/runforms.jsp?resp_app=SYSADMIN&resp_key=SYSTEM_ADMINISTRATOR&secgrp_key=STANDARD&start_func=FND_FNDPOMPO&other_params=
Status
302
Moved Temporarily
VersionHTTP/1.1
Transferred945 B (5.48 KB size)
Referrer Policystrict-origin-when-cross-origin

Connection
	Keep-Alive
Content-Type
	text/html; charset=UTF-8
Date
	Wed, 09 Feb 2022 19:54:26 GMT
Keep-Alive
	timeout=15
Location
	http://odlapp01.odl.pri:8000/forms/frmservlet?lang=US&serverApp=OracleApplications&digitSubstitution=CONTEXT&env=NLS_LANG='AMERICAN_AMERICA'+FORMS_USER_DATE_FORMAT='DD-MON-RRRR'+FORMS_USER_DATETIME_FORMAT='DD-MON-RRRR+HH24%3AMI%3ASS'+NLS_DATE_LANGUAGE='AMERICAN'+NLS_SORT='BINARY'+NLS_NUMERIC_CHARACTERS='.,'&browserName=firefox&gp16=http_ticket&gv16=MrenNAeuXpj0EjXDkxOZ2Q..&jnlp_sis_session_id=firefox_0&form_params=+config='prd'+icx_ticket='.f1GBVpmakPmPxDi8jew2CA..'+resp='SYSADMIN%2FSYSTEM_ADMINISTRATOR'+secgrp='STANDARD'+start_func='FND_FNDPOMPO'+other_params=''&encoding=UTF-8&fsst=NLMry0vPSEr_MxVY2NvRDA..
Set-Cookie
	JSESSIONID=2145290f693d61f743fdf1d54b4f95561911b44e307bb4db9c9f59a5dfd45273.e34Tc34Tbx4Qci0QaNyRbNqKa40; path=/OA_HTML
Transfer-Encoding
	chunked
	
Accept
	text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Encoding
	gzip, deflate
Accept-Language
	en-US,en;q=0.5
Connection
	keep-alive
Cookie
	JSESSIONID=2145290f693d61f743fdf1d54b4f95561911b44e307bb4db9c9f59a5dfd45273.e34Tc34Tbx4Qci0QaNyRbNqKa40; oracle.uix=0^^GMT-5:00^p; prd=HZh6SrJbTaFHhKunf38flXOlyo
Host
	odlapp01.odl.pri:8000
Referer
	http://odlapp01.odl.pri:8000/OA_HTML/OA.jsp?OAFunc=OAHOMEPAGE&akRegionApplicationId=0&navRespId=20420&navRespAppId=1&navSecGrpId=0&transactionid=1634534174&oapc=4&oas=nst7ujetBadUS8XhShQHGQ..
Upgrade-Insecure-Requests
	1
User-Agent
	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0

GEThttp://odlapp01.odl.pri:8000/forms/frmservlet?lang=US&serverApp=OracleApplications&digitSubstitution=CONTEXT&env=NLS_LANG='AMERICAN_AMERICA'+FORMS_USER_DATE_FORMAT='DD-MON-RRRR'+FORMS_USER_DATETIME_FORMAT='DD-MON-RRRR+HH24:MI:SS'+NLS_DATE_LANGUAGE='AMERICAN'+NLS_SORT='BINARY'+NLS_NUMERIC_CHARACTERS='.,'&browserName=firefox&gp16=http_ticket&gv16=MrenNAeuXpj0EjXDkxOZ2Q..&jnlp_sis_session_id=firefox_0&form_params=+config='prd'+icx_ticket='.f1GBVpmakPmPxDi8jew2CA..'+resp='SYSADMIN/SYSTEM_ADMINISTRATOR'+secgrp='STANDARD'+start_func='FND_FNDPOMPO'+other_params=''&encoding=UTF-8&fsst=NLMry0vPSEr_MxVY2NvRDA..
[HTTP/1.1 200 OK 47ms]

GET
http://odlapp01.odl.pri:8000/forms/frmservlet?lang=US&serverApp=OracleApplications&digitSubstitution=CONTEXT&env=NLS_LANG='AMERICAN_AMERICA' FORMS_USER_DATE_FORMAT='DD-MON-RRRR' FORMS_USER_DATETIME_FORMAT='DD-MON-RRRR HH24:MI:SS' NLS_DATE_LANGUAGE='AMERICAN' NLS_SORT='BINARY' NLS_NUMERIC_CHARACTERS='.,'&browserName=firefox&gp16=http_ticket&gv16=MrenNAeuXpj0EjXDkxOZ2Q..&jnlp_sis_session_id=firefox_0&form_params= config='prd' icx_ticket='.f1GBVpmakPmPxDi8jew2CA..' resp='SYSADMIN/SYSTEM_ADMINISTRATOR' secgrp='STANDARD' start_func='FND_FNDPOMPO' other_params=''&encoding=UTF-8&fsst=NLMry0vPSEr_MxVY2NvRDA..
Status
200
OK
VersionHTTP/1.1
Transferred242 B (5.48 KB size)
Referrer Policystrict-origin-when-cross-origin

Connection
	Keep-Alive
Content-Type
	application/x-java-jnlp-file; charset=ISO-8859-1
Date
	Wed, 09 Feb 2022 19:54:26 GMT
Keep-Alive
	timeout=15
Last-Modified
	Wed, 09 Feb 2022 19:54:26 GMT
Transfer-Encoding
	chunked
	
Accept
	text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Encoding
	gzip, deflate
Accept-Language
	en-US,en;q=0.5
Connection
	keep-alive
Cookie
	oracle.uix=0^^GMT-5:00^p; prd=HZh6SrJbTaFHhKunf38flXOlyo
Host
	odlapp01.odl.pri:8000
Referer
	http://odlapp01.odl.pri:8000/OA_HTML/OA.jsp?OAFunc=OAHOMEPAGE&akRegionApplicationId=0&navRespId=20420&navRespAppId=1&navSecGrpId=0&transactionid=1634534174&oapc=4&oas=nst7ujetBadUS8XhShQHGQ..
Upgrade-Insecure-Requests
	1
User-Agent
	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0

Any updates on this bug?

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

(In reply to Florent from comment #6)

Same problem here

I'll go ahead and confirm this report then, though I can't reproduce the issue. The following link works for me:
https://bip.weizmann.ac.il/course/prog2/tutorial/deployment/webstart/Notepad.jnlp

What I find odd is that you are not seeing a Content-Disposition header which is where the filename usually is specified in the case of a scripted URL. Could you compare the headers in another browser that preserves the file extension? That might be in the Dev Tools (F12), Network panel. Does that browser show a Content-Disposition Header from the server?

See the debug network result on Chromium who it's work on, frmservlet is properly with JNLP extension:

Request Method: GET
Status Code: 200 OK
Remote Address: x.x.x.x:8888
Referrer Policy: strict-origin-when-cross-origin
Cache-Control: no-cache
Connection: Keep-Alive
Content-Length: 3652
Content-Type: application/x-java-jnlp-file
Date: Wed, 16 Feb 2022 09:40:00 GMT
Keep-Alive: timeout=5, max=100
X-Content-Type-Options: nosniff
X-ORACLE-DMS-ECID: 005q1xivWotDsXH6yvaeMG00DxC400030E
X-ORACLE-DMS-RID: 0:1
X-XSS-Protection: 1; mode=block
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate, br
Accept-Language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7
Connection: keep-alive
Host: mytest.fr:8888
Referer: https://mytest.fr/
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="98"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-site
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.82 Safari/537.36```

On Firefox file register with no extension: frmservlet
On Chromium register with frmservlet.jnlp

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

Problem is more complicated because it works on Firefox 91.6 ESR but not work on 91.0 or 91.0.2 Release.
And on Mozregression tools, i can't choose this difference of canal.

I want to be sure for the next ESR version (102?) it will continue to work like today for ESR.

Is it reproducible with 91.5 ESR or earlier?

Not reproducible with Firefox ESR 91.*
Problem not happen on ESR, only problem on the "classic" channel

Not sure if this is what you're looking for. I put it in the attachments.

This is not working on 97.0.1 either.

I threw up a PHP page for testing at https://www.jeffersonscher.com/res/somejnlp.php

<?php
// Send header
header("Content-type: application/x-java-jnlp-file");
// Construct page
echo "We have no XML today."
?>

The file is saved either as somejnlp.php or somejnlp.php.jnlp depending on the current handling preference:

(1) Save File, or Always Ask => Save File

Neither Firefox 97.0.1 nor Firefox 91.6.0esr adds .jnlp to the file name when saving.

(2) Use Java(TM) Web Launcher (default)

Firefox 97 does not add .jnlp but Firefox 91.6.0esr does.

(3) Use other... then manually navigate to javaws.exe

Both Firefox 97.0.1 and Firefox 91.6.0esr add .jnlp to the file name when saving and launching.

I think this is different from other Content-Type file extension corrections. Is it because JNLP is executable?

Sounds like this problem can easily be recreated. Is there a fix in the works?

The severity field is not set for this bug.
:kershaw, could you have a look please?

For more information, please visit auto_nag documentation.

With the test url in comment #17 and select Java(TM) Web Launcher to open JNLP as default, I've found the regressed patch below by mozregression.

2022-02-28T22:43:59.308000: DEBUG : Found commit message:
Bug 1752159 - check if target is executable before offering always opening, r=mhowell,mtigley

Depends on D137152

Differential Revision: https://phabricator.services.mozilla.com/D137153

2022-02-28T22:43:59.308000: DEBUG : Did not find a branch, checking all integration branches
2022-02-28T22:43:59.308000: INFO : The bisection is done.
2022-02-28T22:43:59.308000: INFO : Stopped

Gijs, could you take a look?
Thanks.

Ugh.

To be honest, based on the screenshot from jscher, I do not really understand why the specific java app used to open the file makes a difference. I expect it is to do with using the system default vs. using a manually picked executable (ie picking the executable to use for opening from within Firefox)? That is, if you make the "Java (tm) web start launcher" application the default in Windows, and restart Firefox, then add the other app as a handler inside Firefox ("manually"), then I expect the behaviour described in the screenshot flips between the two. Is that correct?

This whole situation is pretty weird, for a few different reasons:

• Under what circumstances should we just append file extensions, if the server doesn't provide one either in Content-Disposition headers or in the URL? We've discussed this in the past but all obvious solutions have downside. Especially on non-Windows, it is perfectly reasonable to have extension-less README or LICENSE files that contain plaintext, and it'd be annoying if the browser insisted on suffixing an extension. AIUI there is no spec for this. We could try to reverse-engineer what Chromium does some more, I guess, but that's not particularly attractive, especially because the behaviour might suit for jnlp but might not for other cases (which are hardly going to be documented). I'm almost sure we have a bug on file for this - Marco, do you have that to hand?
• This seems to have only kind of worked before anyway (and never (?) worked if set to "always ask" or to "save to disk"?), somewhat by accident - why doesn't the server send a meaningful filename in either URL or header?
• why does java have two different apps to open these things with?!
• there is a long and very sad story about whether jnlp files count as "executable". In brief, I think it would be fair to say that Oracle and security researchers have... differing opinions... on the answer to that question. Mike, I thought you were working on a more long-term solution there, in bug 1576762 and co?

(In reply to Kershaw Chang [:kershaw] from comment #20)

Differential Revision: https://phabricator.services.mozilla.com/D137153

That commit... doesn't make an awful lot of sense in this instance. This is https://hg.mozilla.org/mozilla-central/rev/a278575bb4ec - it only changes code that runs in the "always ask" dialog, and it governs whether the preference to open with a specific file is remembered. How is that making a difference to what the filename is, especially if you're running mozregression in the default configuration, where on nightly at that point browser.download.improvements_to_download_panel would already have been true, and we thus wouldn't be hitting this case at all (ie the dialog wouldn't be showing up so that code wouldn't run). Unless... is the security check there causing this dialog to show up, instead of auto-opening the file? And in the "good" case, the dialog doesn't show at all? But that wasn't very clear from your comment...

Otherwise, based on jscher's screenshot, I'm afraid that even if we were to fix this theoretical case, it would be broken in 98 and later anyway because the new default will be "save to disk", and apparently that case has been "broken" for a very long time? :-\

Kershaw, can you give some context?

Would it be appropriate to add .jnlp to the set of MIME types handled by sanitize_non_media_extensions, or are "executables" excluded from that?

I can give some details about my STR for this issue.
Setup:

1. Make "Java (tm) web start launcher" the default application to open JNLP file in windows.
2. In Firefox, set the default action for JNLP to "Use Java(TM) Web Launcher (default)".

STR:

1. Open this link.
2. Before Firefox 97, the "Open Executable File?" dialog is shown and asking whether to launch the file. Note that .jnlp extension is attached to file name (somejnlp.php.jnlp). When clicking OK, the file is saved and JAVA launcher is used to open this file.
3. In Firefox 97, the "Save File" dialog (like comment #1) is shown and asking whether to save the file. When clicking Save File, Firefox only saves the file. JAVA launcher is not started. Note that at this point, the default application for JNLP in Firefox is changed to Always ask.

(In reply to Kershaw Chang [:kershaw] from comment #23)

I can give some details about my STR for this issue.
Setup:

1. Make "Java (tm) web start launcher" the default application to open JNLP file in windows.
2. In Firefox, set the default action for JNLP to "Use Java(TM) Web Launcher (default)".

STR:

1. Open this link.
2. Before Firefox 97, the "Open Executable File?" dialog is shown and asking whether to launch the file. Note that .jnlp extension is attached to file name (somejnlp.php.jnlp). When clicking OK, the file is saved and JAVA launcher is used to open this file.
3. In Firefox 97, the "Save File" dialog (like comment #1) is shown and asking whether to save the file. When clicking Save File, Firefox only saves the file. JAVA launcher is not started. Note that at this point, the default application for JNLP in Firefox is changed to Always ask.

I think you refer to another problem.
Apart from launch, the basic problem is : file not save with .jnlp extension.
Same on last Firefox nightly

3. In Firefox 97, the "Save File" dialog (like comment #1) is shown and asking whether to save the file. When clicking Save File, Firefox only saves the file. JAVA launcher is not started. Note that at this point, the default application for JNLP in Firefox is changed to Always ask.

I think you refer to another problem.
Apart from launch, the basic problem is : file not save with .jnlp extension.
Same on last Firefox nightly

Sorry that forgot to mention that in my last step, the file is saved without .jnlp extension. So, I think what I saw is the same problem.

The reason you can't launch JNLP files on release is because on ESR we allow JNLP as a helper:

https://bugzilla.mozilla.org/show_bug.cgi?id=1722314

bug 1722050 is my plan to move this configuration into policy so it can work on rapid release.

Thanks Mike for the explanation.
Does this mean it will still like that for the next 102ESR ?

Does this mean it will still like that for the next 102ESR ?

Yes, if I don't get the policy implemented by 102, I will port the patch again.

we have the same problem, the file will be saved as "a-name" and not "a-name.jnlp". So the user has to open the file explorer and rename the file (Windows) to be able to start the application.
see the closed https://bugzilla.mozilla.org/show_bug.cgi?id=1756539
Our fallback will be Chrome where the file is saved as "a-name.jnlp" ... :-(

I wonder if the patches in bug 1746052 will end up helping here.

Oops, meant to set a dependency. Will also add the policy bug as such.

Could someone confirm if this situation has improved on current Nightly 102 with the fix from bug 1746052? I'd expect the filenames to get extensions now.

Sorry for the delay, i confirm it's okay on 103.0a1

Marking this verified per the bottom comment, assuming this is by virtue of the fixes in bug 1746052 and thus fixed in 102