Closed Bug 105129 Opened 23 years ago Closed 11 years ago

onfocus event doesn't work correctly after alert()

Categories

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

x86
All
defect

Tracking

()

RESOLVED WORKSFORME
mozilla1.2alpha

People

(Reporter: shawn, Unassigned)

References

()

Details

Attachments

(2 files)

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....
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Target Milestone: --- → mozilla1.0
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. 
OS: Windows 2000 → 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.
Target Milestone: mozilla1.0 → mozilla1.2
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
Priority: -- → P4
Attached file Additional Testcase
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.
Assignee: joki → events
QA Contact: vladimire → ian
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? 
Assignee: events → nobody
QA Contact: ian → events
"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
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.