Start the editor either thru -edit or with the tasks menu. before doing anything else, hit the "H Line" button to insert a horizontal line. Wow, look at the size of that caret! June 26 build.

assigned to simon. Consider the case when the selection can't be text, like when the document contains only HRs and images: what's our plan?

The insert HR transaction needs to set the selection properly after inserting the HR.

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

There is no "insert HR transaction". I'm using nsEditor::InsertNode, which uses the transaction system. Shouldn't it manage the selection properly?

Simon fixed this problem for most cases, but there's still a problem when the element inserted is at the end of a paragraph. In that case we stil get the big caret, probably because there is no "next sibling" of the newly-inserted element. Simon: maybe you should search for a textnode previous to the inserted element if their is no node at the selection anchor=node+offset? I'll let Simon sort this out.

I believe this is a similar problem to that described in bug 10683.

M10

M11

I'm not entirely sure that this is a caret issue, since typing in that situation behaves oddly too (more vertical space suddenly shows up). Behaviour also depends on what was split to make the <hr>. This seems related to the end-of-doc case. Since it looks more like a typing issue, I'm giving it to joe. If you disagree, joe, please bounce it back.

M12, dude.

I love it... m9, to m10, to m11, to m12.

This bug is mostly fixed. There are still cases, I think, where you can get the uber caret. But they are a lot rarer now and I would prefer to close this bug and open new ones against specific remaining scenarios that cause trouble. Note that there is a seperate bug (20106) about the caret disappearing. That bug may make it difficult for you to verify this one.

verified in 11/29 build.