101784 - Keyboard and mouse freezes when the Javascript onFocus event is called for form controls (onfocus + alert)

Status: RESOLVED WORKSFORME

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

Description

[Madhur Bhatia]

Build ID: 2001-09-26--3-0.9.4 ----- MacOS 9.1

When the JS onFocus event is called upon for the <input type=password> form 
control, the keyboard goes dead and even the mouse stops working on the controls 
- even the browser search input box does not get any focus.

steps to reproduce:-

1. open the attached testcase
2. click on the form control

actual: 
the onFocus event is called twice - you will see the alert box displayed twice.
Then the keyboard goes dead. Try to click with the mouse on the Browser Search 
input box, it does not receive any focus.
If you click on the browser back button, the previous page is displayed - but 
still the keyboard is keydead. And the mouse click stops working for the form 
controls.

This is specific to Mac machine. So far tested on MacOS 9.1 The JSevent is 
working fine on windows.

Comment 1

[Madhur Bhatia]

Attachment: testcase

Comment 2

[Madhur Bhatia]

On Linux 7.1 , the onfocus event is going in a loop. Can't tell whether  the 
kayboard goes dead on linux - since the onfocus event is gone in a loop.

Comment 3

[Madhur Bhatia]

Another observation on Linux :--

1. click on the form control -- onfocus event is triggered. If u click on 'OK' 
the onfocus event goes in a loop

2. Now, if you click on the browser search input box, and then hit keyboard 
enter - another alert box is displayed saying 'the information you have entered 
...' --- hit keyboard enter again. You will see the onfocus alert box on the 
screen. Using your mouse, click OK. 
tadddaaa..... the alert box goes away -- the event has gone out of the loop. And 
the keyboard is not keydead.

Comment 4

[Madhur Bhatia]

On macOS 9.1 and macOS 10:-

The onFocus event is triggered twice and then the keyboard goes dead for all of 
the following form controls:-

1. input type=button
2. input type=reset
3. input type=checkbox
4. input type=radio
5. input type=select
6. textarea
7. input type=text
8. input type=password

I have seperate testcases for each of the controls calling upon the onFocus JS 
event.

Comment 5

[Madhur Bhatia]

Attachment: test case for <input type=button>

Comment 6

[Madhur Bhatia]

Attachment: textcase for <input type=checkbox>

Comment 7

[Madhur Bhatia]

Attachment: textcase for <input type=radio>

Comment 8

[Madhur Bhatia]

Attachment: textcase for <input type=reset>

Comment 9

[Madhur Bhatia]

Attachment: textcase for <select>

Comment 10

[Madhur Bhatia]

Attachment: textcase for <input type=text

Comment 11

[Madhur Bhatia]

Attachment: textcase for <textarea>

Comment 12

[Madhur Bhatia]

nominating for nsbranch

Comment 13

[Madhur Bhatia]

Please also note the observation I made on linux 7.1 :-

My previous comments 
========================================
1. click on the form control -- onfocus event is triggered. If u click on 'OK' 
the onfocus event goes in a loop
2. Now, if you click on the browser search input box, and then hit keyboard 
enter - another alert box is displayed saying 'the information you have entered 
...' --- hit keyboard enter again. You will see the onfocus alert box on the 
screen. Using your mouse, click OK. 
tadddaaa..... the alert box goes away -- the event has gone out of the loop. And 
the keyboard is not keydead.
===============================================

I tried to narrow down the problem by 
1. including the controls within a table cell
2. calling a javascript function when the onFocus JS event is called upon
-- and I still get the same behaviour as mentioned above.

build ID: 2001-09-27-04-0.9.4 (branch) 

Comment 14

[Jaime Rodriguez, Jr.]

what are the chances of this making the 0.9.4 branch?

Comment 15

[Jaime Rodriguez, Jr.]

what's the target for this one?

Comment 16

[Jaime Rodriguez, Jr.]

Is this a stop ship? This looks pretty serious.

Comment 17

[saari (gone)]

It is a serious bug, but I wouldn't say stop ship. You won't be seeing this in 
the wild because there is no way to interact with the control, even in IE. 

Comment 18

[Jaime Rodriguez, Jr.]

Thanks for the update and quick turn around ... Much appreciated

Comment 19

[Jaime Rodriguez, Jr.]

Saari says, 6.1 shipped with this issue = PDT-.

If anything turns up in QA's (Gearardo), anaylsis, then let's look at this one
again.

Comment 20

[Madhur Bhatia]

========== on linux 7.1 ===========
for all the form controls mentioned, if I call an alert box when the onfocus 
event is triggered, I get the following result :-

1. mouse click on the control - the onfocus event triggered goes into a loop
2. tab to the control - onfocus event triggered - hit enter or mouse ckick 'ok' 
-  the keyboard goes dead - event does not go in a loop.

If I do not call an alert box when the the onfocus event is triggered, instead, 
I say assign a value to another form control, i get the following result :-
 
1. everything works fine and as desired
2. I do not get any event loop or a keyboard freeze.

========== on macOS 10; mac OS 9.1 ===========
for all the form controls mentioned, if I call an alert box when the onfocus 
event is triggered, I get the following result :-

1. If I click on the control, the onfocus event is triggered twice and then the 
keyboard goes dead.
2. If I tab to the form control, the onfocus event is triggered, I hit keyboard 
enter - the event was triggered only once  - but I got a keyboard freeze.

If I do not call an alert box when the the onfocus event is triggered, instead, 
I, say, assign a value to another form control, i get the following result :-
 
1. everything works fine and as desired
2. neither the event is not triggered twice nor I get a keyboard freeze.

============== on win2000 ====================
the onfocus event works fine and as desired, whether -
1. I call an alert box 
or
2. assign a value to the same or any other form control.
This platform does not show any problem.


=========== points to consider ==============
1. why do the event handlers behave differently when a new window environment is 
opened (such as - alert box , prompt box, etc.) - cause a keyboard freeze.
2. the difference in behaviour for the event handler can only be seen on Linux 
7.1, macOS 10 and macOS 9.1

Comment 21

[Jonadab the Unsightly One (Nathan Eady)]

Too late for 0.9.6, this needs retargeting.

Comment 22

[joki (gone)]

0.9.6 has passed, moving to 0.9.7.  Load balancing 0.9.7 list shortly

Comment 23

[Madhur Bhatia]

still able to reproduce on 
2001-11-26-17-6.2.1 linux 7.1 -- same behaviour on this platform as described in 
my previous comments.

2001-11-26-17-6.2.1 macOS 10 -- same behaviour on this platform as described in 
my previous comments.

Please provide the target milestone for this. Thanks!

Comment 24

[lchiang]

(correcting for joki.  madhur's last change overwrote joki's.)

Comment 25

[joki (gone)]

Moving bugs from 0.9.7 for triaging in 0.9.8

Comment 26

[Jaime Rodriguez, Jr.]

Mass change of nsbranch bugs to nsbeta1. nsbranch is no longer a valid keyword.

Comment 27

[Jaime Rodriguez, Jr.]

what are ethe chances of getting this one in for 099?

Comment 28

[Peter Trudelle]

nsbeta1- per ADT triage team

Comment 29

[Carl Johnson]

I seem to be having the same problem on my Debian Linux system (2.4.18 
kernel).  Mozilla 0.9.9 (20020412).  The page I am viewing seems to use the 
java events onMouseOver and onMouseOut.  This is a serious problem.  It makes 
some web pages completely unuseable.  I have to completely restart mozilla to 
get my keyboard back.

Comment 30

[Rakesh Mishra]

nominating for nsbeta1

Comment 31

[James]

This bug makes mindterm's java ssh client unusable.

Comment 32

[Daniel Wang]

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

Comment 33

[Daniel Wang]

prob happens to Linux (per comment), Mac, and Windows (per dupe)
move target milestone to moz 1.2b as moz 1.1a deadline is missed.

This bug is worksforme on moz 2002102208 win 98. Can anyone still
reproduce this bug?

Comment 34

[Samir Gehani]

adt: nsbeta1-

Comment 35

[Pham]

.

Comment 36

[patrick]

What is the status of this bug? I have been suffering similar symptoms since mozilla 1.4 
for linux. The symtoms I suffer are that mozilla no longer acts on keyboard events or 
mouse focus events. The only way I can getout of this mode is to open mozilla mail and 
shift focus to the "subject or sender contains" search field. This appears to be the only 
mouse focus event that works and the only way to get mozilla to operate normally again. 
 
The testcase on this bug causes my mozilla (currently 1.5 released for linux) to display an 
alert box which when closed re-opens hence making mozilla useless (must be killed) 

Comment 37

[patrick]

This bug seems to have disappeared in Mozilla 1.6 (linux).

Comment 38

[Daniel Wang]

can anyone else confirm that this problem is gone?

Comment 39

[Johnny Stenback (:jst)]

Marking WORKSFORME, please reopen if this reappears.