105129 - onfocus event doesn't work correctly after alert()

Status: RESOLVED WORKSFORME

(Core :: DOM: Events, defect, P4)

Description

[Shawn]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.5) Gecko/20011011
BuildID:    2001101117

If you run an alert onfocus for a form control (input, select, etc) and you then
set focus back to the previous control, focus is not set to the previous control.

Reproducible: Always
Steps to Reproduce:
1. Go to http://www.usroute1.net/formtest.htm

2. Tab out of the first box.

3. The onfocus event for the second box will fire.  This causes an alert()
dialog box to pop up and then focus should be set back to the first box.

Actual Results:  Focus is returned to the first box for one or two blinks of the
cursor, then focus is put on the second box.

Expected Results:  Focus should be placed on the first box and stay there.  This
works fine in IE and NS 4.x

I have tried this both by putting the actual commands in the onfocus for the
<INPUT> control and also by making a function in JavaScript and having the
onfocus call that function.  Both ways produce the same result.

Comment 1

[Vladimir Ermakov]

Confirming

On linux and Netscape 4.x the behaviour is different however:
1)You tab to the second box
2)Cursor dissappears
3)Alert pops up and cursor appears in second box
4)You close alert, and another alert pops up
5)You close this alert and cursor goes to the first box....

Comment 2

[Shawn]

The NS 4.x problem was fixed.  It was my bad.  I forgot about the bug in
Netscape 4.x where I have to stick the document.forms[0].elements[0].focus();
before I do the alert.  Trying the testcase in NS 4.x will now produce the
exptected results.  The problem still occurs in Mozilla however.

Comment 3

[/\/\arcio Galli]

Attachment: Testcase based in the original reported.

This testcase is based in the original URL. I removed the alert box and the
onload event in the body. 

1) put the focus in the first input field and type 'aaaaa'. 
2) tab to the second field.

At this point the onfocus of the 2nd input field was suppose (via onfocus and
JS) to keep the caret & focus in the first input element.

3) type 'bbbbb'. The characters appears in the second input text field.

4) alternate the browser window and back to the this window context (with alt
tab for example). Then note that the focus and caret is now placed in the 1st
input field (expected behavior).

tests did with win98.

Comment 4

[/\/\arcio Galli]

Confirming my previous results with Mozilla 20020204 win98, setting platform to
all. 

Comment 5

[Bob Clary [:bc] (inactive)]

The behavior I see in the test case is:

Start with focus in url bar.
press tab -> html element gets focus 
press tab -> first input gets focus
press tab -> first input keeps focus
press tab -> url bar gets focus

This seems to be related to the issue in bug 53579. Are they dupes?

Comment 6

[Bob Clary [:bc] (inactive)]

Following Marcio's testcase and scenario and using
http://bclary.com/experiments/EventTests/ with all DOM events AT TARGET I get:

1) click on first input

   as the mouse moves, mouseover fires on the html element
   *** no mouseover/out form element? ***
   mouseover is fired on the input1
   mousemove is fired on the input1
   mouseout is fired on input1 (*** this is the problem? ***)
   focus is fired on input1
 
2) press '1' key

   keydown is fired on input1
   input is fired on input1
   keypress is fired on input1
   keyup is fired on input1 
   (order of events: shouldn't this be keydown, keyup, keypress?)

3) tab to the second field.
   keydown is fired on input1
   keypress is fired on input1
   change if fired on input1
   blur is fired on input1
   blur is fired on input2
   focus is fired on input1
   focus is fired on input2
   keyup is fired on input2

4) press '1' key

   keydown on input2
   input on input2
   keypress on input2
   keyup on input2

5) press ALT TAB

   keydown on input2
   keyup on input2
   blur on input1
   
6) press ALT TAB

   focus on input1
   keyup on input1

Comment 7

[scottputterman]

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to [e-mail].  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.

Comment 8

[Daniel Wang]

A test suite has been created to track bug 58441, bug 134293,
bug 105129, bug 131843, bug 50221, bug 134321, bug 122311,
and bug 112294:

http://bugzilla.mozilla.org/attachment.cgi?id=100778&action=view

People who have reported problems in the bugs mentioned
please perform all the test in this suite. All bugs will be resolved
as duplicate of the appropriate bug unless someone can reproduce
a problem with onblur/onfocus style change (no alert involved)

Comment 9

[Vladimir Ermakov]

In the testcase attached if you just tab to second field the focus doesnt change
to field 1. If you click it changes to field one briefly and then back to field
2. Build 2002-12-16-08-trunk

Comment 10

[Thomas Swan]

Attachment: Additional Testcase

Comment 11

[Thomas Swan]

Regarding attachment 122113 [details], changing any box to x will result in an infinite UI
loop and cause Mozilla to lock and never close without specifically killing the
task in Windoes 2000 and Windows XP.

Comment 12

[Thomas Swan]

Appearing in Win32 builds of Mozilla 1.3, 1.3.1RC, 1.4a, and nightly builds
including the Win32 build 2003042908.

Comment 13

[Adam Guthrie]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051014
Firefox/1.6a1 ID:2005101411

This appears to have been fixed. The focus always stays in the first input in
Marcio's testcase while doing all the things he describes. WFM?

Comment 14

[j.j.]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070107 Minefield/3.0a2pre

"Testcase based in the original reported"  wfm.
"Additional testcase" fails, but is it related to that bug? 

Comment 15

[Shriram (irc: Mavericks)]

"Testcase based in the original reported"
- can't reach second box via tabbing or clicking

"Additional testcase" 
- Passes

x86, Win Vista, FF 17.0.1