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.

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

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.

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.

I checked in the fix for this quite a while ago, but forgot to mark this bug fixed.

verified in 9/12 build.