OK, so following the scenario in the attached testcase, all typing in Firefox or Mozilla is backwards. This is with a current Java version. Unfortunately, I can't obtain the source to the applet, so I don't know what it could be doing.

Load the testcase, and click yes on the confirm dialog. Just wait a minute and don't worry about the applet errors. After the page has loaded, right click on the first applet, select About Java. Then click OK. Now typing in the URL bar is backwards

I think you'll have to save the testcase.html file local to see this.

I can't reproduce this with recent trunk build. The first applet is failed to load, is this an expected result?

I does happen on trunk. I think this happens better on my site: http://www.kaply.com/work/backwards I also have a better scenario. Start the browser. Got to the URL. Wait a minute for everything to kind of finish loading. Then click on the first applet. Then click back on the URL bar. At this point, typing in the URL bar is backwards.

Michael, I tested your URL, the first applet is still failed to load, JavaConsole says: java.lang.ClassFormatError: Incompatible magic value 1008813135 in class file LiveConnect at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:162) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) ... (I think this is an expected result, because I don't even find Liveconnect.class in editor.jar) I followed the other steps anyway, the order of typing in URL bar was just normal. BTW, I was on Linux with recent trunk build plus Sun jre 1.5.0.

This happens on www.hifx.com with Windows XP and both trunk and branch build of Aviary and Seamonkey...

I can reproduce this bug, by attempting to type into a textarea (search bar, google bar, URL location) when an applet is loading (with Firefox 1.0). This bug appears to be a duplicate with 234729, 260772, and 265001, so I'll leave it up to the devs to decide which to dupe and which to leave open.

*** Bug 272723 has been marked as a duplicate of this bug. ***

*** Bug 265001 has been marked as a duplicate of this bug. ***

*** Bug 234729 has been marked as a duplicate of this bug. ***

*** Bug 260772 has been marked as a duplicate of this bug. ***

Kyle - based on the duplicates, can you recreate this problem?

Yes, I can. I should be able to look into this soon.

(In reply to comment #14) > Yes, I can. I should be able to look into this soon. Sun Java version 1.5 appears to fix this bug.

As far as I can tell, there is some liveconnect call that makes the nsTypedSelection::Collapse failed (due to the failure of VALIDATE_ACCESS checking).

I tried the testcase but it doesn't happen for me. When I visit www.runescape.com click "play game" button then click "high resolution" button once it reaches the Java applet and it starts to load the game there, instead of saying "yes" and accepting, I say "no" and then click back. I then start to type backwards. In addition, there is also another issue. Once you reach the java applet, and you immediately close the page before you receive the prompt, you will still receive the prompt even though the browser has been closed. Once I click "no" to the prompt. My firefox process stays on, and any additional firefox window I try to open types backwards. I have to open the task manager to end the firefox process in order for things to work right again. I'm using firefox 1.0.3 And using Java 2 Platform standard edition version 1.5.0 build 1.5.0-b64 Running Windows XP Pro SP2 2.4GHz 512MB of RAM

mass reassign my bugs to Pete Zha.

*** Bug 297112 has been marked as a duplicate of this bug. ***

*** Bug 301716 has been marked as a duplicate of this bug. ***

bug 256763 <-- dupe?

*** Bug 236537 has been marked as a duplicate of this bug. ***

*** Bug 193810 has been marked as a duplicate of this bug. ***

*** Bug 308761 has been marked as a duplicate of this bug. ***

*** Bug 310310 has been marked as a duplicate of this bug. ***

*** Bug 319973 has been marked as a duplicate of this bug. ***

Could bug 327013 be the cause of this bug (and maybe bug 256763)?

mass reassign to Alfred

*** Bug 328688 has been marked as a duplicate of this bug. ***

OK, thank you for looking at this. I think the following observation will help crack this important bug. The demo is trivial and all code is available. It is reproducible with now two totally different applets: http://www.stolaf.edu/people/hansonr/jmol/test/ping/Test_pingpong.html http://www.stolaf.edu/people/hansonr/jmol/test/json/property.htm (The second is our critical implementation.) The code for pingpong is available at the Sun Java site, but what is amazing is that the effect is ONLY seen when JavaScript is polling the applet, even with the absolutely trivial polling going on at http://www.stolaf.edu/people/hansonr/jmol/test/ping/Test_pingpong.html namely: function testing(){ document.applets[0].getAppletInfo() setTimeout("testing()",25) } When the page's JavaScript is making repeated calls to the applet's public methods, if a user types text into ANY text entry area on that page or ANY other open page, including especially the URL line, that text will be mangled. Basically, the text entry cursor is not always updating to the point AFTER the typed letter, so the next letter goes in as though the left-arrow key were pressed first. This is a critical functional problem for those of us developing the Jmol applet. We need to poll the applet, but even at only two polls per second, the effect is seen. My guess is that applet Java improperly traps a keypress or keyup event, thus not passing it through to the browser. But before you blame Java, understand that the effect is NOT observed with IE or Opera.

Got it!!! This just showed up on the console window: Exception in thread "AWT-EventQueue-1" java.lang.IllegalArgumentException: Invalid remove at javax.swing.JTextArea.replaceRange(Unknown Source) at com.sun.deploy.util.ConsoleWindow$24.run(Unknown Source) at java.awt.event.InvocationEvent.dispatch(Unknown Source) at java.awt.EventQueue.dispatchEvent(Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source) please take a look at this

Bob, I've tested the latest release jre with firefox. The bug can be reproduced. With jre1.6 development build, I can't reproduce it. It seems to be a jre bug, and I'm working with the Java guys to resolve it.

*** Bug 338842 has been marked as a duplicate of this bug. ***

*** Bug 343922 has been marked as a duplicate of this bug. ***

Could someone pleas clarify typing backwards??e Do they mean lie what is happening here where I type and the cursor jumps to just before th letter, and then when I finish my sentence, whatever was inserted before the cursr appears at the end?oek or do they mean that the text starts coming out like this: .god yzal eht revo spmuj xof nworb kciuq ehT Note that that is "The quick brown fox jumps over the lazy dog" spelled backwards. If this bug is reporting #2, then it is a different bug, if it is reporting #1, then this bug should be marked dupe of bug 256763

As for me, the backwards is random, not exactly reversed.

(In reply to comment #36) > As for me, the backwards is random, not exactly reversed. > That being the case, I think we'll dupe this and bug 256763. The question is, which should be duped to which? Which component does this belong in anyway? And can anyone reproduce it on any OS other than Windows?

I think this should be marked as a dupe of bug 256763 since it has more information about the nature of the beast.

After discussion with Michael and Alfred (reporter and assignee, respectively) we have decided to dupe this to bug 256763. The cause of the problem appears to be that when a character is inserted into the textbox the cursor doesn't move with it - for some people this occurs all the time, resulting in the text being backwards, for others, it occurs only sometimes, resulting in it being jumbled. Although the symptoms are slightly different for different people, we believe it is caused by the same root issue, and hope that duplicating the bugs will give the issue more focus. Additionally, I am adjusting this to PC/Windows rather than All/All, as I'm only able to find references to it on windows (Michael also says he observed it on windows.) Alfred: Please take bug 256763 if you are indeed working on the issue :) *** This bug has been marked as a duplicate of 256763 ***

I'll take ownership of this bug. Don't know how to reassign, so could someone please reassign it to me (danielle.pham@sun.com)

Danielle, this bug has been marked as a duplicate for bug 256763. That should be the reason why the bug can't be assigned to you. Please take that one if you want.