Closed
Bug 299009
Opened 20 years ago
Closed 19 years ago
Leading new line inside a text area is not visible
Categories
(Core :: DOM: HTML Parser, defect)
Core
DOM: HTML Parser
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: carlos, Assigned: mrbkap)
References
()
Details
Attachments
(1 file)
591 bytes,
text/html
|
Details |
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-GB; rv:1.7.6) Gecko/20050524 Firefox/1.0 (Ubuntu package 1.0.2 MFSA2005-44)
Build Identifier: Mozilla/5.0 (X11; U; Linux ppc; en-GB; rv:1.7.6) Gecko/20050524 Firefox/1.0 (Ubuntu package 1.0.2 MFSA2005-44)
In the http://muse.19inch.net/~daf/misc/newline/newline.py page we have a set of
test for textareas and all them with leading new lines fail with Firefox. If you
have a new line as the first character of a textarea, it's not rendered at all.
That means that:
<textarea>Foo</textarea>
and
<textarea>
Foo</textarea> are displayed the same and that's not true.
We detected this bug because we show a textarea to our users as:
<textarea name="foo"></textarea>
and every time they type:
"
Foo"
We get and store it correctly in our database, but when we show it again to our
users from the db value, the html code looks:
<textarea name="foo">
Foo</textarea>
the users are not able to see the new line and if the form is submitted again,
the new value we get and store is just "Foo" without the leading new line.
Reproducible: Always
Steps to Reproduce:
1.Create a form with an empty textarea
2.Submit a value that starts with a new line as the first character
3.Render again the same form showing the submitted value inside the textarea
4.Submit it again without changing anything
Actual Results:
After step number 3 the rendered page will show you the textarea with that first
new line character.
After the step number 4, if you check the new submitted value you will see that
the submitted value is different from the first submitted value althought you
didn't change anything.
Expected Results:
The textarea shows an empty line as the first entry in the textarea and the
submitted value is the same as the first time.
Seems like Opera does the rigth thing (just in case you can see the difference)
Safari is broken too.
Comment 1•20 years ago
|
||
Testcase seems to confirm the issue; I'm curious as to whether there is
something in the spec we're ignoring here or whether this is underspecified.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 2•20 years ago
|
||
According to the HTML spec (see
http://www.w3.org/TR/html4/appendix/notes.html#h-B.3.1) newlines immediately
after start tags and before end tags are never significant. While we don't
implement this to the letter, on certain tags (namely: <textarea>, <pre>, and
<xmp>) we do strip a leading newline. So the HTML spec does say that:
<textarea>
foo</textarea>
and
<textarea>foo</textarea>
are equivalent.
From testing Opera, it seems that they have a bug where they don't strip a
leading CRLF, otherwise it looks like IE, Opera, and Firefox all do the same
thing here.
Comment 3•20 years ago
|
||
Blake suggested a workaround over IRC:
<kiko> mrbkap, so essentially, if we want to have a newline there, we need to
add two \r\ns after the <textarea> element?
<kiko> (and live with opera breakage)
<mrbkap> kiko: why not just add a '\n' after the <textarea> and make everybody
happy?
<mrbkap> since everybody should just strip it
<mrbkap> kiko: then output '<textarea>\n' + user_value
<mrbkap> so if they entered a leading newline, it will show up
<kiko> I'm only concerned that the Opera people will increasingly see leading
newlines.
<kiko> because every time they submit, they submit two instead of one in the
\n\r\n case.
<mrbkap> kiko: except by my testing (on Linux anyway), opera only fails to strip
\r\n
<mrbkap> and strips \n fine
<kiko> or hmmm, that appears to be true.
<mrbkap> (and \r fine, for that matter)
Given Opera's behaviour, it appears that using a single \n after the close-tag
character should give the correct behaviour. Carlos, can you confirm this works
for you?
Reporter | ||
Comment 4•20 years ago
|
||
(In reply to comment #2)
> According to the HTML spec (see
> http://www.w3.org/TR/html4/appendix/notes.html#h-B.3.1) newlines immediately
> after start tags and before end tags are never significant. While we don't
> implement this to the letter, on certain tags (namely: <textarea>, <pre>, and
> <xmp>) we do strip a leading newline.
Completely true.
We are using Zope's tal templates and it was adding extra newlines and I got
confused...
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 5•20 years ago
|
||
(In reply to comment #3)
>
> Given Opera's behaviour, it appears that using a single \n after the close-tag
> character should give the correct behaviour. Carlos, can you confirm this works
> for you?
Yeah, that's the way I fixed it.
Thank you.
Reporter | ||
Comment 6•20 years ago
|
||
This is a real bug, not exactly as I thought in the first place, but after some
hours working with our html generator and different kind of data, I found it.
Will attach a test to show you the problem but as a summary, the problem comes
with the close tag, it adds an extra new line and does not follows the spec because:
<textarea>foo</textarea> (gives you "foo" as the content)
is not the same as:
<textarea>
foo
</textarea> (that gives you "foo\r\n" as the content)
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Reporter | ||
Comment 7•20 years ago
|
||
Assignee | ||
Comment 8•20 years ago
|
||
Right, I said that we only partially implement this (exactly as much as Opera
and IE do, for that matter) and that we only strip the first leading newline
(and not the last). I'm not sure what the problem is here, exactly. Note that
bug 2750 exists for implementing this for all tags, but I'm not sure that we
want to follow the spec here, since we'd then break compatibility with every
other browser out there right now.
Reporter | ||
Comment 9•20 years ago
|
||
(In reply to comment #8)
> Right, I said that we only partially implement this (exactly as much as Opera
> and IE do, for that matter) and that we only strip the first leading newline
> (and not the last). I'm not sure what the problem is here, exactly. Note that
> bug 2750 exists for implementing this for all tags, but I'm not sure that we
> want to follow the spec here, since we'd then break compatibility with every
> other browser out there right now.
The problem is, that if you generate forms as:
<textarea>
$somecontent
</textarea>
The submit gets a newline char added to the end of $somecontent, usually, that's
not a big problem, but in our application it is as it's to translate and the
submitted data will be used outside the web as translations.
Also, our workflow allows you to submit the form with a translation several
times without changing anythin, then, we detect if it changed or not and decide
to store the new value if it changed or not. With this 'feature', the
translation always changes, adding an extra new line every time.
Another problem comes when you create the form with some indentation, in that
case, if you have something like:
<textarea>
$content
</textarea>
You get too extra whitespaces not only an extra newline.
I understand your point that following the spec could break compability with the
other browsers, but I thought that the standars are defined to be followed...
As a workaround to this problem, we are using now:
<textarea></textarea> when we don't have any content
and
<textarea>
$content</textarea> when we have some content.
This solution will be broken with a browser that follows the standard. If the
user adds a newline character at the end of the content text, after we show it
again to the user because it will be generated as:
<textarea>
something
</textarea>
and the browser will ignore that last newline, but It's a corner case and we
will implement a workaround to prevent that our users need to add newlines at
the end of the content.
In conclusion, I think it's a bit odd this situation and I also know it's not
easy to fix it because many forms will be broken after this fix, but I think
that if you decide to ignore that implementation, a request to update the
standard should be send too...
Cheers and thanks for your time.
![]() |
||
Comment 10•19 years ago
|
||
Not a view rendering issue (and is probably wontfix, as Blake said).
Assignee: roc → mrbkap
Status: REOPENED → NEW
Component: Layout: View Rendering → HTML: Parser
QA Contact: ian → parser
Assignee | ||
Comment 11•19 years ago
|
||
I'm going to mark this WONTFIX. It seems like there's a trivial fix on the web app end (don't output a trailing newline after the user's value) and we're currently interoperable with EOMB (every other major browser).
Status: NEW → RESOLVED
Closed: 20 years ago → 19 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•