Closed Bug 56124 Opened 25 years ago Closed 24 years ago

Property navigator.javaAvailable() should show the state of Java support in Mozilla

Categories

(Core Graveyard :: Java: OJI, defect, P4)

Product:
Core Graveyard
Component:
Java: OJI
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 68933
Milestone:
Future

People

(Reporter: bugzilla, Assigned: xiaobin.lu)

Details

Attachments

(5 files)

Testcase for navigator.javaAvailable() check
403 bytes, text/html
Details
An html file which can tell you all the java plugin your system supports
3.42 KB, text/html
Details
Patch to make navigator.javaEnabled() true only if plugin available and pref enabled.
3.95 KB, patch
Details | Diff | Splinter Review
The navigator.javaEnabled() reimplementation(john's patch)
4.16 KB, patch
Details | Diff | Splinter Review
Indentation tab is 2 now
3.90 KB, patch
Details | Diff | Splinter Review
Currently there is no way of telling if the running instance of Mozilla supports Java. There is a property: navigator.javaEnabled() but the only shows the state of the checkbox in the Prefs->Advanced. It would be nice to have some kind of JavaScript property to test if Mozilla supported Java.
Henrik, Can you please attach a test case? Thanks, Ed
Status: NEW → ASSIGNED
Priority: P3 → P4
Target Milestone: --- → Future
Perhaps the property should be called the full name: navigator.javaAvailable A test case could look like: <SCRIPT LANGUAGE="JavaScript" TYPE="text/javascript"> <!-- if (navigator.javaAvailable()) { document.writeln("Java support is installed/available!\n"); if (navigator.javaEnabled()) { document.writeln("and Java is also enabled!"); } else { document.writeln("but Java is *NOT* enabled!"); } } else { document.writeln("Java support is *NOT* installed!\n"); } // --> </SCRIPT>
Summary: Property navigator.javaAvail() should show the state of Java support in Mozilla → Property navigator.javaAvailable() should show the state of Java support in Mozilla
Xiaobin, can you please look into this? Thanks, Ed
Assignee: edburns → xiaobin.lu
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Add Grish to the cc list!
I am trying to figure out the necessity of adding such a method. I believe it will be nice if we add this method. However, navigator object already provides such information in its data member plugins. Also, javaAvailable() only can tell you whether your browser supports java or not,not telling you which jdk version and mimetype it supports. The version of jdk sometimes is more important to the user than to know whether it supports java or not. Another reason which leads me to think its necessity is the way of DOM implementation will be changed soon. Typing about:plugins can tell you all the plugins you have installed in your system. This is why I also try to think to provide such a HTML file and ship with mozilla which can tell you all the java plugin it supports. I attached this HTML for your reference. If it is good, I think it should also be put in same place as about:plugins. How do your guys think?
I think I have attached the HTML file as an attachment but it does not show anything. Clicking the other attachment also show nothing. Maybe this is a bug of BUGZILLA:(. Anyway, I post the html here as a refrence. <!-- -*- Mode: HTML; tab-width: 8; indent-tabs-mode: nil -*- --> <html> <head> <title>About Java Plug-ins Support</title> </head> <body> <script language="JavaScript1.5"> <!-- JavaScript to enumerate and display all installed plug-ins --> <!-- First, refresh plugins in case anything has been changed recently in --> <!-- prefs: (The "false" argument tells refresh not to reload or activate --> <!-- any plugins that would be active otherwise. In contrast, one would --> <!-- use "true" in the case of ASD instead of restarting) --> navigator.plugins.refresh(false); numPlugins = navigator.plugins.length; writeOnce1 = true; for (i = 0; i < numPlugins; i++) { plugin = navigator.plugins[i]; numTypes = plugin.length; writeOnce2 = true; for (j = 0; j < numTypes; j++) { mimetype = plugin[j]; if (mimetype) { enabled = "No"; enabledPlugin = mimetype.enabledPlugin; if (enabledPlugin && (enabledPlugin.name == plugin.name)) enabled = "Yes"; mimeString = mimetype.type; re = /(application\/x-java*)/i; found = mimeString.match(re); if(found && writeOnce1) { document.writeln("<b><font size=+3>Installed Java plug-ins</font></b><br>"); document.writeln("<p><hr>"); writeOnce1 = false; } if(found && writeOnce2){ document.write("<center><font size=\"+1\"><b>"); document.write(plugin.name); document.writeln ("</b></font></center><br>"); document.writeln ("<dl><dd>File name:"); document.write (plugin.filename); document.write("<dd><br>"); document.write (plugin.description); document.writeln("</dl><p>"); document.writeln("<table width=\"100%\" border=\"2\" cellpadding=\"5\">"); document.writeln("<tr><th width=\"20%\"><font size=\"-1\">Mime Type</font></th>"); document.writeln("<th width=\"50%\"><font size=\"-1\">Description</font></th>"); document.writeln("<th width=\"20%\"><font size=\"-1\">Suffixes</font></th>"); document.writeln("<th><font size=\"-1 \">Enabled</th></tr>"); writeOnce2 = false; } if(found){ document.writeln("<tr align=\"center\">"); document.writeln("<td>" + mimetype.type + "</td>"); document.writeln("<td>" + mimetype.description + "</td>"); document.writeln("<td>" + mimetype.suffixes + "</td>"); document.writeln("<td>" + enabled + "</td>"); document.writeln("</tr>"); } } } document.write("</table><p><hr><p>"); } if(writeOnce1) { document.writeln("<b><font size=+3>No Java plug-ins installed</font></b><br>"); document.writeln("Find more information about java plugin at "); document.writeln("<A HREF=\"http://java.sun.com/j2se/1.3/\">Sun Microsystems</A>."); document.writeln("<p><hr>"); } </script> </body> </html>
Henrik: Please let me know how do you think about it? Thanks!
Henrik: If you don't mind, I will close this bug. Thanks!
I'm not sure I agree. Having navigator.javaAvailable() would be a really nice feature to have. Sometimes I just need to check if the user has Java or not. If you have specific needs then you can go through the plugins object to check what version of JVM the user has installed.
But you'd need to do something similar for IE anyway, right?
"But you'd need to do something similar for IE anyway, right?" I dont understand that? Please explain.... What do i need to do for IE????
Henrik, what I meant was that if you wanto figure out in a webpage if java is available in the browser that loads the page you also need to write a bunch of IE specifc code to make the page work in IE too, right? I'm not immediately against adding a property (rather than a method) that tells you if java is available, if we do add one we might as well add one that gives you the version of the JVM as a string, or null if there is no java (or if java is disabled)... Henrik, you said "Sometimes I just need to check if the user has Java or not. If you have specific needs then you can go through the plugins object to check what version of JVM the user has installed." Doesn't navigator.javaEnabled() give you the information you need here then? Or does that property return what the pref is set to, whether or not java is installed? If that's the case maybe the right thing to do is to make navigator.javaEnabled() return true only if java is enabled in the prefs *and* java is installed?
"navigator.javaEnabled()" only reflect the state of the pref. It doesn't matter wheather java is installed or not. Since IE is always delivered with Java, IE only has "navigator.javaEnabled()" I just want to be able to see the two different states: if (!navigator.javaAvailable()) alert("Please install java from here blabla....."); if (!navigator.javaEnabled()) alert("You have java installed but please activate it.....");
Is it important for you to distinguish between the two states, wouldn't something like this be enough? if (!navigator.javaEnabled()) alert("Please make sure java is installed and enabled");
I could find it nice to distinguish between the two states... Telling users to download and install a new JVM is a a pain if the user just has disabled java...
I am sorry for missing the discussion! Johnny, would you like to add this feature or just leave it to the next generation of DOM implemenation?
Could this be related to: http://bugzilla.mozilla.org/show_bug.cgi?id=61474 where the function IsJavaEnabled is created?
In bug 61474, I add a method which can detect whether the user installs java or not and if not, grey out the java console menu. Henrik, is that close to what you mentioned here about adding javaAvailable () method?
I think the method is very close to what I'm asking about. I'm not sure if it should be called JavaAvailable or be a "java" object so that in the future we could have: navigator.java.available navigator.java.version navigator.java.enabled etc...
Good to hear that! Yes, I would like to mark this bug as duplicate of 61474 I fixed before. Thanks! *** This bug has been marked as a duplicate of 61474 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Hmmm.. This bug is not fixed nor a dupe. Neither navigator.javaAvailable() or navigator.javaEnabled() is available. Please explain why this is a bug 61474
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
I mean if your system does not have java installed, however, you have java enabled, you still can't see java console(because it is greying out). This is the whole story of bug 61474. In last comment, I think you thought that is pretty close to what you need, so I mark this bug as dup. If that is not what you mean, I am really sorry.
I want to make sure I understand this bug because what I think is being proposed is illogical. In every Java- and JavaScript-enabled browser that I know of navigator.javaEnabled() returns true when the browser can start and run applets. This needs to be true in Mozilla as well. It sounds like what you're trying to do is have navigator.javaEnabled() return true if the pref is checked on even though a JVM is not installed. That's useless and also breaks code that would work on older browsers. If that's how it currently works, perhaps that should be the bug (and 4xp at that). Now I can see merit to being able to determine that a JVM is installed and not enabled, but it makes more sense to check the other way: if (!navigator.javaEnabled()) // true only when Java is available and enabled { if (navigator.javaAvailable()) alert("You need to enable Java"); else alert("You need to install Java and then enable it"); } I believe Johnny Steinback was saying more or less the same thing above.
I just attached a patch (totally untested, btw) that makes navigator.javaEnabled() return true only if the java plugin is installed and the pref is enabled, this makes alot of sense to me, the current behavior doesn't make sense to me. I haven't yet heard really strong arguments for adding navigator.javaAvailable() to the DOM API yet, but I'd be happy to check in the attached patch (assumin it works :-), or if someone else will relieve me of the trouble of checkin it in and doing that for me I'd be even happier :-) Lemme know what you think.
Thanks, Johhny! It make more sense to me. I will look at the code and test it, if there is no problem, I will check this in!
Thank you Xiaobin.
I have modified the patch a little bit. If java is not enabled, we return right away instead of checking the plugin. After four kinds of testing(java enabled and java plugin installed), it has been proved to be correct.
Johnny, could you review it and I will check it into trunk. Thanks!
Xiaobin, returning immediately if java is not enabled is of course the right thing to do, change the indentation back to being 2 spaces in stead of 4 spaces for consistency with the rest of the files in the diff and you have my r=jst. Thank you. You still need an sr= to check this in, Brendan, wanna have a look at the last patch here?
Johnny: A question about the patch. Why did you choose to add a function to PluginArray rather than something like this: #include "nsIPluginHost.h"; static NS_DEFINE_CID(kRDFXMLDataSourceCID, NS_RDFXMLDATASOURCE_CID); nsCOMPtr<nsIPluginHost> pluginHost (do_GetService(kPluginManagerCID, &rv)); if (NS_SUCCEEDED(rv)) if (pluginHost->IsPluginEnabledForType("application/x-java-vm") == NS_OK) *aReturn = PR_TRUE else *aReturn = PR_FALSE; Was it to avoid the mulithreaded assertion? Thanks in advance for your quick reply!
Huh, multithreaded assertion? When do you see that? To answer your question, I chose to use the plugin array to get at the plugin host because it was available to me where I needed it and it already had the logic for creating the plugin host, and it isolates that plugin host logic into the plugin array. Given that getting at the plugin host is only a matter of getting a service I'm ok with doing that in nsGlobalWindow.cpp, either way is ok with me, do you want to change this?
It is OK for me to leave it there. I was asked because the guy who reported bug 68933 is just curious about this. I will let him see your reason. Brendan: Would you give us a sr about the patch? Thanks very much!
Johnny, we have found that using the nsPluginHost in other parts of the code causes multithreaded assertions. If you didn't see it, that's great.
AFAIK the plugin host is not intended to be used from other threads than the main thread (cc:ing av@netscape.com for verification of this), if you do see these assertions I think someone is not playing by these rules, please file bugs on those assertions. The plugin host should either be made thread safe, or people should not use it from other threads.
Any status on this?
I am asking for "sr=" and "a=" on this bug.
- can mPlugins be an nsCOMPtr? - what about mPluginHost as well, and then using do_GetService in PluginArrayImpl::GetPluginHost? Other than that, it looks good.
Shaver: Thanks for your suggestions! The reason that mPlugins is not defined as nsCOMPtr is because it is a pointer not point to an interface but a implementation class(PluginArrayImpl* mPlugins/nsGlobalWindows.h #317). Also notice that nsIPluginHost is a structure, not a real interface and this is why mPluginHost can not be defined as nsCOMPtr.
Patch for bug 68933 covers the patch for this bug! *** This bug has been marked as a duplicate of 68933 ***
Status: REOPENED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → DUPLICATE
Verified dup.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: