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)

x86
Linux
defect

Tracking

()

VERIFIED WORKSFORME

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();
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
baron@cattell.psych.upenn.edu - are you still seeing this problem on recent builds of Mozilla? Gerv
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
Confirming. Gerv
Status: UNCONFIRMED → NEW
Ever confirmed: true
The URL above doesn't work, could you provide a test case or vaild URL?
reassigning
Assignee: rods → beppe
assigning to kin for review
Assignee: beppe → kin
Target Milestone: --- → M18
URL is working now... Gerv
Accepting bug.
Status: NEW → ASSIGNED
Keywords: nsbeta2
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.
PDT needs a retest on this please.
Whiteboard: [NEED INFO]
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.
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
Status: RESOLVED → VERIFIED
Marking VERIFIED. See previous comments for versions.
You need to log in before you can comment on or make changes to this bug.