28724 - return causes caret problems in Mail replies (not moving to next line)

Status: VERIFIED FIXED

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

Description

[bijals (gone)]

Steps:
1) Open a blank document
2) Type "asdf"
3) Hit return

Actual Results: Caret appears two lines below, but when you type "asdf" again it 
appears on the line above where it is supposed.

Expected Results: Caret appears only one line down and where you type

Build Date/Platform: 2/21/00-08 on NT

Comment 1

[bijals (gone)]

Appears in Mail compose, especially when replying to an email message.  This 
will be a high frequency.  Please stop by to see this problem.

Comment 2

[bijals (gone)]

Again, please focus on the Mail incarnation of this problem which occurs while 
replying to a message:

Hit return on first line and caret does not move to the next line.  You also 
have the caret sometimes show up two lines below, but typing occurs on the 
middle line.

Comment 3

[bijals (gone)]

Changed summary to reflect the bug more accurately.

Comment 4

[Kathleen :Brade]

M14; reassign to jfrancis

Comment 5

[Kathleen :Brade]

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

Comment 6

[Joe Francis]

accepting bug

Comment 7

[leger]

Putting on PDT- radar for dogfood and beta1.  Will not hold for this one.

Comment 8

[bijals (gone)]

This occurs about 60% or more of the times I try to reply to an email in 
Seamonkey Mail.  Basically, hit REPLY all and in the new message type something 
"asdf" and hit return.  Caret does not move to the next line at times or it 
moves two lines down.  Can you show you this today.

Comment 9

[sujay]

adding EB in status summary...ender blocker

Comment 10

[Joe Francis]

This bug actually can happen in a wide variety of circumstances, on both 
plaintext and html editors (including html form text widgets).  Mike has extended 
the selection api's to allow me to get better control of where the caret actually 
ends up.  

I have made use of this new functionality in the editor, and we've seen a lot of 
improvement in the consistency and correctness of the caret location.  So far 
Akkana and I have tested these changes, and will continue to test them tonight 
and tomorrow.

The cool thing about the work on this is that it is unlikely to cause big 
regressions.  Even if I screwed it up, the likely result would just be a bad 
location for the caret in some circumstance.

If PDT wants this in beta1, we are pretty much ready to go (some more hours of 
testing is the extent of my recommendation).

Nominating for PDT+ consideration (removed PDT- from status).

Comment 11

[bijals (gone)]

To analyze this bug we need the following information:

1) Risk associated with check in (need more info from Joe)
a) # of lines of codes added and changed
b) Platforms on which this fix was tested
c) 1 day (based on Joe's earlier comments)

2) Frequency of Bug: High - Mail compose, IM compose, Composer, and plain text
editing

3) Negative impact from bug: Medium - Makes typing frustrating

Comment 12

[Joe Francis]

It has been tested on all three platforms.  

as for how much changed, there were Mike's changes to nsRangeList.cpp in layout:

NS_IMETHODIMP
nsDOMSelection::SetHint(PRBool aHintRight)
{
  return mRangeList->SetHint(aHintRight);
}

NS_IMETHODIMP
nsDOMSelection::GetHint(PRBool *aHintRight)
{
  return mRangeList->GetHint(aHintRight);
}

Then these changes had to be perculated through various dom headers and 
javascript cruft, plus the nsIDOMSelection.h interface (all of these changes were 
trivial).

Then there are my changes in the editor, which amount to about 30 new lines of 
code scattered through nsHTMLEditor, nsTextEditRules.cpp, and 
nsHTMLEditRules.cpp, which make use of the new SetHint() functionality.

So a fair number of files were touched, but altogether < 50 lines of new code.  

Comment 13

[Joe Francis]

fixed

Comment 14

[bijals (gone)]

Analysis on bug:

1) Risk associated with check in (need more info from Joe)
a) < 50 lines of code
b) Tested on all 3 platforms
c) 2 day

2) Frequency of Bug: High - Mail compose, IM compose, Composer, and plain text
editing

3) Negative impact from bug: Medium - Makes typing frustrating

Comment 15

[sujay]

verified in composer using 2/25 builds...Bijal, please verify in mail
compose..thanks!

Comment 16

[sujay]

verified in composer using 2/25 builds...Bijal, please verify in mail
compose..thanks!

Comment 17

[bijals (gone)]

Excellent! Verified in Seamonkey Mail compose window when replying to an email
message.

Comment 18

[sujay]

verified per bijal's comments...in 2/25 build.

Comment 19

[BMO Automation]

Attachment: [mozilla-mobile/fenix] Update initial experiments JSON for Nimbus (backport #28724) (#28733)