332524 - Textarea submitting incorrect string under wrap=hard

Status: RESOLVED INCOMPLETE

(Core :: DOM: Core & HTML, defect, P3)

Description

[Csaba Gabor]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

I have a textarea, with wrap=hard, that is submitting an incorrect string to the server, as I understand the workings of textareas.  Specifically, it is inserting %0D%0A in incorrect places.

As I undersand textareas under wrap=hard, for each pair of adjacent lines (which could be empty) in the control, there should be exactly one %0D%0A (or equivalent) submitted between them.  No more, and no less, and in no other place.  In other words, what the server gets matches what the user sees on his or her screen.

If you take the example attachment, then what I see on my Win XP Pro, FF 1.5.0.1 system is a textarea of 22(!) and not 20 columns.  There are exactly 9 rows which I show within quotes, so spaces can be observed, and with \n for my explicit newlines.  That \s is a space that I supplied, but no longer appears (as it does at the end of the first row, for example):
"wrapped textarea "
"starting text with\n"
"tag newline.  But what\s"
"does it do with this?\n"
"and these\n"
"inserted\n"
"new\n"
"\n"
"lines"

At this point just click on the Submit button, and then view the frame properties for the target frame to the right, where the submission went, to see what was submitted.  Alternately, if you have PHP, you could put a one line php file on your system: <?php phpinfo() ?> and then change the action of the form in the example to point to the php page.

What I expect to get when I submit this to the server (or the iframe) is the lines shown above concatenated, with \n and \s replaced by %0D%0A.  Instead, what I get is:
?txt=text+elem+starting+text&ta=wrapped+textarea%0D%0Astarting+text+with%0D%0Atag+newline.++But%0D%0Awhat+does+it+do+with%0D%0Athis%3F%0D%0Aand+these%0D%0Ainserted%0D%0Anew%0D%0A%0D%0Alines

Bug: In particular, notice that there is a %0D%0A between 'But' and 'what' instead of between 'what' and 'does'.  Also, there is an extra %0D%0A between 'with' and 'this' disagreeing with what I see on my screen.

Csaba Gabor from Vienna

Reproducible: Always

Steps to Reproduce:




It always puzzles me how to mark a bug when data is corrupted.  From my point of view, data corruption is tantamount to data loss, which the severity scale shows as critical.  I just couldn't bring myself to mark it that high though.

This is probably tied up with the scroll bar.  In particular, if I go to the end of the text area and add a new line by pressing Enter, then the rest of the text area matches with what was submitted.  However, in my opinion this does not mitigate the severity of the problem.  Whether or not the scroll bars should be there is a separate issue.

However, as long as we're on the topic...
If I now hit the backspace to get rid of the previously entered Enter (so that I am back to my original text), the scroll bars have not gone away.  Indeed, with the scroll bars there, the textarea takes up 10 rows (1 greater than the original 9), justifying their existence. If I then go to the empty line, press backspace (to reduce the row count), the scroll bar goes poof, and now I press enter to recover to the original entry.

Comment 1

[Csaba Gabor]

Attachment: Textarea tester

Shows a case where the textarea submits incorrect data.  Pressing the Submit button and then viewing the Frame info allows you to see what was submitted.

Comment 2

[Rayann Tedds]

Hiya,

I would like to work on this bug as part of my university coursework. Please could I be assigned to it and given extra information? Thank you!

Comment 3

[Andrei Purice]

Marking this as Resolved > Incomplete since the last activity on this issue was 16 years ago and it might not be relevant anymore.
Feel free to re-open if the issue is still reproducible on your end in the latest FF versions.