I have an application which basically consists in a applet that runs on the browser.
I've been validating this application for Mac OS X and I came across with a focus issue that does not happen in Windows or Linux.
The problem occur, for example, everytime I use a JFileChooser to select a directory to save a file. After I select a directory and press 'ok' in the JFileChooser, if I'm running the application in Windows of Linux, the focus go back to the applet from where I opened the JFileChooser.
But on Mac OS X when I finish using the JFileChooser and I close it (or press ok) the focus does not go back to the applet. In that case I need to click somewhere inside the Applet to get the focus back there. This happens not only when I use JFileChooser but also every time I use a 'heavyweight' component.
I wonder if this is a know issue and we need to deal with it using for example requestFocus()? Any of you had problems with this before?
"Because the focus behavior of this method is platform-dependent, developers are strongly encouraged to use requestFocusInWindow when possible."
See answer here: java applet not grabbing focus in JRE 1.6.0_29 and up (OS X)
(I googled: "osx browser applet focus issues")
Related
I have a java application that can be run as a JFrame or as an applet.
Launching the applet in the browser adds a new tab in the browser and also makes the Java Console appear. After I close both of them, I expect to be able to repeat this operation and see the Java Console reappear. It does not reappear, however I can reload my applet in the browser.
Everytime I have to kill this zombie java interpreter process launched by firefox.
/usr/lib/jvm/java-6-sun-1.6.0.26/jre/bin/java -D__jvm_launched=22906841394 -Xbootclasspath/a:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/deploy.jar:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/javaws.jar:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/plugin.jar -Djava.class.path=/usr/lib/jvm/java-6-sun-1.6.0.26/jre/classes -Dsun.awt.warmup=true sun.plugin2.main.client.PluginMain write_pipe_name=/tmp/.com.sun.deploy.net.socket.1444.1704699298565364673.AF_UNIX
After killing the process, the Java Console will reappear. Also tried the repro steps with chromium, it's the same result except the zombie process' commandline is different.
Things to note:
When I close the browser tab containing the applet, the applet is in a normal state, waiting for the user to perform actions on the UI.
Closing the browser completely between applet relaunches will also fix the problem since the java process is a child of the browser process.
Anyone has an explanation or workaround? Thanks!
Anyone has an explanation or workaround?
For the work-around, test in the applet viewer. (The console is not relevant to production, unless the design is very flawed.)
As to the explanation, a browser will end the JRE/console when/if it feels like it. It is not up to the developer or applet to override that. I've noticed that FF will typically leave the JRE running for 30-60 seconds after leaving an applet page (judging by when the console vanishes).
It's not a zombie, by which I imagine you mean to imply something is going wrong; this is just how the Java plug-in has always worked. The first time it's needed, it starts up, and this may involve opening the console, depending on your settings. It will then continue to run until the browser shuts down. In other words, this is not a bug, but a feature.
Some browsers include a menu item for opening the Java console; you could use that to reopen it as needed, without killing or restarting anything.
I created a java program that will pop up a dialog, and scheduled it as a task. Everything works fine except when the scheduled java program runs and the dialog pops up, there is another window (svchost.exe) hanging behind the dialog box and doesn't go anywhere until the java program finishes its execution. The program is running in Windows XP.
How can I avoid that dos prompt?
Thanks
One word of warning (posting as an answer so I can get fancy links and for length): Services which pop up UI are basically security holes waiting to be exploited (search for "shatter attack" for more information). That's why in Windows Vista and beyond services cannot display UI on the desktop (services run in session 0, the interactive user runs in session 1).
More importantly, there are several scenarios in Windows XP where your application will fail to work: If there are multiple users on the computer logged on at once (fast user switching) or if the machine is a server 2003 machine running with the terminal server role your UI won't pop up in the interactive user's session.
This article talks about the session 0 isolation issue and how to work around it.
If you want your Java program to have no console window, you need to launch Java using javaw, not java.
Create a shortcut for the thing you want to schedule. In the shortcut's properties dialog, Select Run Minimized in the shortcut tab. When scheduling this shortcut, make sure you refer to the shortcut, it ends in .lnk Browsing for it may bypass the shortcut for what the shortcut points to. Source: http://ask.metafilter.com/18994/Windows-Batch-File-Run-Minimized
This is a registered bug (Bug ID: 6515708) but does anyone have a workaround for it?
Scenario
javascript calls OpenDialog() method in applet
applet starts new thread which opens the AWT FileDialog
on completion, the file name is read and the javascript method OnDialogComplete is called
At this point the dialog is disposed and (on some browsers only) the browser hangs.
We have a mixture of XP with IE6/7 and Vista with IE7 but unfortunately the bug appears randomly on any of them.
Ideas anyone?
The bug report suggests it only happens when two FileDialogs are open at once. Perhaps you could detect when the Java implementation is affected (pre-1.6.2), and in that case use an inter-applet-communication method such as a static variable on a class, to implement a mutex preventing OpenDialog() from working when there is already a FileDialog in progress?
I have a JApplet which I contains various Swing components. It also starts a couple of extra threads in the init() and generally does other pretty standard applet-y things.
If I close the browser window containing the Applet, the JRE doesn't die (the icon remains in the system tray) until all the browser's windows have been closed (ie the browser has completely ended and disappears from the task manager)
Is this the expected behaviour or should the JRE end when the browser window enclosing the Applet closes?
I have a destroy() method, but (at present) it only stops the extra threads I started in the init() method. Should I be doing more in here maybe? Are there any other best-practises I should be following?
If you'd like any more info, please let me know in the comments.
:-)
I believe the JRE is loaded as a plugin to the browser, and the icon is supposed to remain in the system tray until the browser ends.
The reasoning behind this is that if you load one applet, leaving the JRE running will accelerate future applets' loading times.
I wrote an application in Java and when it runs on one customer's computer running OS X The Save and Export buttons are disabled. (Everything else works in the application.)
Both of these buttons open up a standard save file dialog.
Any ideas?
The fact that these buttons open a file dialog probably has nothing to do with it being disabled. Buttons can end up being disabled for a number of reasons,
its setEnabled can be called with false,
when using an action, its setEnabled can be called with false, and
when using an action, it can have a property "enabled" that potentially disables it; see Action for more information, there's a list of properties there.
Could you post how you 'implemented the JButtons'?
A stab in the dark, but most macs are still running Java 1.5; check if your current code misbehaves with Java 1.5 on your end. Maybe that's where you problem lies.
This was caused by misinformation recieved from the customer.
Turns out the customer was trying to save to a location where files can't be saved on his/her hard drive.