I'm using IE 8.0.7600.16385 for testing (the default browser is FF) an applet.
The applet is part of a project to deliver music off CD & DVD (it is an MP3 player).
It was working around a month ago (or so), but when the page is loaded from
local disk now, it does not pop the Java Console (which is configured to open
automatically for applets and JWS apps.), & does not load the applet. Instead it
puts a little icon in the upper left of the space the applet should be
that looks like below (the red arrow points to the icon).
Clicking the icon and everywhere else around the applet space produced no further information.
After trawling through the IE options, particularly under the Security, Content & Advanced tabs
and setting all the options I thought might help (to no avail), I opened the Java Control Panel
to see..
So it seems that something in Java itself is stopping IE from loading applets.
How do I reconfigure Java to enable the IE listing under 'Default Java for browsers'?
Update 1
IE will happily load the applet shown at Property Probe (a sand-boxed applet on my site). While another tab of the browser will fail to (attempt to load and) render the applet off the local file system. I am tending towards putting this down to something that changed in IE, though I cannot see how it could have changed between the old and recent tests. The JCP is still showing the IE entry grayed out, which suggests that is its way of indicating that IE is not the default browser (?).
I also noticed that a similar version of IE on the Netbook fails to load the applet off disk with the same symptoms. :(
Update 2
The problem applet is load into a frame (yeah sure, 'ick frames!' get over it) using deployJava.js - a script supplied by Oracle to do version checking before running an applet.
A plain applet in unframed HTML will load just fine off the local file system. I'll do further tests to narrow it down to the 'frames' or the script. But I am betting it will be the script that triggers this behavior.
deployJava.js is the deciding factor. An applet in:
framed HTML
loaded off the local file system
..works in IE8 - unless it is
embedded using the script.
Since I have other ways to do what was needed from the script (plug-in version checking), I'll remove the script and use the alternate method.
And to answer the question as to why the behavior in IE 8 changed. Last time it was tested in IE, the applet element was hard coded in the HTML, no script or version checking used. :P
Related
I need to get title of current active window(for example right now: Google Chrome). I search smth in internet, and found only this javax.swing.FocusManager.getCurrentManager().getActiveWindow(); . But i don't know how to get PROGRAM TITLE with that code.
If you are fine with a non-java solution that will work for Windows computers, there is a programming language called AutoHotkey (AHK) that is more suited for this kind of task. There exists a popular script called "Window Spy" (also known as "ActiveWindowInfo") that has the ability to view the title of the active window, as well as other information such as PID, the name of the .exe that the Window is an instance of, and etc. (I have attached a screenshot of what Window Spy told about the Google Chrome window I was using to write this reply. In the screenshot, I have also indicated which part of it tells you the Title of the Window).
This script comes with most AutoHotkey IDEs (such as SciTe4Autohotkey if you are interested). However, you can perfectly well run the script without an IDE.
Here are some quickstart instructions:
First, you will need to install AHK itself (here is the official website)
You can download the script itself by navigating to https://raw.githubusercontent.com/fincs/SciTE4AutoHotkey/master/source/tools/ActiveWindowInfo.ahk in Chrome, using the shortcut Control+S to save the script to your computer. Make sure that when you download the script, it ends with a .ahk instead of the .txt that it will default to.
Navigate to the file that you downloaded and run it with AutoHotkey (It should be the default thing that happens if you double click the .ahk file with AutoHotkey installed).
If you need any more info on how to use the script, please let me know.
I'm trying to run this simple HelloWorld code written in Java from my browser (Chrome):
public class HelloWorld extends JApplet {
public void init() {
try {
SwingUtilities.invokeAndWait(new Runnable() {
public void run() {
JLabel lbl = new JLabel("Hello World");
add(lbl);
}
});
}
catch (Exception e) {
System.err.println("createGUI didn't complete successfully");
}
}
I compiled it with NetBeans, and then I created a WebApplication project. The HTML code that runs the applet is:
<html>
<head>
<title></title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><applet code="HelloWorld" archive="applet_HelloWorld.jar" width="590" height="530"></applet></p>
</body>
</html>
If run the applet from NetBeans it works. But when I run the HTML code by double clicking it, the following message pops up from the browser:
Your security settings have blocked a local application from running.
I tried with Internet Explorer and Firefox but nothing.
This message started to appear after the last update of Java. Where is the problem?
After reading Java 7 Update 21 Security Improvements in Detail mention..
With the introduced changes it is most likely that no end-user is able to run your application when they are either self-signed or unsigned.
..I was wondering how this would go for loose class files - the 'simplest' applets of all.
Local file system
Your security settings have blocked a local application from running
That is the dialog seen for an applet consisting of loose class files being loaded off the local file system when the JRE is set to the default 'High' security setting.
Note that a slight quirk of the JRE only produced that on point 3 of.
Load the applet page to see a broken applet symbol that leads to an empty console.
Open the Java settings and set the level to Medium.
Close browser & Java settings.
Load the applet page to see the applet.
Open the Java settings and set the level to High.
Close browser & Java settings.
Load the applet page to see a broken applet symbol & the above dialog.
Internet
If you load the simple applet (loose class file) seen at this resizable applet demo off the internet - which boasts an applet element of:
<applet
code="PlafChanger.class"
codebase="."
alt="Pluggable Look'n'Feel Changer appears here if Java is enabled"
width='100%'
height='250'>
<p>Pluggable Look'n'Feel Changer appears here in a Java capable browser.</p>
</applet>
It also seems to load successfully. Implying that:-
Applets loaded from the local file system are now subject to a stricter security sandbox than those loaded from the internet or a local server.
Security settings descriptions
As of Java 7 update 51.
Very High: Most secure setting - Only Java applications identified by a non-expired certificate from a trusted authority will be allowed to run.
High (minimum recommended): Java applications identified by a certificate from a trusted authority will be allowed to run.
Medium - All Java applications will be allowed to run after presenting a security prompt.
I faced the same issue today, and I was able to fix the issue by changing the security settings on the Java Control Panel from HIGH to MEDIUM.
Well, setting the Java Security Setting to MEDIUM permanently is not really recommended as this will allow potentialy malicious software to run on your system and not be blocked. So I suggest after running your applet you may want to change back the setting to HIGH.
Location of the Java Control Panel
Change the setting of the Control Panel
If you are using Linux, these settings are available using /usr/bin/jcontrol (or your path setting to get the current Java tools). You can also edit the files in ~/.java/deployment/deployment.properties to set "deployment.security.level=MEDIUM".
Surprisingly, this information is not readily available from the Oracle web site. I miss java.sun.com...
Go to Control Panel
Double click on Java
Open the Security tab
Select Medium
Click on Apply
Restart your web browser
That's it!
If you have no Medium security level, then you should add your application to the Exception Site List (Java Control Panel → Security tab).
Open your applet in a browser and copy the contents of your address bar.
Go to Control Panel → Java Control Panel → Security tab and press the Edit Site List... button.
Press the Add button, insert your path and press Enter.
Press Continue on the security warning that appears.
Open the applet again and don't forget to press Run on the pop-up window.
If you are like me whose Java Control Panel does not show Security slider under Security Tab to change security level from High to Medium then follow these instructions: Java known bug: security slider not visible.
Symptoms:
After installation, the checkbox to enable/disable Java and the security level slider do not appear in the Java Control Panel Security tab. This can occur with 7u10 and above.
Cause
This is due to a conflict that Java 7u10 and above have with standalone installations of JavaFX.
Example: If Java 7u5 and JavaFX 2.1.1 are installed and if Java is updated to 7u11, the Java Control Panel does not show the checkbox or security slider.
Resolution
It is recommended to uninstall all versions of Java and JavaFX before installing Java 7u10 and above.
Please follow the steps below for resolving this issue.
1. Remove all versions of Java and JavaFX through the Windows Uninstall Control Panel. Instructions on uninstalling Java.
2. Run the Microsoft uninstall utility to repair corrupted registry keys that prevents programs from being completely uninstalled or blocking new installations and updates.
3. Download and install the Windows offline installer package.
My problem case was to run portecle.jnlp file locally using Java8.
What worked for me was
Start Programs --> Java --> Configure Java...
Go to Security --> Edit Site List...
Add http://portecle.sourceforce.net
Start javaws portecle.jnlp in CMD prompt
On step 3, you might try also to add file:///c:/path/portecle.jnlp, but this addition didn't help with my case.
I am using an older Data Structure and Algs book that comes with Java Applets for practice. So I needed to store and run some applets locally. I am currently running Windows 10 OS with Edge, Chrome, and IE 11.
Running applets seem to only be allowed in IE11, and as other have mentioned you have to add the applet to the exception list. My issue was since I am storing these locally, and opening them in IE, it opened with path starting with "C:\..." Adding the full path using, "file///..." like mentioned in one of the other answers didn't work for me.
The fix:
So, I just added(without the quotes), "file:///" to the exception site list and finally got it working. This also allows me to run any applet stored locally, and I do not have to explicitly add an exception for each applet path.
I plan to remove the exception from the list once I am done using the programs, and only add it back as necessary.
Java applets do create a security risk, hence are disabled in most modern browsers. You have to lower the security to run it. There is a guide by Oracle for that.
Starting with Java 8, there is no "medium" risk setting in the Security tab under Java
You will keep getting this error till you revert to older Java (suggested Java 7, it has hit the end of life though).
Install both 32-bit and 64-bit version because browsers are still 32-bit, even on a 64-bit machine, 64-bit OS
In general, browsers (I see this esp. with Safari) are kind enough to inhibit a Java applet from running if it senses that a security related update for Java exists. It seems to do this quietly... my applet just "sits-and-spins" in the browser window - never executes. Is there a way, preferably via JavaScript, to programmatically determine whether or not this condition will exist (so that, for example, applet loading can be skipped and some kind of informational message can be displayed)?
In my particular case, my applet quietly did nothing when launched with Java 1.6.0_37 (on Mac OSX 10.6, Safari 5.1.7). As soon as I updated to Java 1.6.0_43, the applet ran without incident.
The best approach is generally to poll for the existence of the applet using Javascript, and take alternate action after a specific time.
Note that the Deployment Toolkit Script is intended to ensure a valid Java version and run the applet while providing feed-back to the user, so it would be a better overall approach to deploying the applet.
So I have created an applet that creates a file on the local hard drive, and eventually uploads it to a CGI that I have created.
When run on IE, the applet works fine, and creates and uploads the file properly.
However, on firefox, I get an error on the Java Console, access denied, showing me that it simply can't create the file. I created the certificate myself, and did not buy one or have it verified through a company.
I need a solution that will work for anybody who potentially uses the applet, meaning the fix can't just be editing my own settings, unless I can do that with every computer that accepts the certificate.
Unsigned applets cannot access local disk on all browsers. It worked for you in IE because I believe that you ran it from file system (not via http). So, the right solution is not to create file on disk. Create content in memory and upload it. But remember: you can connect only to server the applet was downloaded from.
If you really have to create local file you have to sign the applet.
May be, some setting has to be done. One of the reason could be your Mozilla Firefox is not java enabled.
Check the following links :
A fix for Java applets not loading in Firefox
Applet loads but hidden in Firefox
To test whether java is enabled or not in a web browser, click [here]
This bug may be relevant.
It states that Firefox kills java applets that take too long to load. I have an example that works fine when loaded from a local resource but fails when it is remote. Sometimes, reopening the applet can make it work as it appears that it loads more and more of the classes each time.
I am deploying a signed & trusted applet. We need to run the applet in a separate JVM & increase the heap size. Setting separate_jvm & java_arguments works on our local boxes. Curiously we have clients that though they are using 1.6.0_15 don't seem to be running the new plugin architecture.
When I check their Java config, "use next-generation plugin" is checked & IE7's option "use Java 1.6.0_15 for applet plugin" is also checked. Nothing seems obviously wrong. The Java console also reports the correct version, but neither separate_jvm nor java_arguments are respected.
Just as a sanity check we wrapped the applet in a JNLP & set up our web page to serve the applet with a jnlp_href. The applet tag had a bogus code parameter to ensure the JVM was actually running the JNLP. The Java console complains that it cannot find the bogus class when it should be properly loading the JNLP.
Are there security settings or something else that might cause what I'm seeing?
I'm afraid I've just a few suggestions rather than an absolute answer.
The Java virtual machine version
and plug in version can be
different. Go to Control Panel,
Java, Runtime Environment settings.
When you check the console it may
show the two different versions.
The new plugin architecture would
depend on browser, Opera doesn't use
it at all, for example. IE7 does
though. So check which browser it
works on.
Java has got corrupted due to
repeated installs and uninstalls.
Pretty common complaint I've found.
If you have control over one of the
machines you should uninstall every
Java. Restart machine. Install
latest Java.