User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a2) Gecko/20040614 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a2) Gecko/20040614 This was previously brought up in comment to bug 120921, which was subsequently duped to bug 78414. But it's really a separate issue that's been around for ages. I'm not sure if it's a regression of bug 78846, or if that was exclusively a fix for Mac OS pre-X. Once an applet has acquired the keyboard focus, it will not let go of it. While it's possible to switch the focus between multiple applets, it is impossible to do anything with the keyboard in the browser window outside of them, even on other tabs. URL bar, text fields, keyboard shortcuts all thus stop working. Reproducible: Always Steps to Reproduce: 1. Open a page containing a Java applet that accepts keyboard input. (e.g. any of various crossword applets) 2. Click in the applet to set the focus on it. 3. Click in the URL bar. 4. Try to type. 5. Click in an HTML text field. 6. Try to type. 7. Activate another tab and repeat. Actual Results: Keystrokes continue to go to the applet. If another tab has been activated, the applet tends to draw on the other tab (probably just a case of bug 162134). The only way to regain focus in the window itself is to close the applet down by leaving the page it is on or closing its tab. Expected Results: Removed the focus from the applet when I clicked something else, enabling me to type back in the Mozilla window.

setting: component: Plug-Ins -> Event Handling since that's where keyboard focus is supposed to start, though Java: OJI might be appropriate as well. Here's a testcase that is somewhat reduced in complexity: http://www.simonstl.com/dynhtml/update/code/chap6/lc2.html?words=foo To reproduce click on the label over the input field - you can not type in the location bar after that. This is different than bug 78414 as here keyboard accelerators do work, in fact you can cmd-r to fix the problem until you click on the label again. I also found bug 122482 which sounds like it might be related but there's not enough description to know for sure. If it were http://lxr.mozilla.org/seamonkey/source/content/events/src/nsEventStateManager.cpp#694 would need a Mac ifdef. I'm not setup to build at the moment to try that...

That applet is a partial testcase - it shows that the browser is denied the keystrokes, but since it doesn't process keyboard input itself, doesn't show that the keystrokes are in fact going to the applet rather than into a black hole. Unless the applet just doesn't work on my setup (indeed, the JS on that page doesn't); otherwise, _any_ Java applet could be such a partial testcase. And Cmd+R has no effect for me (now using 2004070508). But pressing Reload or choosing Reload from the menu does.

Confirming with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040925 Firefox/0.10 Would the reporter of this bug or someone with the right permissions change Hardware and OS to ALL, since bug is only listed as Mac and MacOS X and I expirence this on XP SP2. Need to also change the version since I am using branch and this is filed as trunk, but dont know which should be changed to since there is no ALL. Also, please change the summary to be easier for people to find with querying to something like 'Java applets permanently hogs keyboard focus causes jumbled text when trying to type' I'm going to nominate for blocking 1.0 since when I tried the test case and first tried to make this post, I was fighting with the screwy typing, very annoying bug, and eventually firefox crashed.

It appears that the symptoms you're describing are different from mine - I don't get jumbled text, only keystrokes refusing to go anywhere but to the applet. And I see you're using Firefox, so that might make a difference. But I will see if I can reproduce the problem on my Win98 box at home....

I mentioned this in bug 120921, comment #11, but this behavior appears to be a regression. I've used the attached test case on a OS 10.3.5 machine running Netscape 7.02 and Netscape 7.1 (Gecko builds 20030208 and 20030624). Briefly, the test displays an index page with two frames. The top frame contains a standard html textarea. The bottom frame contains a Java applet with a text field. By typing into the top frame, then bottom frame, then top frame, results vary according to the browser used and whether an AWT or Swing text field is being used. Running 7.02, everything works fine with an AWT control. If a Swing control is used instead, the browser crashes. Under 7.1, neither the AWT or Swing control gives keyboard focus up.

jst, can you have a quick look and see if anything can be done to protrect from the crash?

(In reply to comment #3) > Confirming with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; > rv:1.7.3) Gecko/20040925 Firefox/0.10 > > Would the reporter of this bug or someone with the right > permissions change Hardware and OS to ALL, since bug is only listed > as Mac and MacOS X and I expirence this on XP SP2. I have tested it on Win98 using both a build from a few months ago and a new one, and was unable to reproduce the problem. > Need to also > change the version since I am using branch and this is filed as > trunk, but dont know which should be changed to since there is no > ALL. I'm not sure how this is supposed to be handled. But for as long as a bug is on the trunk, it will be inherited by any branches that are created off it. My guess is that it should remain set to Trunk, since that's where the bug originated and where fixing it will have most impact. > Also, please change the summary to be easier for people to > find with querying to something like 'Java applets permanently hogs > keyboard focus causes jumbled text when trying to type' The jumbled text problem seems to be Firefox-specific. As such, I suppose it warrants a separate bug report.

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

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

I can reproduce this bug 100% of the time. If you have an applet with a JTextField and click on it then you can no longer focus on any other FF component such as typing in the location bar or search bar. The focus is perm stuck on the applet. Sometimes this causes a crash also. If you need a simple example showing this goto: http://www.letsdomath.com/greg/lmo/BullsEye/BullsEye.html Click on one of the fields and then try to type in the search bar. this is without a doubt a 1.0mac blocker imo.

moving blocking-aviary1.0mac+ bugs to Firefox1.1 and Mozilla 1.8a6 Target Milestones.

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

This problem doesn't happen when you use the Java Embedding Plugin. http://javaplugin.sourceforge.net/

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

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

(In reply to comment #13) > This problem doesn't happen when you use the Java Embedding Plugin. > > http://javaplugin.sourceforge.net/ Now, this plug-in is built in by default. WFM. Mac OS X 10.3.9 Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051108 Firefox/1.6a1

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051108 SeaMonkey/1.5a The problem has indeed gone away as I try it now. And it seems (at least superficially) that Java support is more reliable now.