Closed Bug 38194 Opened 24 years ago Closed 24 years ago

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

Categories

(Core :: DOM: Editor, defect, P3)

Sun
Solaris
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: axel, Assigned: akkzilla)

Details

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
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
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
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
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
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.
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
I checked in the fix for this quite a while ago, but forgot to mark this bug
fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
verified in 9/12 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.