95654 - caret appears misplaced with respect to <HR> when I hit BACKSPACE

Status: VERIFIED FIXED

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

Description

[shrirang khanzode]

win nt trunk 0815

add a hr , hit ENTER , HIT BACKSPACE once ..observe the caret position, it's top 
is almost in line with the <HR>, you have to hit backspace once more to get it 
in the correct position.

Comment 1

[rubydoo123]

g

Comment 2

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 3

[Charles Manske]

I can't reproduce this, but I have the fix to bug 159207 in my tree. I think
these recent changes by mjudge will fix this too. Please test after fix for
159207 is checked in.

Comment 4

[mjudge]

the selection code is working fine.  the only problem is that when you are
hitting return you get 2 BRs  one after the HR then another on next line.  since
the HR forces a newline you actually have 3 .  first is the HR second is the
first BR and the third is caused by the second BR.  I will give this to jfrancis
to let him decide if this rule decision is a bug.  

Comment 5

[Joe Francis]

probably very simple...

Comment 6

[Syd Logan]

EDITORBASE+ per editorbase triage

Comment 7

[Joe Francis]

Attachment: patch to nsHTMLEditRules.cpp

hey, it helps to attach the patch if I want reviews, doesn't it?

This patch changes the WillInsertBreak() code to see if we are right after a
block (note that HR's count as blocks for this purpose).  If we are than
instead of putting selection after the inserted br, it puts it before.

You could get the same bug as originally described using a table instead of an
hr, for instance.  it's just harder to do the test case.  I had to edit source
to make it happen.  Anyway, this patch fixes it for HRs, Tables, etc...

The last diff in the patch is just a correction of some stale comments.  It's
unrelated to the bug.

Comment 8

[Joe Francis]

just to clarify, placing the selection before the inserted br prevents the
postprocessing code from inserting the second br.  Thus the extra br Mike
mentions no longer occurs after this patch.

Also, for QA:
This bug has morphed from the original report.  now the test case is:
1) insert HR
2) hit enter
result: you are two lines below the HR
expected result: you are one line below the HR

Comment 9

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

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

yep... r=glazman

Comment 10

[kinmoz]

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

sr=[e-mail]

Comment 11

[Joe Francis]

fix landed on trunk

Comment 12

[sujay]

verified according to Joe's new testcase...however now I see a new
problem:

1) insert HR
2) hit enter
3) hit backspace

the HR disappears! shouldn't the caret be at the end of the HR ?
new bug report filed for this: bug 169213