Closed Bug 1286 Opened 26 years ago Closed 25 years ago

JS modifying non-existent widgets.

Categories

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

Product:
Core
Component:
Layout: Form Controls
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: jeremie, Assigned: pollmann)

References

(
URL
)

Details

Attachments

(1 file)

test case
(deleted), text/html
Details
As seen in the noted URL, javascript and form textarea values are not hooked up.
Status: NEW → ASSIGNED
Setting all current Open/Normal to M4.
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
QA Contact: 4110 → 4137
Reassigning qa contact to cpratt@netscape.com
Assignee: karnaze → pollmann
Status: ASSIGNED → NEW
Eric, this looks like a dom (or javascript) bug. The text area should end up with "foo bar" in it.
Status: NEW → ASSIGNED
Here's the interesting part: <BODY onload="foo()"> <FORM> <TEXTAREA>This is a test!</TEXTAREA> </FORM> <SCRIPT> foo() function foo() { dump(document.forms[0].elements[0].value+"\n") document.forms[0].elements[0].value = "foo bar" dump(document.forms[0].elements[0].value+"\n") } </SCRIPT> </BODY> This is posted internally at http://blueviper/forms/textareadom.html It seems that the DOM accesor method is depending on the widget having already been created, and it's not at the point this script executes. I'll take a look.
Summary: JS and textareas → JS modifying non-existent widgets.
Target Milestone: M4 → M6
Vidur, this is an interesting problem. What should we do in the case that the value attribute of a text area (selectedIndex in the case of <SELECT>'s, selected in the case of <OPTIONS>'s, ...) is set before the corresponding widget is created? (This URL is a great minimal example of our illogical behaviour) We can't store the value in the DOM because the DOM doesn't store this value. We can't store it in the widget because the widget hasn't been created yet. Can we delay execution of a javascript until the widgets above them in-flow are created? Can we store the value temporarily somewhere to initialize the widget with later when it is actually created? (I know of no such mechanism yet, is there one?) The relevent code is at: layout/html/content/src/nsHTMLTextAreaElement.cpp line 318 GetPrimaryFrame is returning null but the call is still returning NS_OK For selects/selectedIndex it is at: layout/html/content/src/nsHTMLSelectElement.cpp line 375 same problem. I already put a related hack into nsHTMLSelectElement to *get* the selectedIndex based on what it should be when the widget is later created. However, if the selected attribute of an option is modified before this call, it will return the defaultSelected value incorrectly.
Redistributing to M8...
Component: Form Submission → HTML Form Controls
OS: Windows 95 → All
Hardware: PC → All
Target Milestone: M8 → M11
Solving this problem will require some substantial changes to many form element's frame code to cache information until widgets are created. Scheduling for M11.
Target Milestone: M11 → M12
Attached file test case (deleted) —
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Target Milestone: M12 → M11
I fixed this with yesterday's checkin. To verify, go the the attached test case. The text area should read "foo bar" if the test worked, and "This is a test!" if it failed.
Status: RESOLVED → VERIFIED
Following pollmann's clear, concise instructions (thanks, pollmann!), everything works as expected in the 1999091508 build under NT. Marking verified fixed.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: