Java 6u19 broke my applet! (java.awt.AWTPermission accessClipboard) - Java Applet Development

I was happily developing my applet with Java SE 6 Update 17 when I decided to upgrade to Update 20. Suddenly the drag-and-drop support in my JTree stopped working! After further testing, I discovered that drag-and-drop works fine in Updates 17 and 18 but fails in Updates 19 and 20. They cause an exception on every drop: "java.security.AccessControlException: access denied (java.awt.AWTPermission accessClipboard)". There must be some kind of regression that appeared in Update 19, but in the meantime I need a workaround.
I've posted a [simplified project|http://vocaro.com/trevor/files/TreeDemo.zip] that reproduces the problem. The exception occurs on line 98 of importData in ItemTree.java, when getTransferData is called. But I fail to see how this is accessing the clipboard! Is it a bug? Any suggestions would be appreciated. Thanks. 

trevor#vocaro.com wrote:
..I discovered that drag-and-drop works fine in Updates 17 and 18 but fails in Updates 19 and 20. ..There were some major changes to the plug-in as a result of the changes introduced to address [Mixing Signed and Unsigned Code (Ensuring Application and Applet Security)|http://java.sun.com/javase/6/docs/technotes/guides/jweb/mixed_code.html].
Search the forum and bug database for further details. 

AndrewThompson64 wrote:
There were some major changes to the plug-in as a result of the changes introduced to address [Mixing Signed and Unsigned Code (Ensuring Application and Applet Security)|http://java.sun.com/javase/6/docs/technotes/guides/jweb/mixed_code.html].Thanks, but I don't see how that document is relevant to my problem. I'm not mixing signed code with unsigned code, and I never see any warning dialog. It's just a simple unsigned applet with a drag-enabled JTree in it. Why would that be a security issue? It still seems like a Java bug to me.
Search the forum and bug database for further details.Before posting this email, I searched Google but found nothing. I also searched bugs.sun.com for "accessClipboard" and found nothing. Is there another search term I should be using? 

trevor#vocaro.com wrote:
AndrewThompson64 wrote:
There were some major changes to the plug-in as a result of the changes introduced to address [Mixing Signed and Unsigned Code (Ensuring Application and Applet Security)|http://java.sun.com/javase/6/docs/technotes/guides/jweb/mixed_code.html].Thanks, but I don't see how that document is relevant to my problem. I'm not mixing signed code with unsigned code, and I never see any warning dialog. It's just a simple unsigned applet with a drag-enabled JTree in it. Why would that be a security issue? It still seems like a Java bug to me.I did not mean to imply either it was or it was not. There have been a lot of cases reported around the forum that had the smell of bugs - side effects on other functionalities besides mixing signed and unsigned code. That is why I suggested you should..
Search the forum....for details of those discussions. Unfortunately none of the threads seemed to go too far - the OP would disappear or other things.
..and bug database for further details.Before posting this email, I searched Google but found nothing. I also searched bugs.sun.com for "accessClipboard" and found nothing. Is there another search term I should be using?I tried the bug DB for "clipboard applet 1.6" and had no better luck, which brings us to the next step.
Prepare a test case and raise a bug report. See what Sun has to say about the matter. 

AndrewThompson64 wrote:
Prepare a test case and raise a bug report. See what Sun has to say about the matter.Well I'll be darned. I filed a bug report on this, and a few weeks later Sun...er, I mean Oracle...released Java 6 Update 21, and the bug is now gone!

Related

Applt unresponsive in Mac OS X

This one is driving me nuts.
For some obscure (to me at least) reason, my swing applet is totally
unresponsive in OS X, although it works just fine in Windows. Here's
the story:
~ Original version developed over a year ago, using JBuilder. Original design was not very complicated - little user
interaction, mainly feedback text, progress bars and a cancel button.
Since the IDE lacks a GUI-creation feature, opted for GridBagLayout
mode, manually coding it. Worked perfectly well in both platforms.
~ About three weeks ago the client updated specs for the applet, and it
involved a great deal of additional GUI stuff. Refused to code that
manually, so I decided to use NetBeans (currently 6.5.1) for the new
version. Creating the new GUI was a breeze, really, and I had it up and
running in a couple of days. Everything looked nice and dandy up to
here.
~ Next day, when I tried the applet on a Mac, I hit the
no-java-1.6-for-OSX wall. Looked it up on the net and found this blog by
Jim Blackler
that explains why. Followed the directions, which involve setting
NetBeans to work with JDK 1.5, and yes, the applet showed, but the GUI
was completely distorted and it was unresponsive.
~ Great idea: download NetBeans for Mac and work from there. Long story short, the resulting applet worked perfectly well in Windows but was still unresponsive in Mac.
~ In an attempt to return to "known grounds", I changed the layout
model back to GridBag, which led to a less-than-perfect result but
still functional (in Win, that is). Tried again on the Mac and,
although the GUI looked the intended way, it was still unresponsive.
~ Suspecting a bad java install on my Mac, I tried it on another one, with
the same result. I even downloaded the newer Update 3, but there was no
change.
~ After a bit of exchange at the Apple forums, I reinstalled NetBeans for Mac and debugged the applet
with it. BTW, I went back to the GridLayout model and fixed it for Mac, and that's the version
I debugged w/NetBeans. Funny enough, the applet ran like a charm from
the IDE! In a heart-pounding minute I built/signed the jar and tried it
in Safari, just to find that the darn thing was again unresponsive. Of course, it shines in Windows.
Just to make things clear, by "unresponsive" I mean that the GUI
elements do not respond to user interaction. I know for sure the applet
is running - since the original version I included an optional Trace
window, which let me make sure that everything runs well all the way to
the start() method.
I would gladly show any code here, but the thing is I don't think
there's anything wrong with it - it runs well in Windows and the Mac NetBeans IDE. Actually I
woudn't really know what to show. I guess it must be related to some configuration issue which I'm missing.
Thanks in advance to anyone with a good idea! 
And no stack traces are ever dumped? I hate to say this but it sure sounds like a bug in the Mac JRE to me. If you were using classes that could not be found, or you have a class version incompatibility of some sort you should have gotten a stack dump somewhere about that. I wouldn't really trust NetBeans myself but even so if it's crashing at runtime it should be telling you so.
Have you tried running with appletviewer on the Mac? That would be the first thing I would do. 
Thanks cotton.m
No stack dumps whatsoever - it actually looks like it's waiting for user input (as it should be) but does nothing when clicked on. Nada.
As for the appletviewer suggestion, that's exactly what NetBeans does when you "run" and applet from the IDE, so the answer is yes, it does work (but that's the only way it will!) 
JGraterol wrote:
Thanks cotton.m
No stack dumps whatsoever - it actually looks like it's waiting for user input (as it should be) but does nothing when clicked on. Nada.
As for the appletviewer suggestion, that's exactly what NetBeans does when you "run" and applet from the IDE, so the answer is yes, it does work (but that's the only way it will!)Have you tried actually running appletviewer directly though? From Terminal? Because that should be the exact same JRE with no chance of NetBeans interference as what's running in Safari.
If the answer to that question is yes and that it works there then....
1) Well the stupid but obvious must be asked. Did you restart Safari?
2) Have you tried any other browsers on Mac? Like Firefox for example.
If running from the Terminal works then I suspect it's Safari that's the problem. It would be interesting to know what Firefox does. I have few 1.5 applets myself, largely Swing with some custom painting and they worked fine on Mac on at least Firefox. I think I tried only one on Safari and that worked too. Point being, I know it does work (mostly) but the lack of any stack trace dump is a bit perturbing. 
Been trying to run appletviewer from terminal, but being the java-newbie I am, I ran into trouble. I'm getting "java.security.AccessControlException: access denied (java.util.PropertyPermission user.home read)" as soon as the applet gets to the part where it initializes a jFileChooser to the current folder. Of course, I'm using the signed version of my applet. Help?
As for the Safari/other browsers question, I must have reset each one of them (including emptying their collective cache) a million times by now. Safari, Firefox, Opera, you name it. If Google had already finished their Mac version of Chrome I would've tested that one too. 
JGraterol wrote:
As for the Safari/other browsers question, I must have reset each one of them (including emptying their collective cache) a million times by now. Safari, Firefox, Opera, you name it. If Google had already finished their Mac version of Chrome I would've tested that one too.And nada on all of them?
I saw you mentioned the signed part earlier but I didn't really think much of it. But I'm beginning to wonder. I just tried a number of Swing based applets on a Mac with various browsers without issue. What I did not do is test any applets that require requesting permission to do things.
Can you build a version of your applet where you don't need any file permissions and just see if that works by itself? Did the original working version of the applet work with files as well? 
cotton.m wrote:
And nada on all of them?Same boring behavior.
cotton.m wrote:
Can you build a version of your applet where you don't need any file permissions and just see if that works by itself? I'll give it a shot.
cotton.m wrote:
Did the original working version of the applet work with files as well?Yes it did. Actually, working with local files was the original reason to create the applet. The host web app needs to transfer very large files (>2GB) to an IIS server, and the applet uses apache.FTP to achieve that. 
JGraterol wrote:
cotton.m wrote:
>Did the original working version of the applet work with files as well?Yes it did. Actually, working with local files was the original reason to create the applet. The host web app needs to transfer very large files (>2GB) to an IIS server, and the applet uses apache.FTP to achieve that.
I don't see a way of being able to help without seeing this thing in action. :/
I don't normally do this but if you have a link and don't want to post it here you can send it to me at max AT maxstocker.com and I'll take a look at this. I'm curious to see what's going on, my guess is something security-ish but I really don't know wtf is going on here. 
Before getting into that (which would probably be against company rules, not sure) I followed your idea, just the other way. I created a simple applet (still with NetBeans) with only a button that fires a jFileChooser and displays the file name. Built/signed it and, guess what, it works perfectly well. Wtf?
I will try yet again to look for stuff that shouldn't be there in my applet, but right now am extremely tired (almost 2am). Tomorrow.
Thanks again for all your help! 
JGraterol wrote:
Before getting into that (which would probably be against company rules, not sure) I understand but at the same time there is a limit to what anyone can do without being able to see exactly what is failing.
I followed your idea, just the other way. I created a simple applet (still with NetBeans) with only a button that fires a jFileChooser and displays the file name. Built/signed it and, guess what, it works perfectly well. Wtf?Well than add things till it fails. But I really don't understand why you aren't getting a stack trace here...
I realize this is an ancient source but there is an example of running a signed applet here [http://java.sun.com/developer/onlineTraining/Programming/JDCBook/signed.html#appli] I really think you want to run this in appletviewer and see what's going on, this just has to be some sort of traceable error.
>
Thanks again for all your help!Good luck. 
I haven't read the entire thread (I know, I'm lazy), but there is one other place that stack traces can be dumped, and it's the console located in Applications/Utilities/Console.app
Try that for any stack traces. 
Good morning to both, and thanks macrules2 for your post.
macrules2 wrote:
I haven't read the entire thread (I know, I'm lazy), but there is one other place that stack traces can be dumped, and it's the console located in Applications/Utilities/Console.appChecked all of the logs and no, there's nothing in them. I even re-tested the applet from Safari and checked again (there should've been new entries) and nothing. Weird, I know.
cotton.m wrote:
I realize this is an ancient source but there is an example of running a signed applet here http://java.sun.com/developer/onlineTraining/Programming/JDCBook/signed.html#appli I really think you want to run this in appletviewer and see what's going on, this just has to be some sort of traceable error. After playing a bit with the settings (thanks for the link, btw) I was finally able to make it run in appletviewer from terminal... only to find out that yes, it works well, meaning no error/stack dump. Back to square one.
I think I'll follow your idea of adding things to the dumb applet I made yesterday until it fails too... Rather lengthy and boring process, but I see no other way out at this point.
I'll post whatever I find out. In the meantime, thank you so very much for your help.

OS X 10.8 Java 7 applet exception on dragStart

Does anyone recognize a problem like this? It seems to be quite some way outside our own code, but you never know. Someone might have a workaround, or be able to suggest just who to report this to if it is indeed a bug :-)
Hi there,
I tested the drag and drop in the application I'm validation - also a Swing application that runs as an applet inside a browser - and I got the same exception. I'm using JRE 1.7.0_08 and mac osx 10.7.4.
I struggled with this before and I could never make the drag and drop to work on mac osx. As a workaround - with java 6 - you could detach the frame out of the browser (on mac you can use cmd+shift for that) and once you do that, you could use the drag and drop without problems. So, the drag and drop did not work only when the applet runs inside the browser.
On Java 7 you get this exception when you try to use the drag and drop and the workaround we had in Java 6 is also not working, which fire and exception if you press cmd+shift. So basically, with Java 7 is even worse...
With this validation I'm doing I already report 2 bugs in Sun's BugParade. They were both accepted as bugs but with priorities changed to low and I think that one is pretty nasty (7196264) which only happens in Java 7.
Nice to at least finally find some more people who have not only encountered the very same bugs but also reported them. Now, if only it would be fixed or at least some workaround (horrific hack or not) could be found :-) …
For reference, I have now reported this as a bug too: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7197576
Any news on this problem?
And what happens to the bug you reported? I cannot find it...
Sadly, no news.
And good question, I can't find it either …

Issues with users who accidently drag a menu item

Hi, I am a desktop support person and don't know much about how Java works, but I have a problem I think is Java related. Hoping someone will clue me in on what terms to use when troubleshooting this problem. Which is:
My company has a homegrown application that uses Java. When some of our users (and only some of them) click on a menu item and accidently hold it down and drag, a little shortcut type icon shows next to their pointer as they are moving and when they release, the entire program just errors out in the form of the URL turns in to "about.blank". They have to shut down IE and start over.
Can someone tell me what I can do to stop this behavior? We thought it was application related until we discover that it doesn't happen to everyone. So is there a setting in I/E or Java that needs to change?
Any clues at least as to what terms I can use to further research would be greatly appreciated. 
So whatever this application is, whether it was written in Java or not, specifically allows drag-n-drop for its menus. Sounds like it shouldn't have, so this "feature" is more like a "bug". What do you think the forum can do about it though? Talk and complain to the people who wrote that app. 
What do you think the forum can do about it though?I think he was probably looking for some advice like what
you mentioned. He probably has a very frustrating job and
if he talked to the designers then he probably heard a line
of bull and some excuses. He probably expected us to tell
him that if IE was involved and there were windows with toolbars
that it could possibly be an applet written in java. He
probably needed to know that if this were the case (java applet
or something else) that there wouldn't be any external fix
that could be done and that in fact (as you mentioned) the
bug would have to be fixed in the software and re-deployed.
He also probably wanted some sympathy and it most likely is
a one time futile attempt for a shot in the dark solution.
I think he needed to know what you told him.
walker
p.s. I've been wrong lots of times, especially when i make conjecture. 
As I said in my original request, this does NOT occur on every users PC. That would indicate the problem is not in the programming.
I am simply under the impressing (maybe incorrectly), that dragging and dropping a menu item has something to do with Java. And the other commenter is right. I am sort of shooting in the dark. Just thought Java savvy folks might have seen this before and know right off the bat. I am continuing to research.
By the way the version of Java is 1.4.02 (the current corporate standard). Yet on my PC that has Java 1.5 the issue does not occur and it is the same application. But there are also users who have 1.4.02 and the problem does not occur.
Thank-you all for your input. I continue to be baffled but will post what I find out for the curious. 
I may be totally wrong, but just wondering: are you sure you're talking
menus here instead of toolbars? A toolbar is normally located just
below the menubar. Toolbars can be dragged, dropped, dumped and
docked about anywhere causing a lot of frustration if the docking isn't
handled properly ...
kind regards,
Jos 
As I said in my original request, this does NOT occur
on every users PC. That would indicate the problem is
not in the programming.Actually that isn't necessarily true.
But there are also users who have 1.4.02
and the problem does not occur. Which by similar logic would indicate that the problem is
not necessarily Java.
Thank-you all for your input. I continue to be
baffled but will post what I find out for the curious.could you confirm for us that it is in fact a web based java applet
and that the toolbar or menu is part of the applet and that all
of the IE settings on all of the computers are the same and
that the plugin cache has been cleared and the plugin settings
are the same and could you find out if the java console shows
an error or stack trace? 
To answer some of your questions and to update:
It is not toolbars, it is menu's in the application.
I now know it is NOT Java. I found out the application calls another application that does use Java later on down the line but this page with these menu items are not using java. So thanks to everyone. I'm off to look elsewhere. This is not a Java issue.
Guess I'll look into IE settings, certain settings I know are all the same because they are set through Group Policy but not every setting is set that way and possibly some are different. By typing in "about:blank" on Google, I see alot of returns and looks like many reasons to get that but I'll have to find something about dragging and item in a web page, getting that little shortcut icon, when is that normal and when is it not.
Thanks again for being kind enough to respond, Java is off the hook.

Copy & Paste Function in Java JDK 6 Update 24

I have a problem, that in my Version Java JDK 6 Update 24 the Copy & Paste-Function do not work. I have already read that they had disabled this function in Update 24 and in Update 23 it is still working.
But when comes Java 6 Update 25?
And is in Update 25 this function enabled or not?
Or on which way can i put Update 24 working with the Copy & Paste- Function?
Regards 
843467 wrote:
But when comes Java 6 Update 25?Dude, why don't you try typing "java update 25" into Google and see what you get. Go on, give it a try just for kicks. It would have been far less effort than making this post.
Or perhaps you were under the illusion that people from Oracle visit here to answer your questions? 
What specifically do you mean that you can't copy or paste? 
sorry that I havn't been precise enough.
We have a Java client application using Swing running on windows xp or windows 7 and since update 24 our users can no longer use copy and paste to transfer data from other applications (for instance e-mail clients or excel) into Swing components of our Java application or the other way round from Swing components (for instance JTextField or JTable) into the other applications.
In the release notes I read about security vulnerabilities having been fixed with update 24. So I don't really know if this behaviour is a feature or a bug?
If it's not a bug, how can we disable this feature?
Thx in advance
Edited by: 843467 on Mar 15, 2011 8:10 PM 
So if you have a JTextArea called textArea, and you do textArea.copy() and textArea.paste(), it does not work?!
Did you check into java.awt.datatransfer.Clipboard? I never have, but you might want to.
~Bill 
Thanks for your answer. I will check with the Clipboard object.
But the problem does only occur when I try to transfer data out of the java app into another app. In the past users could simply mark some contents in the java app, press ctrl-c which caused the contents to be transfered to the system clipboard and then paste the data somewhere else, or the other way round. This worked fine without doing any additional coding.
Now since update 24 it seems that swing does no longer allow data to be transfered from the java app through the system clipboard. If this is a new feature, how can we configure to allow this again?
Thx for your help 
843467 wrote:
Thanks for your answer. I will check with the Clipboard object.
But the problem does only occur when I try to transfer data out of the java app into another app. In the past users could simply mark some contents in the java app, press ctrl-c which caused the contents to be transfered to the system clipboard and then paste the data somewhere else, or the other way round. This worked fine without doing any additional coding.
Now since update 24 it seems that swing does no longer allow data to be transfered from the java app through the system clipboard. If this is a new feature, how can we configure to allow this again?
Thx for your helpI should have been more clear. My apology. Here's what I really should have said ... "If I understand you correctly, that's really weird and will generally be unacceptable, IMO. But for clarification, can you try to use the copy and paste methods and see if that helps, as they are supposed to work directly on the System clipboard." Then of course I directed your attention to the Clipboard class for information's sake.
Also, has anyone else noticed this and is it peculiar to any particular OP-SYS? 
abillconsl wrote:
..has anyone else noticed this and is it peculiar to any particular OP-SYS?Here is a place you can test it. I am running 1.6.0_24 (Sun/Win 7) and copy/paste by keyboard shortcuts fails for me. 
Moderator action: Moved from Java Programming.
db 
I tested again (on WinXP SP3 platform) and discovered that copy/paste by keyboard shortcut is working when I run the app inside my Eclipse IDE.
If I start the app with Java Web Start then copy/paste fails again. So I assume that it has something to do with the app being downloaded.
Hope this helps. 
843467 wrote:
I tested again (on WinXP SP3 platform) and discovered that copy/paste by keyboard shortcut is working when I run the app inside my Eclipse IDE.
If I start the app with Java Web Start then copy/paste fails again. So I assume that it has something to do with the app being downloaded.Did you try the keyboard alternatives to Ctrl-X, Ctrl-C, and Ctrl-V? Namely:
Cut: Shift-Delete
Copy: Ctrl-Insert
Paste: Shift-Insert 
Andrew Thompson wrote:
abillconsl wrote:
..has anyone else noticed this and is it peculiar to any particular OP-SYS?Here is a place you can test it. I am running 1.6.0_24 (Sun/Win 7) and copy/paste by keyboard shortcuts fails for me.Well that sounds really stinkalog. I certainly hope they fix it!
PS: Nice site - thanks.
Edited by: abillconsl on Mar 16, 2011 4:28 PM 
abillconsl wrote:
Andrew Thompson wrote:
abillconsl wrote:
..has anyone else noticed this and is it peculiar to any particular OP-SYS?Here is a place you can test it. I am running 1.6.0_24 (Sun/Win 7) and copy/paste by keyboard shortcuts fails for me.Well that sounds really stinkalog. I certainly hope they fix it!*
PS: Nice site - thanks.Thanks. I like to help out where I can. :-)
BTW #splungebob Tried the alternate key-combinations you suggested with no success. Both styles of keyboard shortcut work (for copy at least) in a JTable in an app. that runs from naked Jar file (no security manager).
* That suggests it was a deliberate change to the security policy for sand-boxed apps., and will not be changed back.
OTOH - since JWS existed for free floating apps. (1.2+), and since 1.6.0_10+ for embedded applets, the JNLP API services can be used to do copy/paste operations even in a sand-boxed app. Specifically the ClipboardService. Here is my little demo. of the ClipboardService.
Ultimately it seems a good move to update sand-boxed apps. to leverage the JNLP API services for any case where the keyboard accelerators fail. I'll need to update the properties applet, and several other apps. (when I get a round tuit). 
Just to throw in something: here's a link to a blog explaining the vulnerability that was fixed (not that I fully understand it, but you certainly do :-)
http://slightlyrandombrokenthoughts.blogspot.com/2011/03/oracle-java-applet-clipboard-injection.html
Cheers
Jeanette 
wtf - since when do links not work? Plus an edit doesn't show the complete post ...
so trying again, without any tags - soft should be good enough to auto-detect, anyway, this is good ol' jive, right ;)
http://slightlyrandombrokenthoughts.blogspot.com/2011/03/oracle-java-applet-clipboard-injection.html
Jeanette

Transparent Applet

I must first confess that I know nothing of Java programming and as such am looking more for some directional pointers than an actul fix to our prioblem. the Java experts we have at our disposal have not been able to find a cause or resolution to the following.....
We have an applet in widespread use that behaves strangley in a very indiscriminent manner ?
Symptoms....*
When re-maximising or alt-tabbing back into the applet from another Windows based application the applet returns in a transparent form, the frame of the window complete but the contents only partially or in some cases not at all visable, It is not plain white but rather displays a snapshot of the application or desktop behind it. If the applet is then dragged across the screen the background remains the same, taking the snapshot with it ?
The applet itself is still functioning, (it manages calls both ingoing and outgoing to a local IP phone) and if you click within the applet and chance upon a button it will respond and indeed that button will then become visible. Mostly the only way to return the applet to it's normal state is to close it down and re-launch however we have had some success in openning the java console and 'wiping' it over the top of the applet ?
Trouble Shooting*
Initially the problem was put down to a local PC resource issue but we have found it occurs on all types of machine, both old and new, with additional memory installed etc. During an episode local CPU, IO and memory allocation has been observed and there is nothing to suggest that there is a performance problem. Indeed any other applications in use continue to respond normally as indeed does the applet itself, it's just see-through ?
All the PC's in use are running Windows XP and using Internet Explorer but every other variable that we can think of has been tested for. Many different versions of JRE have been tried from 1.6.0_03 through 1.6.0_21 but this has made no difference, IE 6,7 & 8 have been tested, again having no effect. An Auto refresh, (every 10 seconds) has been added to the applet but the applet remains transparent.
The applet is used across a wide variety of users in different countries who run different applications along side it, so no one common denominator in the local setup or usage exists ?
We've anabled full logging but at the time of an occurance, nothing stands out.
The issue is very intermittant and we can find no way of making it happen.
If anyone has any theories or simply an idea as to where the problem may lie, (e.g. within the code or configuration of the applet or the PC's JRE settings) this would be much appreciated as we are stumped.
Edited by: 807570 on Nov 4, 2010 4:44 AM
Edited by: 807570 on Nov 4, 2010 4:48 AM 
It is common for "crashed" windows (in windows) to perform this "snapshot" behaviour - Ive seen it all my life, its just a generic crash symptom. Yesterday I had a problem where my JFrame only drew a white background and when you clicked buttons (or even moved your mouse over some of them) they would "re-apear". Alot of the functions of the frame continued as normal. I think the cause was a null pointer error, though its not repeatable enough for me to test. 
Thanks, can there be any Java based reason for this happening specifically to the applet whilst not effecting any other application ?
Edited by: 807570 on Nov 4, 2010 3:31 PM 
I found that for an applet I wrote, Internet Explorer displayed it very badly (panes disappearing or not being refreshed correctly) whereas Firefox displayed it correctly. And this was with the same version of Java in both browsers. 
DrClap wrote:
I found that for an applet I wrote, Internet Explorer displayed it very badly (panes disappearing or not being refreshed correctly) whereas Firefox displayed it correctly. And this was with the same version of Java in both browsers.+1
People can probably hear my teeth grinding when an applet related question mentions loading it in 'the browser'. The browser environment owns the applet. (1)
In my experience with applets over the years, I have heard of cases where:
<li> The browser failed to act on showDocument(). (Note that this is not even a bug of any sort, due to Sun documenting the method as being not compulsory.)
<li> The browser failed to call stop() or destroy().
<li> And my personal favorite, just for its sillyness - FF had a micro-version that when the user 'scrolled up' the page, the entire applet would be reloaded!
1) Don't get me wrong. This is the way it should be. An applet is a guest in a web page that the browser is displaying - it should be the browser that is in control. (And presumably the end-user controls the browser, but that is getting beyond the scope of this thread.) 
OK, so it's the Browsers fault ?
I'm still struggling to see a way out of it. The transparency is happening often enough to have a serious impact on productivity.
We could try a different browser but it would be a major change to rollout for a 1500+ users and I guess I'm confused as to why other java apps we use don't have this issue ?
could it be because the applet runs in it's own small window as appose to in an already open browser session ?
Any idea's on how we could troubleshoot further would be greatly appreciated. 
807570 wrote:
OK, so it's the Browsers fault ?Possibly.
I'm still struggling to see a way out of it. ..Try offering a Java Web Start (http://www.java.com/en/download/faq/java_webstart.xml) based launch for the applet. That is if the applet does not need to interact with JavaScript. JS is not available in an applet launched using JWS.
We could try a different browser but it would be a major change to rollout for a 1500+ users and I guess I'm confused as to why other java apps we use don't have this issue ?Applications, or applets, or both?
could it be because the applet runs in it's own small window as appose to in an already open browser session ?Huh? I do not understand what you mean. What is the inherent difference between a 'small window' and an 'open browser session'? Can't a browser window be both? 
Thanks again Andrew, Sorry for the delay in coming back, I hope you're still around.
Again, I should pre-empt this by stating my lack of Java knowledge and experience but I think that thanks to your previous comments, I may be seeing a possible way 'round this issue......
Try offering a Java Web Start (http://www.java.com/en/download/faq/java_webstart.xml) based launch for the applet. That is if the applet does not need to interact with JavaScript. JS is not available in an applet launched using JWS.correct my thinking if I'm way off here but if we use Webstart would that involve converting the applet to an application ? ( Currently, there are no entries for this applet in the cache viewer)
If so, I would have to engage the 3rd party who provide / develop the applet for us so would this be straight forward for them to do ?
How exactly would I describe my requirements to them ?
in answer to your other question.....
Applications, or applets, or both?both 
Klefticuf wrote:
..correct my thinking if I'm way off here but if we use Webstart would that involve converting the applet to an application ? No. Webstart can launch free floating applets (outside the browser). Though it is used most often for applications.
I think most of your other questions are redundant, after that..
All it would require to launch using webstart is a JNLP launch file for the applet that uses some parameters that the original applet used, plus a few more, in an XML (JNLP) format understood by a webstart client. 
Again, many thanks, this is just the sort of info I'm after.
I shall just test the applet using Firefox to confirm that the removal of IE from the equation does, as I suspect it will, eradicate the issue.
That being the case, I shall look into asking if our provider could set up the JNLP/Web Start method as a test.
I shall return to mark this thread as answered if this line of investigation proves fruitful. 
Alas, the Firefox test was unsuccessful. Initial reports were promising, but not long into the day, a transparency occurred.
The problem has now transcended 3 versions of IE, multiple version of Java, endless types of hardware & OS config. and now a completely different browser ? The only common denominator being the applet itself ?
I appreciate that it would still perhaps be a valid test to try using JNLP but there'll be difficulties in getting that agreed to and set up..... so.......
..... I was wondering, as a hypothetical.....
If we were to experience the transparency issue on JNLP as well or if we were to be told that JNLP was not an option, ( due to previously mentioned Javascript restrictions for example ) are there any suggestions of where else we could look for a cause ?
Would the considered opinion be that JNLP will almost definately solve the problem ? 
I was thinking about what I posted earlier (about IE mis-displaying an applet but Firefox displaying it correctly). And I believe that was wrong. What actually happened was that IE mis-displayed the applet (so the part about IE was true). But I didn't test Firefox because I had used the old-fashioned <OBJECT> element which was specific to IE (so the part about Firefox was false). Instead I decided to convert the project to JNLP at that point and everything was fine from then on. Sorry for the misinformation.
It shouldn't take you too long to set up the JNLP configuration for your applet. The hardest part for me was getting our IIS server configured with the MIME type for JNLP... when I asked the administrator to do that I got the response "We're not installing Java on our IIS server". Education was required.

Categories

Resources