Closed Bug 102819 Opened 23 years ago Closed 23 years ago

Enter key at the end of line inserts two newlines

Categories

(Core :: DOM: Editor, defect)

Product:
Core
Component:
DOM: Editor
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.1alpha

People

(Reporter: kazhik, Assigned: mozeditor)

References

Details

(Whiteboard: EDITORBASE+; fixinhand; need r=,sr=; patch in 83378 [adt2])

Attachments

(1 file, 5 obsolete files)

patch for nsHTMLEditRules.cpp
1.72 KB, patch
Details | Diff | Splinter Review
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
QA Contact: sheelar → esther
Target Milestone: --- → mozilla1.0.1
Blocks: 108194
*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
Keywords: mozilla1.0
Target Milestone: mozilla1.0.1 → mozilla1.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
Assignee: ducarroz → kin
Component: Composition → Editor: Core
Keywords: mailtrack
Product: MailNews → Browser
QA Contact: esther → sujay
Marking as duplicate of 102842; please un-dup if you disagree. *** This bug has been marked as a duplicate of 102842 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
verified.
bug 012842 was marked as FIXED, but I can reproduce this bug with 2002020611/Linux. Reopening. I can reproduce the similar bug 58960.
Status: VERIFIED → REOPENED
OS: Windows 2000 → All
Resolution: DUPLICATE → ---
*** Bug 106225 has been marked as a duplicate of this bug. ***
Moving to Moz1.1
Target Milestone: mozilla1.0 → mozilla1.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.
Attached patch a patch (obsolete) — — Splinter Review
I got it. There is a silly mistake in nsHTMLEditor.cpp. Try this patch.
Attached patch true patch (obsolete) — — Splinter Review
Sorry, I mistook, too... Try newer one.
Attachment #69852 - Attachment is obsolete: true
Attached patch a patch with one more fix (obsolete) — — Splinter Review
I added one more fix of the same mistake on that file. (Thanks, Kazuhiko.)
Attachment #69855 - Attachment is obsolete: true
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.
Attachment #69902 - Flags: needs-work+
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.
Status: REOPENED → ASSIGNED
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.
Attached patch a patch with replaces only (obsolete) — — Splinter Review
Attachment #69902 - Attachment is obsolete: true
*** 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
Attachment #73156 - Flags: review+
*** 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?
Attachment #73156 - Flags: superreview+
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
Attachment #73156 - Flags: approval+
Keywords: mozilla1.0 → mozilla1.0+
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...
Attachment #73156 - Attachment is obsolete: true
*** 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.
Attachment #77587 - Attachment is obsolete: true
Whiteboard: EDITORBASE; fixinhand; need r=,sr=
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
Assignee: kin → jfrancis
Status: ASSIGNED → NEW
Depends on: 83378
Whiteboard: EDITORBASE; fixinhand; need r=,sr= → EDITORBASE+; fixinhand; need r=,sr=
Keywords: nsbeta1+
Status: NEW → ASSIGNED
Whiteboard: EDITORBASE+; fixinhand; need r=,sr= → EDITORBASE+; fixinhand; need r=,sr=; patch in 83378
Whiteboard: EDITORBASE+; fixinhand; need r=,sr=; patch in 83378 → EDITORBASE+; fixinhand; need r=,sr=; patch in 83378 [adt2]
83378 has landed on trunk.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
nsbeta1-. The fix is too risky for the 1.0 branch.
Keywords: nsbeta1+ → nsbeta1-
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a+) Gecko/20020701 Now it WFM. pi
QA Contact: sujay → sairuh
w4m using recent trunk bits.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: