Closed
Bug 31181
Opened 25 years ago
Closed 25 years ago
no input in return of focus after alert
Categories
(Core :: Layout: Form Controls, defect, P3)
Tracking
()
VERIFIED
WORKSFORME
M18
People
(Reporter: jonathanbaron7, Assigned: kinmoz)
References
()
Details
(Whiteboard: [NEED INFO])
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•25 years ago
|
||
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
Assignee: trudelle → rods
Component: XP Toolkit/Widgets → HTML Form Controls
QA Contact: jrgm → ckritzer
Comment 2•25 years ago
|
||
baron@cattell.psych.upenn.edu - are you still seeing this problem on recent
builds of Mozilla?
Gerv
Comment 3•25 years ago
|
||
From an email received from baron@cattell.psych.upenn.edu:
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 5•25 years ago
|
||
The URL above doesn't work, could you provide a test case or vaild URL?
Updated•25 years ago
|
Target Milestone: --- → M18
Comment 8•25 years ago
|
||
URL is working now...
Gerv
Comment 10•25 years ago
|
||
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 12•25 years ago
|
||
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•25 years ago
|
||
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
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 14•25 years ago
|
||
Marking VERIFIED. See previous comments for versions.
You need to log in
before you can comment on or make changes to this bug.
Description
•