31181 - no input in return of focus after alert

Status: VERIFIED WORKSFORME

(Core :: Layout: Form Controls, defect, P3)

Description

[Jonathan Baron]

From Bugzilla Helper:
User-Agent: Mozilla/4.7 [en] (X11; I; Linux 2.2.12-20 i686)
BuildID:    2000022916

In a JavaScript form, the script checks for input and returns focus
to the input box if no input.  Although the cursor blinks in the
input box, no typing is allowed.

Reproducible: Always
Steps to Reproduce:
1. Go to the url above.
2. Click the button at the bottom of the intro page.
3. Click the button at the bottom of the next page, without
entering anything.  Then try to enter something.


Actual Results:  You can't enter anything.

Expected Results:  You should see what you enter.

This works in all previous version of Netscape.  The relevant code is:

if (!((r1<=100) && (r1>=0)))a
 {alert("Please answer with a number 0-100."); present();return;}

and present() defines "item" and then does:

junk = top.subq.document.open();
top.subq.document.write(item)
top.subq.document.close();
top.subq.document.subform.rin1.focus();

Comment 1

[Peter Trudelle]

After the alert in the middle of step 3, I have two identical forms, one
following the other . I can't enter anything in the first, but can in the
second.  changing component to HTML Form Controls, reassigning. cc joki, brade,
saari

Comment 2

[Gervase Markham [:gerv]]

[e-mail] - are you still seeing this problem on recent 
builds of Mozilla?

Gerv

Comment 3

[ckritzer (gone)]

From an email received from [e-mail]:

I don't know quite how I am supposed to respond to this, and I
don't have time to look around, but perhaps this will help.
Sorry for the annoyance if this is all wrong.

I use JavaScript for doing psychology experiments, and I hope
that the new browser will eventually work for them.  I reported
two bugs earlier, and they are both still there, and there is a
new one.  I can't recall or find what I gave as the original
examples, but the two relevant urls are:
http://www.psych.upenn.edu/~baron/mtest.htm
and
http://www.psych.upenn.edu/~baron/old/all4.htm

The problem in the first url (mtest) is the timing loop.  This is
bad practice I know, but it works in previous versions of
Netscape, such as 4.6, 4.7.  With Milestone 15, it crashes
(freezes).  The critical part is here. 

function wait(x)
{
x+=new Date().getTime()
while (new Date().getTime() < x) {r=r}
return
}

The second url leads to several problems.  The old problem was
that focus did not go properly to the first response element in
the form.  When I first reported this, it went there at the
beginning, I think, but not after an alert if you make a mistake.
The critical line that isn't working is:

top.subq.document.subform.elements[0].focus();

There is also a new problem with that same page.  In all previous
versions of Netscape (including 3), repeated "writes" to the same
frame would overwrite the previous frame (at least after a
"document.close()".  Now the new write gets added on to the end.
I'm sure there is a workaround for this, but I am also sure that
many people have written scripts that depend on the old behavior.
The critical lines are:

top.subq.document.write(item)
top.subq.document.close()

where "subq" is a frame and "item" is the entire contents.

Here is the last message I received. [ckritzer note: previous sentence refers to 
the bugzilla email he received.]  Again, apologies if I
am doing this wrong.  Jon

Comment 4

[Gervase Markham [:gerv]]

Confirming.

Gerv

Comment 5

[rods (gone)]

The URL above doesn't work, could you provide a test case or vaild URL?

Comment 6

[rods (gone)]

reassigning

Comment 7

[rubydoo123]

assigning to kin for review

Comment 8

[Gervase Markham [:gerv]]

URL is working now...

Gerv

Comment 9

[kinmoz]

Accepting bug.

Comment 10

[ekrock's old account (dead)]

Nominating nsbeta2. JavaScript validation of form data entry is the #1 most 
common use of JavaScript on the web (document.write ()) being the only 
close contender), and resetting focus after an error alert is a widely used 
technique in form validation. This is pretty core DOM0-based UE. We need to get 
the HTML Forms user experience right, and this is an important part.

Comment 11

[leger]

PDT needs a retest on this please.

Comment 12

[Prashant Desale]

I just tested this one with latest builds [2000-0524-08] on Linux.
Problme seems to be there, but its little wiered.

You click button first time, get alert and you can not type anything in the box.
Now you click button again, get alert second time, and now you can type in the 
box.
So it fails only first time. and if you really click mouse in the box then also 
it lets you type.
Bug is still there.

Comment 13

[ckritzer (gone)]

Marking WORKSFORME on:
- MacOS9 2000-05-25-09-M16 Commercial Build
- Linux6 2000-05-25-09-M16 Commercial Build
- Win95 2000-05-25-09-M16 Commercial Build

Comment 14

[ckritzer (gone)]

Marking VERIFIED.  See previous comments for versions.