Enter key at the end of line in the quoted text in plain text mode inserts two newlines. This bug is similar with bug 58960. Build: 2001100203/Win2k

*spam* Moving these bugs target milestones back to Mozilla 1.0 as they're listed in a tracking bug for fixes essential for 1.0

Duplicate of bug 67391, perhaps?

As jjkarppi@cs.helsinki.fi pointed out, this is a dupe of bug 102842 -- or vice versa, bug 102842 has more comments. Bug 67391 is much more specific than this bug, but seems related. pi

reassign to editor core

Marking as duplicate of 102842; please un-dup if you disagree. *** This bug has been marked as a duplicate of 102842 ***

verified.

bug 012842 was marked as FIXED, but I can reproduce this bug with 2002020611/Linux. Reopening. I can reproduce the similar bug 58960.

*** Bug 106225 has been marked as a duplicate of this bug. ***

Moving to Moz1.1

it seems to act like bug #92686 was "fixed". If you hit Shift+Enter, the proper behavior occurs. Enter seems to insert a paragraph break and Shift+Enter inserts a line break. I think that Enter should always insert a line break when in plain text mode.

I got it. There is a silly mistake in nsHTMLEditor.cpp. Try this patch.

Sorry, I mistook, too... Try newer one.

I added one more fix of the same mistake on that file. (Thanks, Kazuhiko.)

Comment on attachment 69902 [details] [diff] [review] a patch with one more fix The changes that do a straight replacement of eEditorPlaintextBit with eEditorPlaintextMask should be done. But my guess is that this change in the *logic* shouldn't be made: - if (isShift && !(mFlags&eEditorPlaintextBit)) + if (isShift || mFlags&eEditorPlaintextMask ) That change will prevent the HTML rules code from being triggered which handles the splitting of <pre> and <span> containers that can be in Plaintext Mail Compose replies. Cc'ing jfrancis for confirmation.

Cc'ing jfrancis ... Joe see my previous comment. I'm thinking that the code in question is specifically for HTML editors, ala, inserting <br>s in containers like <li> without breaking or adding new new list items, so the logic is correct.

Okay. I'll modify my patch. It seems, all we have to do is this: When Enter key is hitted, split <SPAN> and insert one BR only for plain text mail composition. (Now, two BR will be inserted.) I'll make some more efforts for this bug.

*** Bug 130233 has been marked as a duplicate of this bug. ***

Comment on attachment 73156 [details] [diff] [review] a patch with replaces only r=jfrancis

*** Bug 123854 has been marked as a duplicate of this bug. ***

Comment on attachment 73156 [details] [diff] [review] a patch with replaces only sr=kin@netscape.com So does this fix the reported problem? Or does this bug need to remain open after this patch is checked in?

This patch does not fix this bug. (I have no solutions to fix it now.) We need other works. Please remain open.

Actualyy, this bug here is more general thant the summary suggests, compare bug 123854. It also happens when you press enter in the middle of a quoted line. pi

Comment on attachment 73156 [details] [diff] [review] a patch with replaces only a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Has this landed? It was approved 10 days ago.

I asked jfrancis to check-in it. (I have no CVS account.) But it has not been check-in yet. I'll ask him again.

This is a true fix, I hope. In detail, SplitNodeDeep (and CreateBR for inline node at line#1385) makes a break. So, we should not add an extra BR in Plaintext mode.

Comment on attachment 73156 [details] [diff] [review] a patch with replaces only btw, i checked in the approved patch. Marking obsolete...

*** Bug 124733 has been marked as a duplicate of this bug. ***

skamio's patch causes you not to get any blank line at all if you split a plaintext mailcite in the middle of a line (instead fo at the end). I am attaching a patch that I think will work (though I can't test it right now).

this patch detects when there is already a break before the split point when splitting an inline mailcite. We only need to add a second br when there wasn't a break at end of split cite.

Joe, please make sure this patch is thoroughly tested before checking in.. also test other areas this might affect it. thanks.

so kin found some probs with patch. I revised to address, but i'm not going to post it because i realize now that there is a larger prob i have to solve. i'll post a new patch when it's ready. re sujay's comment: of course. i never land without testing. I was just posting so that kin/akk/brade could help me test it out.

new patch in bug 83378.

over to me

83378 has landed on trunk.

nsbeta1-. The fix is too risky for the 1.0 branch.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a+) Gecko/20020701 Now it WFM. pi

w4m using recent trunk bits.