caret on wrong line after pressing return

RESOLVED DUPLICATE of bug 1263357

Status

()

Core
Editor
RESOLVED DUPLICATE of bug 1263357
15 years ago
2 years ago

People

(Reporter: Ramūnas Lukaševičius, Unassigned)

Tracking

({regression, testcase})

Trunk
mozilla1.6alpha
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: editorbase+)

Attachments

(2 attachments)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212

when I type text in the new composer window, then select some text and mark
bold. After that I place cursor after last marked bold symbol and press ENTER.
After that, cursor stays at the line end and not moves to the next line beginning.

Reproducible: Sometimes

Steps to Reproduce:
1. type this text in new composer window: "foo.boo"
2. select "foo."
3. make selected text bold
4. place cursor between "." and "b": foo.<cursor>boo
5. press ENTER

Actual Results:  
Cursor stays at the first line end.

Expected Results:  
Cursor should move to the second line beginning.

I can reproduce this problem not always, but very often.

Comment 1

15 years ago
-->core
Assignee: composer → jfrancis
Status: UNCONFIRMED → NEW
Component: Editor: Composer → Editor: Core
Ever confirmed: true
Keywords: nsbeta1, regression
OS: Linux → All
Hardware: PC → All
Summary: wrong cursor position → caret on wrong line after pressing return
Whiteboard: editorbase

Comment 2

15 years ago
EDITORBASE+
QA Contact: sujay → beppe
Whiteboard: editorbase → editorbase+
nsbeta1+
Keywords: nsbeta1 → nsbeta1+

Updated

15 years ago
Target Milestone: --- → mozilla1.6alpha
Kaie can you take a look?
Assignee: jfrancis → kaie

Comment 5

15 years ago
This bug can be seen in Mozilla 1.2.1.

However, Mozilla 1.3.1, Mozilla on the 1.4 branch, and Mozilla trunk all work
correctly for me.

Marking WORKSFORME as this bug has already been fixed by some other work.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME

Comment 6

15 years ago
I can reproduce this easily on the trunk build from today. Try this -
after you type in foo.boo and make foo. bold, set the caret at the end of foo,
arrow over (and here is the trick, watch the status line) you want the caret to
land after the period, but still within the bold tag. It's at that point between
the period and the end bold tag where the issue is surfaced.

<b>foo.^</b>boo

where ^ is where the caret should be

if the caret is outside the bold tag, it works correctly.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 7

15 years ago
Ok, now I see it. Thanks for the additional description.

The trick is to use the arrow keys.

(It works correctly when using the mouse to place the cursor between foo. and
boo, that's what I was doing)
Status: REOPENED → ASSIGNED

Comment 8

15 years ago
This bug is in 1.0, 1.2, 1.4, latest trunk.

If we have
  <span style="font-weight: bold;">X</span>Y
or
  <b>X</b>Y
the bug only occurrs when arrowing from left to right.
(I see the bug with botb <b> or span with style.

If you place the caret at
  |xy
and arrow right once, and hit enter, we see the bug.

If you place the caret at
  xy|
arrow left once, and hit enter, the caret is moved down correctly.

Although arrowing from left or right both arrives at the same position with
regards to characters, there is a difference, visible in the status bar. When
starting left going right, we are still in the bold element. When starting right
moving left, we have not yet arrived in the bold element.

Comment 9

15 years ago
It's not likely that I will work on editor/selection bugs in the near future.
Mass assining my bugs to nobody.

Assignee: kaie → nobody
Status: ASSIGNED → NEW

Comment 10

15 years ago
snarfing kaie's old bugs
Assignee: nobody → mozeditor

Comment 11

15 years ago
snarfing kaie's old bugs
Here's my analysis of the problem:

We have the following content: <b>foo<br/></b>bar

Now we want to position the caret so that it is:
1. After the <br/>, i.e. on the second line.
2. But still inside the <b> element.

The problem is that currently there is no frame that satisfies these demands. 
The inline frame (representing the <b> element) has no continuation frame - so
there's no frame on the second line associated with the <b> element.

It seems that the only solution would be to change reflow so that if the last
child of an InlineFrame is a BRFrame, an empty continuation frame will be
created for it. Then we can position the caret in that frame.

Does this make sense?
That could easily mess up the calculation of the height of the second line,
although arguably that line-height *should* depend on the <b> span... CCing
dbaron for comment.
QA Contact: rubydoo123 → editor
Assignee: mozeditor → nobody

Updated

8 years ago
Depends on: 389321
Keywords: testcase

Comment 15

7 years ago
This happens because a <br> node is injected in the document, and pressing Enter removes it.  It doesn't have anything to do with bug 389321.
No longer depends on: 389321
Created attachment 8734400 [details]
TestCase Bold.html

Firefox: 45.0.1, Build ID: 20160315153207
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0

Hi Reporter,

I have tested this issue on the latest Firefox (45.0.1) release, latest Nightly (48.a01 - Build ID: 20160323030400) build. I have changed the provided test case from comment 14 and now I can reproduce this issue. 
STR:
1. Open the test case "TestCase Bold.html".
2. Move cursor between "d" and "t" (between bold HTML element and body element).
3. Press enter.
The cursor remain at the end of the first line.

Thanks,
Cosmin.
Duping to more recent bug with more discussion.
Status: NEW → RESOLVED
Last Resolved: 15 years ago2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1263357
You need to log in before you can comment on or make changes to this bug.