textarea.value returns bogus "\n" to javascript for empty last line

VERIFIED FIXED in M17

Status

()

defect
P3
normal
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: axel, Assigned: akkzilla)

Tracking

Trunk
Sun
Solaris
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Description

19 years ago
If I start with an empty textarea, and type a RETURN in it, it will report
two \n back to javascript. This only happens, if the empty line is at the 
end of the text.
This gives you an extra free line, if you add text via javascript.
The extra \n appears in other outputs as well.

Axel
Assignee

Comment 1

19 years ago
This is reproducible in the plaintext editor (which makes debugging much
easier): bring up the plaintext editor, click in it if necessary, hit a single
return, then do Debug->Output Text and Debug->Dump Content Tree.  Notice that
there are two br tags, one with no attributes and one with type=_moz.

The plaintext output sink treats br type=_moz just like any other br.  Should it
be skipping them?  How about the bogus node -- does it need to worry about that?

Adding Joe in the hope that he knows what's supposed to happen here.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

19 years ago
I'm going to go ahead and assign it to Joe -- and set it to m17 for now, doesn't 
seem like it is a blocker or showstopper
Assignee: beppe → jfrancis
Target Milestone: --- → M17

Comment 3

19 years ago
I need to put in 2 break nodes in order to supply the blank line.  One break at 
the end of some text, for instance, does not give you a blank line below that 
text to put the caret.  We have to put in a second br to get that blank line.  

I guess we could have the output system strip moz-br's, but there are some times 
when you wouldn't want to do that.  (For instance, if the user creates an empty 
paragraph, I have to put a moz-br in it to get the paragraph to render, and if 
you strip it out on output and then use some other client to read it back in, you 
will be missing the vertical whitespace casued by the "empty" paragraph.)

What we should probably do is hav eth output system ignore moz br's if and only 
if it is outputting text (not html).  Assigning to Akkana.
Assignee: jfrancis → akkana
Reporter

Comment 4

19 years ago
Joe, to your example why we should output the moz-br's.
Wouldn't it be a bug in the other viewer to not display whitespace for an empty 
paragraph? And if the viewer would display the paragraph correctly, wouldn't
we require it to understand (and neglect) our moz-br's?

What is in the standards? Should an empty paragraph do spacing?
I am asking as I have no clue which document there is internally, and which
standards it should adhere, I would guess HTML4, and would think, it should
display.
So if mozilla needs some dummy content do display correctly, why tell the rest
of the world?

Just my $0.02

Axel

Comment 5

19 years ago
html viewers traditional do not render empty <p>s.

There are no standards.  Rendering standards only apply to css.  HTML is free to 
be rendered however a viewer likes.
Assignee

Comment 6

19 years ago
I have a fix for this.  We're already hacking around this in the html output
sink; might as well do it in the plaintext sink as well.  Sigh.  I wish we had a
better solution that wouldn't take forever to implement.
Status: NEW → ASSIGNED
Assignee

Comment 7

19 years ago
I checked in the fix for this quite a while ago, but forgot to mark this bug
fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 8

19 years ago
verified in 9/12 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.