Closed Bug 18479 Opened 26 years ago Closed 26 years ago

[DOGFOOD]Select fields are empty if html parser is interrupted

Categories

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

x86
All
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: shrir, Assigned: rods)

Details

(Whiteboard: [PDT-])

Using today's commercial build on Linux, try the folowing: 1.Install the build. 2.Launch the browser. 3.Go to "http://people.netscape.com/morse/wallet/samples/INTERVIEW.HTML" and enter first and last name. 4. Select Edit | Wallet | Capture Form . A dialog should come up asking if you would like info saved. 5. Follow the prompts. 6. Quit and relaunch the browser. Then, go to "http://people.netscape.com/morse/wallet/samples/INTERVIEW.HTML" 7.Select Edit | Wallet | Safe Form Fill. 8. Observe that a Screen comes up with an empty Pull Down list. 9. Ideally your name should have been visible there.
I just noticed this as well. See my comment in bug 17995
Assignee: sujay → morse
Component: Layout → Autofill
QA Contact: petersen → paulmac
updating assignee and component
Status: NEW → ASSIGNED
Target Milestone: M12
Actually the pull-down lists aren't empty -- if you select them, the values in the list are displayed. Problem is that the initial selection was not being displayed. Here's a simple test case to demonstrate the problem. If the writing was done with one document.write statement instead of two, the problem does not occur. Sounds very familiar -- like I just saw this bug occur elsewhere. I'll do a search. <html> <script> list_frame = 1; function loadFrames(){ top.frames[list_frame].document.open(); top.frames[list_frame].document.write( "<form>" + "Name:" + "<select>" ) top.frames[list_frame].document.write( "<option VALUE='Name'>Morse</option>" + "<option VALUE='Name'>&lt;do not prefill&gt;</option>" + "</select><br/>" + "</form>" ); top.frames[list_frame].document.close(); }; </script> <frameset rows = "25,100" onload="loadFrames();"> <frame src="about:blank"> <frame src="about:blank"> </frameset> </html>
OS: Linux → All
This is not linux-specific. Updating the OS to be "all".
Component: Autofill → HTML Form Controls
OK, the bug I was thinking of was bug 17852. It was similar to this bug in that both problems occured because the html parser got interrupted in the middle of a select statement. This symptoms differ however -- in 17852 there was a crash there but in this bug there is simply a failure to display the selected value.
Assignee: morse → rods
Status: ASSIGNED → NEW
This is definitely related to bug 17852. The test case in that bug report is now showing the same symptoms as reported here -- i.e., no value is initially displayed in the list. Here is that test case: <html> <body> <select> <script>dump('block parser to cause crash\n');</script> <option VALUE='first'>steve</option> </select> </body> </html> Assigning to rods since he was the one who fixed bug 17852
Summary: Safe Form Fill's Name field empty → [DOGFOOD]Safe Form Fill's Name field empty
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
This is a duplicate, but I don't remember the number, it should be fixed now.
Status: RESOLVED → REOPENED
No, it's not fixed. Still does it as of a tree that I pulled this morning. I think the bug that you were thinking of was 177852 (as I mentioned above) which had to do with a crash. This is not a crash -- simply the fact that the list does not come up pre-selected.
Resolution: FIXED → ---
Whiteboard: [PDT-]
Putting on PDT- radar.
Summary: [DOGFOOD]Safe Form Fill's Name field empty → [DOGFOOD]Select fields are empty if html parser is interrupted
Since this has been marked PTD-, I don't expect the basic problem to be fixed for M12. So I have checked in a simple work-around in the safe-form-fill dialog that insures that makes it does not appear to be empty. Basically, I avoid the problem by putting the <select> and the first <option> in the same write statement. With this change, safe-formfill is no affected by this problem. So I'm changing summary line from: Safe Form Fill's Name field empty to Select fields are empty if html parser is interrupted
Status: REOPENED → RESOLVED
Closed: 26 years ago26 years ago
Resolution: --- → FIXED
The list wasn't notifying the combobox when it had been reset and that it should still try to make sure something was selected - Fixed
I didn't expect this bug to get fixed so quickly. Just backed out my hacked fix to the safe-form-fill dialog. With this bug fixed, the old dialog is working just fine. So you can use that as a test to verify this bug.
Status: RESOLVED → VERIFIED
verified
You need to log in before you can comment on or make changes to this bug.