247140 - Java applets permanently hog keyboard focus

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Stewart Gordon]

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.

Comment 1

[Bill McGonigle (not currently reading bugmail; please contact directly)]

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...

Comment 2

[Stewart Gordon]

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.

Comment 3

[u88484]

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. 

Comment 4

[Stewart Gordon]

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....

Comment 5

[Jeff Grollo]

Attachment: test case exhibiting input problem

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.

Comment 6

[chris hofmann]

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

Comment 7

[Stewart Gordon]

(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.

Comment 8

[Asaf Romano (gone)]

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

Comment 9

[HARUNAGA Hirotoshi]

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

Comment 10

[Greg Tiller]

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.

Comment 11

[Asa Dotzler [:asa]]

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

Comment 12

[HARUNAGA Hirotoshi]

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

Comment 13

[Steven Michaud [:smichaud] (Retired)]

This problem doesn't happen when you use the Java Embedding Plugin.

http://javaplugin.sourceforge.net/

Comment 14

[Jaime Mitchell (use [e-mail] for email)]

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

Comment 15

[John Abraham]

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

Comment 16

[Hiro]

(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

Comment 17

[Stewart Gordon]

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.