84278 - Leading whitespace lost in form multiline text-entry widget at submission

Status: VERIFIED WORKSFORME

(Core :: DOM: Editor, defect)

Description

[Kent Paul Dolan]

*

This may be related to bug 30471, in that common code could conceivably
be causing the similarly described problem there, but does not duplicate
it directly.

Leading whitespace at the beginning of a multiline textbox is stripped when
submitting a form.  I found this when trying to enter a centered first line
in a Usenet news posting at a descendent of http://groups.google.com, but
if the asterisk at the beginning of this box isn't on the second line indented
ten spaces, in the resulting report then the bug reproduces at the referenced
URL as well.  If not, the original spotting was at this messy location:

http://posting.google.com/post?cmd=post&enc=ISO-8859-1&group=talk.bizarre&gs=/groups%3Fhl%3Den%26lr%3D%26safe%3Doff%26group%3Dtalk.bizarre

and can be replicated by opening that window, entering some nonsense with some
leading whitespace (I used newlines and space characters followed by
blackspace), and then asking to see a preview of the posting.

A bugzilla search for "whitespace form" in the summary and description fields
found 133 bugs, but none seemed to duplicate this one.

Marked "major" because it disables some types of exact text entry into forms,
trivial sometimes but crucial in other applications.

Seen in build 2001052708 for win32.

Comment 1

[Kent Paul Dolan]

Yes, the problem replicates in the bugzilla bug report form multiline text-entry
widgets, the asterisk in my original description for this bug lost its leading
ten spaces and previous blank line, as (un)expected.

Comment 2

[Kent Paul Dolan]

I've also seen this earlier: when pasting my resume into a text box, the
centered first line became left justified in the ack email copy to me, but I
didn't realize it was a browser bug at the time, so there are at least three
circumstances that reproduce this bug.

The "Resume Text" form box of the below messy URL is an example of this case,
but not a suitable testbed unless you intercept the output so as not to annoy
the intended recipient of the form contents.

http://job11.cbdr.com/Scripts/cgihndlr.exe/cgihndlr.exe/RT=TE/TEM=teDTL01.nst/LR=R/JB=86522/S1=820181/R=410001?S2=410001

You could title this one "son of line-eater", I suppose, for those old enough
in net-years to catch the joke about a well known BNEWS bug, the workaround
for which outlived the bug itself by five years or so.

Comment 3

[rods (gone)]

reassigning

Comment 4

[Kent Paul Dolan]

I have to go off the net for a while, so I cannot participate in Mozilla bug
reports any more, but as one last attempt to help, I noticed that this problem
also includes stripping the _trailing_ whitespace from a multiline forms text
entry widget, when trying to leave some trailing whitespace using the
groups.google.com Usenet article posting interface as previously mentioned.

To reproduce, navigate to the site to a current articles list view, post a new
article in some newsgroup (button at the top of the article list), enter some
nonsense Usenet article text including trailing whitespace, ask to preview the
posting, ask to edit the posting some more, notice that the trailing whitespace
is now gone.

Good luck, folks.

Comment 5

[Kathleen :Brade]

this might be an editor bug (maybe even a duplicate?)
-->editor for investigation
(we'll bounce it back to Form Submission if it's not in editor)

Comment 6

[Syd Logan]

spam composer change

Comment 7

[Kathleen :Brade]

-->Core

Comment 8

[Kathleen :Brade]

-->Core

Comment 9

[kinmoz]

The problem that Kent mentions while pasting, was bug 86450, which was fixed a
while ago.

I can't reproduce the problem during submission, so I'm marking this as
WORKSFORME. Kent if you can still reproduce the problem reopen and let me know.

I tried leading and trailing space, and in all cases the spaces were sent on
submission.

Comment 10

[James Baxter]

WFM too - Verified