836490 - browser does not retrieve keyboard focus from Java applet in textbox

Status: RESOLVED DUPLICATE of bug 868005

(Plugins Graveyard :: Java (Oracle), defect)

Description

[Bob Hanson]

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20130116073211

Steps to reproduce:

1) opened http://chemapp.stolaf.edu/jmol/simple.htm and accepting security risk
2) I entered text in the textbox under the applet.
3) I then clicked and/or dragged in the Java applet (which has a KeyEventListener and will appropriately consume keyboard events when the applet has focus).
4) I then clicked in HTML textbox and tried to type.
5) With focus in textbox, I pressed CTRL-K and then typed characters.
6) Left page and returned
7) Typed text into the textbox.




Actual results:

(1) applet loaded.
(2) text appeared in the textbox.
(3) model responded appropriately when dragged.
(4) Nothing appeared to happen. No text was observed. It appeared as though the textbox was disabled. (It wasn't.)
(5) Characters appeared in bottom left-hand corner of the applet. This would have been appropriate if the applet had had keyboard focus. 
(6) Nothing strange.
(7) Normal response from browser -- text appeared in textbox. (keyboard focus has returned to the browser)




Expected results:

browser should have regained key event focus when user clicked in textbox, and typed text should have appeared in the textbox. 

This behavior is 100% reproducible on my computer and was first noticed on a completely different computer by a different user. 

I am the applet developer. I have never seen this behavior before, possibly because I have recently started using Windows 8. I do not know how long it has been a problem, because I only occasionally use this textbox. 

It is somewhat similar to other reported bugs, but I cannot find it exactly.

Comment 1

[Paul Silaghi, QA [:pauly]]

Can you please check whether this happens in the current
development version of Firefox as well? http://nightly.mozilla.org

(In reply to Bob Hanson from comment #0)
> I have never seen this behavior before, possibly
> because I have recently started using Windows 8.
It is reproducible on Firefox 17? Or in FF 18 on Win 7 ?

Comment 2

[Tiziana Sellitto [:tiziana]]

Bob, can you still reproduce this using a current version and with the suggestion of comment 1?

I'll close this in two weeks. Please feel free to add any useful information that can help to understand if you already have the problem.

Comment 3

[Bob Hanson]

Apologies -- The link should read http://chemapps.stolaf.edu/jmol/simple2.htm

Still a problem; completely reproducible exactly as described. No text typing in step 4. Typing into the text box after manipulating the model does not return keyboard focus to the browser; keyboard focus is still in the applet.

Please do not close until this is addressed..

Comment 4

[Tiziana Sellitto [:tiziana]]

I would have close this only in case of lack of information.
Bob, could you verify if the problem exists in Windows 7,too? 
and verify the regression window with this http://mozilla.github.io/mozregression/ ?

Comment 5

[Bob Hanson]

Sorry, I have no way to revert to Windows 7 or use mozregression. Someone else will have to do that. I'm just reporting the bug. Reproduced in FF22, so it is at least a bug for FF18-FF22/Windows8. Can't someone from your end test Windows 7? I might be able to test Windows 7 later this week after returning from traveling, but I have no access to such a machine here. Could you please confirm the bug in Windows 8? 

Hardware is a Toshiba laptop with touchscreen.

Comment 6

[Paul Silaghi, QA [:pauly]]

I confirm the STR in comment 0 on nightly 25.0a1 (2013-07-14) Win 7 x64.

Comment 7

[Paul Silaghi, QA [:pauly]]

This is reproducible on FF 4.0.1, so it's not a regression.
Win only, not repro on Mac or Linux.

Comment 8

[Paul Silaghi, QA [:pauly]]

Actually this is a regression in Java branches.
Latest j6u43 is good.
First j7 is bad.
So, maybe a dupe of bug 868005 ?

Comment 9

[Georg Fritzsche [:gfritzsche]]

Behaviour per Spy++ appears to be the same as bug 868005.