98609 - return not advancing caret to newline sometimes.

Status: VERIFIED DUPLICATE of bug 152419

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

Description

[sujay]

email from Bij:

Okay, here is one bug I am not sure who it would go to.  I get it here and
there, 
but below is one way to reproduce it.  However, that's not how I usually run
into 
it. 

Steps: 
1) Open a blank document 
2) Click the horizontal line as the first item in the document 
3) Hit return 
4) Create a bullet and type the text "Hello" 
5) Put the caret in front of the horizontal line (left side) 
6) Hit tab to go to the end of the horizontal line (right side) 
7) Hit return 
8) Delete the new line 
9) Put the caret in the front of the horizontal line (left side) 
10) Hit tab to go to the end of the horizontal line (right side) 
11) Hit return 

Actual Results: Caret stays on the right side of the horizontal line with a 
decreased vertical size, but no new line created. 

Expected Results: Caret is on new line. 

Build Date/Platform: Win NT using 2001011004 build 

Thanks, Bij



------- Additional Comments From [e-mail] 2001-01-19 23:44 -------

marking future for now but hoping to fix for moz0.9



------- Additional Comments From [e-mail] 2001-02-12 14:12 -------

is this the same as #67838?



------- Additional Comments From [e-mail] 2001-05-04 09:11 -------

we need to reduce to simple test case.



------- Additional Comments From [e-mail] 2001-06-25 15:27 -------

adding QAHP

Comment 1

[sujay]

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

Comment 2

[sujay]

lemme see if I can get a reduce test case.

Comment 3

[sujay]

I'm following Bijal's steps and I don't understand step 6).
How can you hit tab to go to the end of the Hrule when your caret
is in front of the Hrule?

Comment 4

[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 5

[Joe Francis]

The directions are not right: tab does notmove the cursor, it inserts
whitespace.  If I use right arrow where he says tab, then I cannot reproduce
this bug.

Comment 6

[Syd Logan]

steps for reproducing seem unlikely for most users, minusing

Comment 7

[jhp (no longer active)]

Here is a simpler testcase, taken from bug 127939:

1) Open blank page in Editor.
2) Select Debug->Insert Text.
3) Double click "those" to highlight, and then choose to underline
4) Double click "who" to highlight.
5) Press 'Enter' key

The text after the word "who" goes to the next line, but the caret remains at
the end of the first line.

Comment 8

[sujay]

removing minus...we have a better testcase...one that users might run into.

Comment 9

[Joe Francis]

I believe the comment #7 test case is already fixed.  I don't understnad the
comment #1 testcase.

Comment 10

[sujay]

Javier, Joe is saying that your testcase is fixed...can you please
try again in later build ?

also state your expected results...

Comment 11

[jhp (no longer active)]

On build 2002031403 Win32, the testcase in comment #7 still fails.
Expected Result:  Pressing Enter erases "who" and moves both caret and "wait."
to the following line.
Actual Results:  Pressing Enter erases "who" and moves "wait." to the following
line, but the caret remains at the end of original line.

Comment 12

[Joe Francis]

I'm full of crap.  I was remembering a different bug where there was an extra 
blank line caused.  

Comment 13

[Syd Logan]

In most cases, clicking around and hitting return works, just in this case we
had to involve selection, and their had to be stuff following it on the line. We
consider this less critical than anything else on the EDITORBASE list.

Comment 14

[Joe Francis]

The trunk is the wave of the future!

Comment 15

[Joe Francis]

The days of having a half dozen milestones out in front of us to divide bugs 
between seem to be gone, though I dont know why.  Lumping everything together as 
far out as I can.  I'll pull back things that I am working on as I go.

Comment 16

[Charles Manske]

Kindof a weird test case! (comment #7)

Comment 17

[Charles Manske]

The key thing seems to be that the selection must touch text that has any 
inline attribute on the left before hitting enter.

Comment 18

[Joe Francis]

This is a dup of 152419.  It might not be obvious from looking at it, but the 
common feature between these two bugs is that you end up with a <br> just before 
the close of an inline style tag.  That's what drives the caret problems.


*** This bug has been marked as a duplicate of 152419 ***

Comment 19

[sujay]

verified.