74091 - TEXTAREA loses soft returns on back button. [form sub]

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Ian]

I've notice a small glitch with the textarea element in the forms. 

If you create a form using something like the HTML code below:

<FORM  METHOD="POST" ACTION="anything.cgi">
   <TEXTAREA NAME="ANYTHING" ROWS="7" COLS="50" WRAP="HARD"></TEXTAREA>
   <INPUT  TYPE="SUBMIT">
</FORM>

Then you enter some data in the form. Enter enough data so that the textarea box
does soft returns. Now when the form is submitted the data is sent with hard
returns as it should. But now if I hit the back button to get the form on the
window again (so I can continue editing) all the soft returns within the form
have now changed to hard returns. Maybe this is the way the system was designed
to work, but I don't think it should be this way. To me if I go back, the form
should contain the exact same data as it did before I hit submit. I noticed that
this bug exist on Netscape 4.76 and on mozilla browsers but does not exist on IE
5.5. It is more are an annoyance than anything. 

Here is a step by step sample. 

* Create the form as mentioned above.
* Enter the information below as one line to let the window do soft returns.
When reporting a bug about page handling, it is recommended that you test the
problem isn't an intentional difference between the modes. 
* Now type "Hello world" before the word "problem"
* You should notice that the text is still in soft returns.
* Now submit the form and then click on the back button. 
* The data should still be in the box. 
* Now enter "Another Word" before "Hello".
* You should notice that is now a hard return after the word "problem"

Comment 1

[Kathleen :Brade]

cc Joe in case he knows anything about this bug.

Comment 2

[basic]

this might be related to bug 50633

Comment 3

[basic]

Attachment: testcase

Comment 4

[Chad Austin]

confirmed Win2K 20010607, 0.9.1 branch

Comment 5

[rods (gone)]

Mass move of form submission bugs, Eric, I am sorry I don't have more time to 
look at these closer.

Comment 6

[Kevin McCluskey (gone)]

Bulk reassigning form bugs to Alex

Comment 7

[Vladimir Ermakov]

The bug is sill here on 2001-10-23-09-trunk...

Comment 8

[Alexandru Savulov]

setting milestone

Comment 9

[John Keiser (jkeiser)]

This is totally form controls, and will probably be fixed when bug 112430 is ...
the problem is the way we're using the serializer--we just have to flip a bit
somewhere that says not to make the wraps happen when we're about to store the
value.  In that bug we're going to be touching that code directly anyway.

Comment 10

[Kevin McCluskey (gone)]

Moving to Mozilla1.1

Comment 11

[John Keiser (jkeiser)]

I keep meaning to nominate this.  This is an incredibly annoying bug for me when
using Mozilla.

Comment 12

[Kevin McCluskey (gone)]

nsbeta1-.

Comment 13

[John Keiser (jkeiser)]

Attachment: JS testcase

A related problem, which I am uploading now, is that JS shows hard returns even
though it should not (at least IE does not, and it seem to me they are
right--wrap=hard is essentially unformatted until submission).

Comment 14

[John Keiser (jkeiser)]

Attachment: Patch

This patch fixes the problem by adding an interface to nsGfxTextControlFrame2
to allow content to grab the value either with or without wrapping.  Content
will grab it without wrapping in all cases now except submission.  To keep
everything else the same, all frames do as they did before and grab the value
with wrapping.

This has been tested with Bugzilla and with the testcase provided.  wrap=hard
submits with wrapping but does not appear to be wrapped for JS or for
save/restore.  Glory be!

This patch also consolidates GetPrimaryFrame(), which was being done in
multiple places.  Everything is tested and still works (I tested
image.naturalHeight).  I would have liked to consolidate body.bgColor, but a
bug there prevented testing (there *is* no primary frame) so I left it the same
and added a comment.

Comment 15

[John Keiser (jkeiser)]

So the preceding patch works, and I am writing this comment with the patched
build to prove it.  The patch was uploaded with the patched build, of course,
but that has wrap=soft.

save/restore works beautifully.

Comment 16

[rods (gone)]

Comment on attachment 83468 [details] [diff] [review]
Patch

make sure you test Printing and PP r=rods

Comment 17

[Marc Attinasi]

Comment on attachment 83468 [details] [diff] [review]
Patch

sr=attinasi

Comment 18

[John Keiser (jkeiser)]

Checked in to trunk.

Comment 19

[John Keiser (jkeiser)]

(marking fixed)

Comment 20

[Johnny Stenback (:jst)]

Argh! This caused bug 145741, there isn't always a frame available for all
elements, we're now calling GetPrimaryFrameFor() and then calling
CallQueryInterface() on the result in at least two places w/o checking if we
found a frame or not! CallQueryInterface() is NOT null safe! I'll fix bug
145741, but someone should add null ptr protection in nsHTMLTextAreaElement.cpp too.

Reopening.

Comment 21

[John Keiser (jkeiser)]

Attachment: CallQueryInterface brown bag fix

My bad, I keep thinking do_QueryInterface and CallQueryInterface are
functionally the same thing, which they are not.

Comment 22

[John Keiser (jkeiser)]

BTW, looking at the patch, there are no other places where I introduced this.

Comment 23

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 84299 [details] [diff] [review]
CallQueryInterface brown bag fix

This looks like it will also fix the crash I'm seeing when submitting after
using "Edit Attachment as Comment" in bugzilla.

In any case, r=dbaron.

Comment 24

[Johnny Stenback (:jst)]

Comment on attachment 84299 [details] [diff] [review]
CallQueryInterface brown bag fix

sr=jst

nsHTMLImageElement::GetImageFrame() (bug 145741) and the one you just fixed
were the two places where CallQueryInterface() could be called on a null
pointer IIRC.

Comment 25

[John Keiser (jkeiser)]

Yet Another Fix Checked In.

Comment 26

[Vladimir Ermakov]

Verifying on build 2002-07-03-10-trunk on windows 98