Bug 23474 - In a designMode document, the cursor can't be moved after the last BR node if there is no text following it
Summary: In a designMode document, the cursor can't be moved after the last BR node if...
Status: VERIFIED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 525.x (Safari 3.2)
Hardware: PC Windows XP
: P3 Minor
Assignee: Nobody
URL: http://marijn.haverbeke.nl/codemirror...
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-22 03:53 PST by Marijn Haverbeke
Modified: 2010-11-08 23:35 PST (History)
10 users (show)

See Also:


Attachments
Simplified CodeMirror test case (752 bytes, text/html)
2010-05-26 19:26 PDT, Jacob Lee
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marijn Haverbeke 2009-01-22 03:53:07 PST
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.
Comment 1 Jacob Lee 2010-05-26 19:26:19 PDT
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.
Comment 2 Ojan Vafai 2010-05-27 06:51:51 PDT
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?
Comment 3 Marijn Haverbeke 2010-08-18 04:28:37 PDT
> 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.
Comment 4 Marijn Haverbeke 2010-08-18 04:39:48 PDT
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.
Comment 5 Ojan Vafai 2010-08-18 10:01:51 PDT
(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.
Comment 6 Ryosuke Niwa 2010-11-03 16:36:31 PDT
*** Bug 47806 has been marked as a duplicate of this bug. ***
Comment 7 Levi Weintraub 2010-11-08 11:10:02 PST
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.
Comment 8 Marijn Haverbeke 2010-11-08 12:00:30 PST
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.
Comment 9 Ryosuke Niwa 2010-11-08 12:10:22 PST
(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.
Comment 10 Marijn Haverbeke 2010-11-08 13:02:16 PST
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.
Comment 11 Ryosuke Niwa 2010-11-08 15:57:39 PST
(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.
Comment 12 Marijn Haverbeke 2010-11-08 23:35:27 PST
> 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.