23474 2009-01-22 03:53:07 -0800 In a designMode document, the cursor can't be moved after the last BR node if there is no text following it 2022-05-12 12:02:23 -0700 1 1 1 Unclassified WebKit HTML Editing 525.x (Safari 3.2) PC Windows XP VERIFIED WONTFIX http://marijn.haverbeke.nl/codemirror/jstest.html P3 Minor --- 0 marijnh+webkit webkit-unassigned almaza24map ap barbiecarrington01 brantfordhousecleaning enrica jacobly jen123cruz123 jparent lweintraub morrita ojan rniwa rolandsteiner tamuccuser tony wdm oldest_to_newest 106589 0 marijnh+webkit 2009-01-22 03:53:07 -0800 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. 231045 1 57188 jacobly 2010-05-26 19:26:19 -0700 Created attachment 57188 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. 231276 2 ojan 2010-05-27 06:51:51 -0700 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? 266040 3 marijnh+webkit 2010-08-18 04:28:37 -0700 > 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. 266042 4 marijnh+webkit 2010-08-18 04:39:48 -0700 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. 266182 5 ojan 2010-08-18 10:01:51 -0700 (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. 304348 6 rniwa 2010-11-03 16:36:31 -0700 *** Bug 47806 has been marked as a duplicate of this bug. *** 306227 7 lweintraub 2010-11-08 11:10:02 -0800 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. 306266 8 marijnh+webkit 2010-11-08 12:00:30 -0800 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. 306278 9 rniwa 2010-11-08 12:10:22 -0800 (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. 306306 10 marijnh+webkit 2010-11-08 13:02:16 -0800 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. 306425 11 rniwa 2010-11-08 15:57:39 -0800 (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. 306629 12 marijnh+webkit 2010-11-08 23:35:27 -0800 > 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. 57188 2010-05-26 19:26:19 -0700 2010-05-26 19:26:19 -0700 Simplified CodeMirror test case inner.html text/html 752 jacobly PCFET0NUWVBFIEhUTUw+CjxodG1sPgogIDxoZWFkPgogICAgPHNjcmlwdD4KCmZ1bmN0aW9uIGlu c2VydE5ld2xpbmUoKSB7CiAgdmFyIHRvSW5zZXJ0ID0gZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgi QlIiKTsKICB2YXIgc2VsID0gd2luZG93LmdldFNlbGVjdGlvbigpOwogIHZhciByYW5nZSA9IHNl bC5nZXRSYW5nZUF0KDApOwogIHJhbmdlLmRlbGV0ZUNvbnRlbnRzKCk7CiAgcmFuZ2UuaW5zZXJ0 Tm9kZSh0b0luc2VydCk7CgogIC8vIE1vdmUgdGhlIGN1cnNvciB0byBhZnRlciB0aGUgaW5zZXJ0 ZWQgbm9kZS4KICB2YXIgbmV3UmFuZ2UgPSBkb2N1bWVudC5jcmVhdGVSYW5nZSgpOwogIG5ld1Jh bmdlLnNlbGVjdE5vZGUodG9JbnNlcnQpOwogIG5ld1JhbmdlLmNvbGxhcHNlKGZhbHNlKTsKICBz ZWwucmVtb3ZlQWxsUmFuZ2VzKCk7CiAgc2VsLmFkZFJhbmdlKG5ld1JhbmdlKTsKfQoKZnVuY3Rp b24gZ28oKSB7CiAgZG9jdW1lbnQuYm9keS5hZGRFdmVudExpc3RlbmVyKCdrZXlkb3duJywgZnVu Y3Rpb24oZXYpIHsKICAgIGlmIChldi5rZXlDb2RlID09IDEzKSB7CiAgICAgIGluc2VydE5ld2xp bmUoKTsKICAgICAgZXYucHJldmVudERlZmF1bHQoKTsKICAgIH0KICB9LCBmYWxzZSk7Cn0KICAg IDwvc2NyaXB0PgogIDwvaGVhZD4KICA8Ym9keSBjb250ZW50ZWRpdGFibGU9InRydWUiIG9ubG9h ZD0iZ28oKSI+CiAgICA8YnI+V3JpdGUgdGhpbmdzIGhlcmUuCiAgICA8YnI+Rm9vLgogIDwvYm9k eT4KPC9odG1sPgo=