Open Bug 332524 Opened 15 years ago Updated 3 years ago
Textarea submitting incorrect string under wrap=hard
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20060111 Firefox/18.104.22.168 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20060111 Firefox/126.96.36.199 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 188.8.131.52 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.
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.
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!
You need to log in before you can comment on or make changes to this bug.