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.

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

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.

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.

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

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?

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

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 adt@netscape.com. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.

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)

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

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.

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

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?

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?

"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