1328716 - Ciena Ethernet Services Manager depends on navigator.mimeTypes['application/x-java-jnlp-file'] being truthy if the UA string indicates Firefox

Status: RESOLVED WONTFIX

(Web Compatibility :: Site Reports, defect, P3)

Description

[ddavis]

Attachment: Firefox-48-plus-WebStart

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161129173726

Steps to reproduce:

Run this inside of Firefox 47.0.1 with a Javascript interpreter, having Java JRE 8u111 installed (including browser plugin). This code snippet should return "Web start is Installed".

if (navigator.mimeTypes && navigator.mimeTypes.length)
{
	x = navigator.mimeTypes['application/x-java-jnlp-file'];
	if (navigator.userAgent.toLowerCase().indexOf('chrome') > -1 || x)
	{
		alert("Web start is Installed");
	}
	else
	{
		alert("Web start is Not Installed");
	}
}

Then run the same snippet in Firefox 48.0.2 with the same version of Java. YOu will find that this returns "Web start is Not Installed".


Actual results:

Alert in FF 48+ returns "Web start is Not Installed"


Expected results:

Alert in FF 48+ should have returned "Web start is installed"

Comment 1

[ddavis]

Attachment: Firfox-47-test

This is the result of running the js snippet in firefox 47.

Comment 2

[ddavis]

Comment on attachment 8823826 [details]
Firefox-48-plus-WebStart

This is the result of running the js snippet in FF 48. The result is not the desired one. Why is this? What changed between versions?

Comment 3

[Loic]

Attachment: 1328716.html

Comment 4

[Loic]

It's due to:
Boris Zbarsky — Bug 1144204. Stop returning things for non-plug-in MIME types from the navigator.mimeTypes getter. r=smaug 

bz, is it normal?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Is that type one of the types listed for the Java plugin in about:plugins?  If not, then this is normal, yes.

Does navigator.mimeTypes['application/x-java-jnlp-file'] return truthy in any other browser?  Note that the code snippet in comment 0 explicitly doesn't bother checking it in Edge or Chrome, which are the only two other modern browsers on Windows...

Comment 6

[Loic]

My list of types for the Java plugin:

application/x-java-applet	Java Applet	
application/x-java-bean	JavaBeans	
application/x-java-vm		
application/x-java-applet;version=1.1.1		
application/x-java-bean;version=1.1.1		
application/x-java-applet;version=1.1		
application/x-java-bean;version=1.1		
application/x-java-applet;version=1.2		
application/x-java-bean;version=1.2		
application/x-java-applet;version=1.1.3		
application/x-java-bean;version=1.1.3		
application/x-java-applet;version=1.1.2		
application/x-java-bean;version=1.1.2		
application/x-java-applet;version=1.3		
application/x-java-bean;version=1.3		
application/x-java-applet;version=1.2.2		
application/x-java-bean;version=1.2.2		
application/x-java-applet;version=1.2.1		
application/x-java-bean;version=1.2.1		
application/x-java-applet;version=1.3.1		
application/x-java-bean;version=1.3.1		
application/x-java-applet;version=1.4		
application/x-java-bean;version=1.4		
application/x-java-applet;version=1.4.1		
application/x-java-bean;version=1.4.1		
application/x-java-applet;version=1.4.2		
application/x-java-bean;version=1.4.2		
application/x-java-applet;version=1.5		
application/x-java-bean;version=1.5		
application/x-java-applet;version=1.6		
application/x-java-bean;version=1.6		
application/x-java-applet;version=1.7		
application/x-java-bean;version=1.7		
application/x-java-applet;version=1.8		
application/x-java-bean;version=1.8		
application/x-java-applet;jpi-version=1.8.0_111		
application/x-java-bean;jpi-version=1.8.0_111		
application/x-java-vm-npruntime		
application/x-java-applet;deploy=11.111.2		
application/x-java-applet;javafx=8.0.111

Comment 7

[Boris Zbarsky [:bzbarsky]]

OK, well, that type is not in the list.

Does it appear in navigator.mimeTypes in any other browser?

Comment 8

[ddavis]

Attachment: allbrowsers.PNG

This is what I've got.

Comment 9

[ddavis]

This JavaScript snippet is really just checking to see if the browser in use is Chrome or Firefox. An omitted portion of the code also checks for IE. The code always works in Chrome, but not in FF after 48. Why would this MIME type not be listed after 47?

Comment 10

[Boris Zbarsky [:bzbarsky]]

> This is what I've got.

That doesn't answer my question, really.  It shows that navigator.mimeTypes is a lot longer in the browser on the far right (whichever one that is), but nothing about what navigator.mimeTypes['application/x-java-jnlp-file'] is in any of the browsers involved.

> This JavaScript snippet is really just checking to see if the browser in use is Chrome or Firefox.

Um... what does that have to do with "Web Start"?

> Why would this MIME type not be listed after 47?

Before Firefox 47, navigator.mimeTypes[foo] would return a truthy thing for any type "foo" that the operating system knew anything about.  Starting with Firefox 47, it only does that for a type handled by a plug-in, which is what other browsers do, as far as I know.

Comment 11

[ddavis]

(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #10)
> > This is what I've got.
> 
> That doesn't answer my question, really.  It shows that navigator.mimeTypes
> is a lot longer in the browser on the far right (whichever one that is), but
> nothing about what navigator.mimeTypes['application/x-java-jnlp-file'] is in
> any of the browsers involved.

My apologies on providing impertinent information. 

> 
> > This JavaScript snippet is really just checking to see if the browser in use is Chrome or Firefox.
> 
> Um... what does that have to do with "Web Start"?

I suppose you are correct. We are dealing with an old system that uses WebStart to run a login prompt, and the code supplied in comment 0 is the code that stopped detecting Java Web Start after 47, and end-users had to use a work-around to access the prompt (you know how end-users are when things don't work as transribed on screen). We here at my organization weren't sure what had changed.

> 
> > Why would this MIME type not be listed after 47?
> 
> Before Firefox 47, navigator.mimeTypes[foo] would return a truthy thing for
> any type "foo" that the operating system knew anything about.  Starting with
> Firefox 47, it only does that for a type handled by a plug-in, which is what
> other browsers do, as far as I know.

This information is helpful and I appreciate the time you took to look at this.

Is there a patch note that you can link me to that reveals this change in handling types?

Comment 12

[Boris Zbarsky [:bzbarsky]]

I;m not sure what you mean by "patch note", but https://bugzilla.mozilla.org/show_bug.cgi?id=1144204 is the ticket where the change was made.  The new behavior more closely follows the HTML spec, aligns better with other UAs, and fixes at least one web site that was known to be broken with the old behavior (see <https://webcompat.com/issues/1984>).

It doesn't look like this change was release-noted or anything like that....

Comment 13

[ddavis]

Thank you for the information. I will pass this on. We try to use FF as much as possible here, but looks like we have to switch to Chrome for administering quite a few devices now.

Comment 14

[Boris Zbarsky [:bzbarsky]]

You don't control the script in question?  Who does?

Comment 15

[Boris Zbarsky [:bzbarsky]]

Note that if you really just want to keep using Firefox and don't control these pages you can probably do that by overriding what navigator.userAgent returns for the sites in question to include the string "chrome" somewhere.  Let me know if that's useful and I can point you to some resources.  But I'd like to understand whether someone other than your organization might be affected by this problem...

Comment 16

[ddavis]

Attachment: ciena.PNG

The device is a Ciena device, so they wrote the code for the detection. Attached is an image of the JS built into the page with the Web Start launcher and offending JS highlighted. Does this information help in any way?

And yes, any information you could provide as a work-around for the modifying the useragent string would be helpful.

Comment 17

[ddavis]

Attachment: ciena2.png

Here's another image of the actual JS.

Comment 18

[Boris Zbarsky [:bzbarsky]]

Hmm.  I don't see anything in that JS that examines navigator.userAgent, so it's not clear to me that modifying the UA string would help.

If modifying it _would_ help, https://addons.mozilla.org/en-US/firefox/addon/user-agent-js-fixer/ might be a reasonable approach.

Comment 19

[Boris Zbarsky [:bzbarsky]]

https://addons.mozilla.org/en-US/firefox/addon/user-agent-switcher-firefox/ might also be useful.

Comment 20

[ddavis]

(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #18)
> Hmm.  I don't see anything in that JS that examines navigator.userAgent, so
> it's not clear to me that modifying the UA string would help.
> 
> If modifying it _would_ help,
> https://addons.mozilla.org/en-US/firefox/addon/user-agent-js-fixer/ might be
> a reasonable approach.

Thanks for the link. Tested this add-on with FF 50.0.2 with no change. When clicking the "Web Start Client" launcher, I get the same results as before. 

Perhaps it is now the vendor's responsibility to update their method. I brought this issue up on bugzilla.mozilla.org because I feared that this change may effect many other users than just those in my organization.

Comment 21

[ddavis]

(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #19)
> https://addons.mozilla.org/en-US/firefox/addon/user-agent-switcher-firefox/
> might also be useful.

This add-on works. We may look into deploying FF via CCK2 to include this extension for users who need it. Not the most elegant solution, but we may be able to work with it.

Comment 22

[Boris Zbarsky [:bzbarsky]]

> I brought this issue up on bugzilla.mozilla.org because I feared that this
> change may effect many other users than just those in my organization.

Right, that's my worry too, hence trying to figure out the details.  Any information you are able to provide about which exact device this is so we can contact Siena about it would be very much appreciated!  We can try to add some sort of workaround for their code, but it really would be better if they fixed their thing to not do UA sniffing.  :(

Comment 23

[Boris Zbarsky [:bzbarsky]]

I guess the important part is that this is the Ethernet Services Manager software, right?

Comment 24

[Boris Zbarsky [:bzbarsky]]

Tried contacting them via https://twitter.com/bz_moz/status/819258305507983361

Comment 25

[Adam Stevenson [:adamopenweb]]

Thanks bz, setting whiteboard to sitewait.

Comment 26

[ddavis]

(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #23)
> I guess the important part is that this is the Ethernet Services Manager
> software, right?

Yup, that's ESM Version R.6.2.0.35, but we have several devices with version R.6.5.0.44 that have the very same issue. I don't believe that the device type is important in this scenario. We use a diverse array of their devices, all of which have the Ethernet Services Manager.

Thanks for the tweet bz.

Comment 27

[Mike Taylor [:miketaylr]]

ddavis, do you know if this issue still reproduces, or if they fixed it? Thanks.

Comment 28

[Mike Taylor [:miketaylr]]

Wondering how popular this software is, and if it's important for Enterprise scenarios...

Adam, can you try to get in touch via LinkedIn or something and start a conversation?

Comment 29

[Firefox Bug Husbandry Bot]

See bug 1547409. Moving webcompat whiteboard tags to keywords.

Comment 30

[Oana Arbuzov [:oanaarbuzov]]

The issue is still reproducible.
I've used https://playcode.io/javascript Online Javascript interpreter.
https://prnt.sc/hUtoHqM50Zpp

Tested with:
Browser / Version: Firefox Nightly 102.0a1 (2022-05-16), Firefox Release 100.0
Operating System: Windows 10 Pro

Comment 31

[BugBot [:suhaib / :marco/ :calixte]]

Redirect needinfos that are pending on inactive users to the triage owner.
:denschub, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 32

[Dennis Schubert [:denschub]]

While the testcase still reproduces, I don't think we'll do anything about anything related to in-browser Java. Closing as such.