174017 - Multiple enters after quoted text does not move cursor HTM editor only

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect)

Description

[Pratik]

Build - 2002100804/Win2K

1. Reply to a message with some body (HTML mode reply)
2. Go somewhere in the middle of the quoted text.
3. Press enter multiple times

Actual Result: The enter causes the text below to be shifted down but the cursor
stays where it is.

Expected Result: Cursor should move down on pressing enter.

I searched through bugzilla and couldn't find this bug. I've been seeing this
for a few days now.

Comment 1

[Pratik]

Bug is also present in 2002101108 build. Interestingly, if after pressing all
the enters, you start pressing backspace, then it deletes all the enters and
brings the quoted text up. Backspace reverses what enter did instead of doing
what its supposed to do.

Comment 2

[Jean-Francois Ducarroz]

seems related to bug 173818. Reassign to jfrancis

Comment 3

[Pratik]

Not sure if its related to bug 173818 since this happens on both Linux and
Windows and bug 173818 doesn't occur on Linux.

Comment 4

[Peter Lairo]

This is a serious usability issue, particularly for regular (novice) users -> 1.2

Comment 5

[Joe Francis]

please retest with latest builds, this is a WFM so far.

Comment 6

[Pratik]

I still see the bug in Build 2002101508/Win2k. I'll check on linux tomorrow.

Comment 7

[Peter Lairo]

Please reopen this bug. I still see it in Build:
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2b) Gecko/20021014

Comment 8

[Pratik]

Reopening. I still see the bug on build 2002101605/Linux. Can other people
confirm/deny this on recent nightlies?

Comment 9

[Pratik]

I just noticed that I see this bug only with the HTML compose window; its not
present in plain-text compose.

Comment 10

[Felix Miata]

Text compose WFM in OS/2 trunk 2002101509.

Comment 11

[Joe Francis]

ok, i see it in today's build.

Comment 12

[Peter Lairo]

This bug seems to only happen in *HTML* compose, not in *text* compose.

I therefore suggest you edit the subject line to mention "HTML compose only".
We've wasted enough time boucing back and forth between "WFM" and "still broken".

And what is Target Milestone: "M3"? Also, Let's please get some keywords in here.

Comment 13

[Peter Lairo]

This regression bug is highly visible and makes mozilla behave "oddly" for
anyone using Mail/News. 

REQUESTED KEYWORDS: nsbeta1, nscatfood, mozilla1.2, mozilla1.0.2, regression, 4xp

Comment 14

[Joe Francis]

component change

Comment 15

[Joe Francis]

nominating for EB+ since this is a high profile regression.

Comment 16

[Joe Francis]

Attachment: patch to nsHTMLEditRules.cpp

Tweaks to logic for placing br's after block boundaries fixes this problem.

Comment 17

[kinmoz]

Comment on attachment 105075 [details] [diff] [review]
patch to nsHTMLEditRules.cpp

sr=[e-mail]

Comment 18

[Joe Francis]

fix landed on trunk

Comment 19

[esther]

I still see the problem as originally stated in HTML compose in the 11-19 trunk
builds on linux, macosx and winxp.  Note editing the summary to state HTML
compose only as suggested in comment 12  reopening. 

Comment 20

[Kathleen :Brade]

EB+ per meeting

Comment 21

[Joe Francis]

I merged in the wrong direction when landing a later fix, accidentally removing
this patch.  I'll re-land this when tree opens.

Comment 22

[Joe Francis]

relanded fix.  sorry for mixup.

Comment 23

[sairuh (rarely reading bugmail)]

vrfy'd fixed with 2003.02.19.