1

In firefox only this problem occurs. If you do any sort of update to the range in the keyup event, it won't allow you to move the caret from the beginning of the line to the end of the previous using the left arrow key.

See: jsfiddle

<div id="bE" contenteditable="true">blah blah blah... enough to fill more than one line<br></div>

bE.addEventListener("keyup",KU);
function KU()
  {
  var sel=window.getSelection();
  var range=sel.getRangeAt(0).cloneRange();
  sel.removeAllRanges();
  sel.addRange(range);
  }

All I'm doing here is getting the range and saving back again without making any changes. Retrieving and saving the range (without changing anything) causes this problem. Really need to make it work. Works fine in ever other browser.

poby
  • 1,572
  • 15
  • 39
  • I am not seeing a problem here. Are you saying after a user changes something on the second line, they should be able to use the left arrow key to get back to the first? – Lloyd Banks Nov 06 '14 at 06:53
  • No changing. Just put the cursor on the 2nd line (after the word wrap). Then use the left arrow key to go back to the 1st line. In firefox its impossible, other browsers it works – poby Nov 06 '14 at 07:19

1 Answers1

1

The problem is that in Firefox there is a mismatch between the caret position the user sees and its representation in the document, which is that the positions at the end of one line and the start of the next, while visibly different, map to the same point in the document. In Chrome and other WebKit-esque browsers this problem doesn't exist because the visible position after the space at the end of the line doesn't exist; the space is not rendered and the caret goes straight from the start of the line to the end of the preceding word. This also seems conceptually better than the Firefox approach to me, since you wouldn't expect where the line wrapping falls to affect the number of arrow key presses it takes to navigate between words.

As to a solution, I suggest adding a check for whether the range you're selecting is identical to the currently selected range before calling removeAllRanges() and addRange().

Tim Down
  • 318,141
  • 75
  • 454
  • 536
  • I ended up fixing it by tightening up the code so it only updates the range when a change is needed but your solution is as good. Its a shame contenteditable is such a mess in all browsers and even more so that nobody seems inclined to fix or standardize exactly how it should behave. – poby Nov 06 '14 at 20:41