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.

-->core

EDITORBASE+

nsbeta1+

Kaie can you take a look?

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.

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.

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)

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.

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

snarfing kaie's old bugs

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.

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.

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.