Bug 23474 – In a designMode document, the cursor can't be moved after the last BR node if there is no text following it

• Component: HTML Editing
• Status: VERIFIED WONTFIX

[Marijn Haverbeke]

If an editable document ends in a BR node (with any amount of non-displaying nodes behind it), the cursor behaves as if the line before that BR node is the last line of the document. Other browsers allow one to move the cursor to the blank line at the end.

To reproduce, see the CodeMirror editor, which rebinds the enter key to just insert a BR node and move the cursor after it. On load (see URL) the document ends in a BR, but the cursor can't be moved to the blank line. When pressing enter, typing something, and then pressing enter again, nothing seems to happen, since the newly inserted BR creates the above situation, and the newly created line is inaccessible.

[Jacob Lee]

Created attachment 57188 [details]
Simplified CodeMirror test case

CodeMirror has long since worked around this bug. The workaround causes other problems, though, so it would be much better if the cursor behavior were fixed.

This bug also affects Google Apps Script, the editor for which is CodeMirror.

[Ojan Vafai]

To be clear, in that test case:
1. Put the cursor after Foo.
2. Hit enter.

A BR gets inserted, but the cursor doesn't move down. I'm not sure how fixable this is. The problem is that the line after the BR is not rendered because that's just how HTML rendering works. I don't think we could add a contentEditable quirk to render that line because it would break other cases. 

IE actually renders the new line in this case, so it doesn't have this problem.

Weirdly, Firefox does let you put the cursor there, but it doesn't render the line and it's in this sort of half-line position. Not sure if that's more or less broken.

Is it not enough of a workaround for codemirror to always ensure there's an extra BR at the end of the contentEditable element?

[Marijn Haverbeke]

> Is it not enough of a workaround for codemirror to always ensure there's an extra BR at the end of the contentEditable element?

Not really. The state of the DOM tree is treated as the authoritative content of the editor by CodeMirror, and having stray cruft in there would require a lot of work-arounds.

[Marijn Haverbeke]

I should add that BR's inserted with execCommand("insertLineBreak") do not suffer from this problem, though they are not different in any visible way. If someone can hint me at a hack, no matter how dodgy, that would allow me to switch any BR into 'non-ignored' mode, that would already be hugely helpful.

[Ojan Vafai]

(In reply to comment #4)
> I should add that BR's inserted with execCommand("insertLineBreak") do not suffer from this problem, though they are not different in any visible way. If someone can hint me at a hack, no matter how dodgy, that would allow me to switch any BR into 'non-ignored' mode, that would already be hugely helpful.

execCommand("insertLineBreak") inserts two BRs in this case.

[Ryosuke Niwa]

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

[Levi Weintraub]

I feel that supporting this would be a hack. Editing is doing the proper thing and inserting the <br> as expected. It's a conscious layout decision to then collapse that <br>, and changing that layout strategy would cause all sorts of problems. Instead to support this, editing would have to be hacked to treat a single inserted <br> that is otherwise collapsed differently.

[Marijn Haverbeke]

When you say 'editing', do you mean the script that's initializing designmode, or another webkit component? In the first case, I don't see how the script can cause the BR to behave differently. In the second case, this bug should not be closed, but moved to the right component. The BR is part of the editable document, and should be treated as such.

[Ryosuke Niwa]

(In reply to comment #8)
> When you say 'editing', do you mean the script that's initializing designmode, or another webkit component? In the first case, I don't see how the script can cause the BR to behave differently. In the second case, this bug should not be closed, but moved to the right component. The BR is part of the editable document, and should be treated as such.

Editing is the WebKit component to which this bug belongs.  I agree with Levi.  In WebKit, we don't render the very last BR that isn't followed by any content for compatibility reason regardless of whether we're in editable region or not.  The correct fix is for the script to insert two BRs at the end.

[Marijn Haverbeke]

However, no other browser hides this trailing BR, and it'd require weird, webkit-specific code to drop it from the document 'as the user sees it', which, in CodeMirror, is not just the saving/exporting of the content, but also iterating over the lines, keeping an undo history (I recently had to fix two bug related to this magic BR and the undo history) and several other pieces of functionality.

In short, it's your rendering engine, so you have the last word, but you're really making things difficult for client code with this behaviour.

[Ryosuke Niwa]

(In reply to comment #10)
> However, no other browser hides this trailing BR, and it'd require weird, webkit-specific code to drop it from the document 'as the user sees it', which, in CodeMirror, is not just the saving/exporting of the content, but also iterating over the lines, keeping an undo history (I recently had to fix two bug related to this magic BR and the undo history) and several other pieces of functionality.

Firefox does hide BR.

> In short, it's your rendering engine, so you have the last word, but you're really making things difficult for client code with this behaviour.

How about execCommand('InsertLineBreak')?  It does the right thing.

[Marijn Haverbeke]

> Firefox does hide BR.

Nope, FF works as expected, and allows the user to place his caret after the last BR.

> How about execCommand('InsertLineBreak')?  It does the right thing.

As I said before, I don't want to have an extra BR in my DOM.