Opened 16 years ago
Closed 12 years ago
#8627 closed Bug (fixed)
Textarea misses first line if empty (in display)
Reported by: | sebastian.hillig | Owned by: | sebastian.hillig |
---|---|---|---|
Component: | Forms | Version: | dev |
Severity: | Normal | Keywords: | forms textarea |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
If you save a textarea with a leading empty line, the browser won't show you that line (when viewing that textarea a change form again). This is due to a behaviour that browsers (test FF, Safari on Mac and IE 7 on Win) ignore the first line-break within a textarea when displaying it. Therefore the patch only adds one line-break right after the opening textarea-tag
Attachments (1)
Change History (11)
by , 16 years ago
Attachment: | fix_textarea_disappearing_first_empty_line.diff added |
---|
comment:1 by , 16 years ago
Component: | Uncategorized → Forms |
---|---|
Keywords: | textarea added |
follow-up: 4 comment:2 by , 16 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
I'm not sure I like this. It changes the data without the user's consent. If you load a form, then save, then load again, then save again (e.g. whilst editing), blank lines keep getting added to your data.
comment:3 by , 16 years ago
I really don't like this, because it silently corrupts the data in ways that will' screw with things people commonly use textareas for.
(as I was saying before Malcolm closed this out from under me)
comment:4 by , 16 years ago
Replying to mtredinnick:
I'm not sure I like this. It changes the data without the user's consent. If you load a form, then save, then load again, then save again (e.g. whilst editing), blank lines keep getting added to your data.
In the wild the opposite happens (At least in Safari, Firefox, IE7, Opera, lynx and others). If you rely on lets say one or two newlines in front of other data in a textarea the first newline will get eaten on every save. I have not found a current browser yet that handles this different. Opera has even changed this behavior to ignore the first line: http://my.opera.com/community/forums/topic.dml?id=94823
Use for example FlatPage in admin enter some newlines in the textarea and then some other visible characters. Now hit "Save and continue editing" several times and watch the characters wandering upwards. In reverse entering something different to a newline will work fine. With that patch no additional newline is stored in the database.
The Spec is not 100% clear here but all major Browsers implement it on the same way.
http://www.w3.org/TR/html4/interact/forms.html#h-17.7
comment:5 by , 16 years ago
milestone: | 1.0 → post-1.0 |
---|---|
Resolution: | wontfix |
Status: | closed → reopened |
Triage Stage: | Unreviewed → Design decision needed |
We can look at this after 1.0. It's too late now to have time to test it thoroughly and it's a bit of an edge case (only affects leading blank lines). I'm worried that it will change things for, e.g., machine-processed data that uses HTML intelligently.
comment:6 by , 16 years ago
For documentation:
Maybe this will help with that issue when someone is working or thinking on it later: http://www.toke.de/textarea-nl-testcase.html
comment:8 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → Bug |
comment:9 by , 13 years ago
Easy pickings: | unset |
---|---|
Patch needs improvement: | set |
Triage Stage: | Design decision needed → Accepted |
UI/UX: | unset |
This seems just wrong, but I could confirm the bug. Given that all browsers behave consistently, we'd better add the CRLF.
The patch is stale.
comment:10 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Patch, only adds a line-break, with corrected tests