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)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: carlos, Assigned: mrbkap)

References

()

Details

Attachments

(1 file)

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.
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
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.
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?
(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
(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.
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 → ---
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.
(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.
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
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 ago19 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: