103888 - Text on line below gets deleted when a style change for a lower line is made on the line above

Status: VERIFIED FIXED

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

Description

[TucsonTester2]

Build ID: 20011004

Composer does not properly backspace lines that had there styles changed on a
previous line.

Reproducible: Always

Steps to Reproduce:
1.Open Composer
2.Type some text
3.Click on the bold button on the toolbar
4.Hit enter and type some text
5.Place the cursor at right end of the first line
6.Hit backspace

Actual Results:
The text on the line below gets deleted instead of the text on the line below.

Expected Results:
I would expect that the line I place the cursor on would be deleted.

Comment 1

[TucsonTester2]

This bug only occurs if you place the cursor (step 5) by using a mouse click. 
If you move the cursor using the error keys instead, then backspacing works
correctly.

Also the problem isn't backspacing only.  In step 6, if you hit the enter key
instead of hitting backspace, then instead of adding a blank line between the
two lines of text you have already entered, the cursor will move to the line
below the second line of text.  If, in step 6, you type some text instead of
hitting backspace or enter, the text will be added to the end of the second line
instead of to the end of the first line.

Steps to Reproduce:
1.Open Composer
2.Type some text
3.Click on the bold button on the toolbar
4.Hit enter and type some text
5.Click at the end of the first line so the cursor is there
6.Enter text

Actual result:  Text will be added to the end of the second line
Expected result:  Text should have been entered at end of first line.


Basically, when you click at the end of the first line, it places the cursor
correctly, but any action you take will be treated as if it is at the end of the
second line (at the end of the formatting that was set in step 3).  But this
only happens when using a mouse click to place the cursor at the end of the
first line, and only if the first line ends with a tag for a format change
(bold, italic, underline, big text, small text, etc).

Comment 2

[Syd Logan]

Nice edge case. EDITORBASE, assigning to mjudge.

Comment 3

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 4

[Toylet]

the bug has been here since 0.9.4....

Comment 5

[TucsonTester1]

In build 2001121003 this is still an issue. Also notice that when you hit "
enter " after changing the text style, the caret jumps to the beginning of the
first line of text.  

Comment 6

[anthonyd]

recommend on EDITORBASE- since this will include some layout hacking tog et the 
correct keyboard navigation around css remenants working.

Comment 7

[Kevin McCluskey (gone)]

Making EDITORBASE+. Simple, common action results in unexpected behavior.

Comment 8

[mjudge]

Attachment: small fix to fix big problem in nsFrame.cpp

this will disable the "helpful" adjustment of selection when a point is outside
of the frames area.  in the past we would set the content offset of the frames
content to '+1' when the point is "right" of the frames rectangle.  This causes
problems in splittable frames when the first frame is 0 width.	this simply
defaults to <parent content>,(frame content'soffset) rather than adding 1 to
the offset since the point is to the left of the frame's rectangle.

Comment 9

[mjudge]

Attachment: added comment to patch.

added comment to refer to this bug and to explain that we mean to not skip past
content offsets that have frames with no size.

Comment 10

[mjudge]

Comment on attachment 77933 [details] [diff] [review]
added comment to patch.

jfrancis has reviewd it. he told me to put his review marker on it.

Comment 11

[kinmoz]

Comment on attachment 77933 [details] [diff] [review]
added comment to patch.

sr=[e-mail]

Comment 12

[Asa Dotzler [:asa]]

Comment on attachment 77933 [details] [diff] [review]
added comment to patch.

a=asa (on behalf of drivers) for checkin to the 1.0 branch

Comment 13

[scottputterman]

adding adt1.0.0 nomination

Comment 14

[Jaime Rodriguez, Jr.]

Pls check this into the trunk for a couple of days, and have QA verify that the
patch resolves the issue, and does not cause any regression.

Comment 15

[Jaime Rodriguez, Jr.]

sujay - any word on the verification for this one? were there any regressions
introduced?

Comment 16

[sujay]

I cannot verify this until one of two things happens:

1) Mike checks it into the trunk
2) Mike gives me an optimized build with this patch

Comment 17

[mjudge]

this was checked into trunk today check it out.

Comment 18

[Michael Buckland]

adt requests you test bug on trunk and update bug with results.  Thanks!

Comment 19

[sujay]

verified fix on 4/18 trunk. looks good. problem is gone now.

Comment 20

[Jaime Rodriguez, Jr.]

adt1.0.0+ (on ADT's behalf) approval for checkin to the 1.0 branch. Pls check
this into the 1.0 branch asap, then add the keyword fixed1.0.0. thanks for you
patience mike!

Comment 21

[mjudge]

changing to fixed branch as well as trunk

Comment 22

[Jaime Rodriguez, Jr.]

If this is truly fixed on the branch, pls add the keyword fixed1.0.0.

Comment 23

[sujay]

verified on 4/19 branch also. 

However, I discovered a bug during additional testing this time.

There is a problem after step 2) . If you enter a space after the text then
there is no problem, but if you don't enter a space.
then when you hit return, the caret jumps to the beginning
of the first line.

Should I reopen this bug ? or file a new one?

Comment 24

[sujay]

actually the problem occurs regardless if you enter a space or not.

filed bug 138608 on new issue.

marking this bug verified because the new problem does not
stop me from verifying this fix. the workaround is to just
keep typing and the caret jumps to the correct position.