Closed Bug 33014 Opened 24 years ago Closed 23 years ago

Strange textarea content update when changed from JavaScript

Categories

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

x86
Windows 98
defect

Tracking

()

VERIFIED FIXED
mozilla1.0

People

(Reporter: martin.honnen, Assigned: mozeditor)

Details

Attachments

(1 file)

I have the following simple form
<FORM NAME="formName">
<INPUT TYPE="button" VALUE="add text"
       ONCLICK="this.form.output.value += new Date().toString() + '\r\n';"
>
<BR>
<TEXTAREA NAME="output" ROWS="25" COLS="80" WRAP="soft"></TEXTAREA>
</FORM>

which should just allow  - by pressing the button - to add a line with the 
current Date repeatedly to the text area. The date is added however there are 
additional lines added every time you press the button so that distances between 
the lines increase steadily. Very strange behaviour. 
Bug is probably related to
http://bugzilla.mozilla.org/show_bug.cgi?id=28623
where others complained about their javascript assigment to text area not 
showing up correctly. 
This is simple DOM level 0 stuff that ought to work without problems.
kin could you take a look? If not maybe it's a buster bug.
Assignee: rods → kin
Joe--could you look at this and see if it's a block transformation issue?  The 
strings all get added in the proper order but the breaks seem to get messed up 
after the 3rd click.
Assignee: kin → jfrancis
Target Milestone: --- → M15
setting to M16, just in case this is a block issue
Target Milestone: M15 → M16
i accept Bugzilla as my lord and savior.  
Status: NEW → ASSIGNED
moving this over to m17
Target Milestone: M16 → M17
dom0 b.c. nsbeta2 6/1-.
Keywords: nsbeta2
Where are we exposed here?  Highly visable pages?
Whiteboard: [NEED INFO]
[nsbeta2-] 
Whiteboard: [NEED INFO] → [nsbeta2-] [NEED INFO]
i put the same comment on another bug (#35463) :

on any HTMLInput object, this.form is undefined anyway. it should reference the
form the input belongs to.

hmmm... maybe i had better open a proper bug report for this .form problem ?
oops, forget about my previous comment. i tested it on another machine and it
worked. the first machine must have something wrong with its installation of Moz.

sorry for the spam.
moving to future
Keywords: nsbeta2
Whiteboard: [nsbeta2-] [NEED INFO]
Target Milestone: M17 → Future
Updating QA contact.
QA Contact: ckritzer → bsharma
QA Contact Update
QA Contact: bsharma → vladimire
1.0
Target Milestone: Future → mozilla1.0
Attached file Test case.
I just the test case mentioned above, and tried it on windows, linux, and mac
builds ... it looks like this bug is fixed. Martin, reopen this bug if you still
see it.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Verifying on build 2001-09-06-05 branch
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: