Open Bug 1075901 Opened 6 years ago Updated 6 years ago

Firefox gets confused about cursoring in a contenteditable element after the selection is changed programatically

Categories

(Core :: DOM: Editor, defect)

32 Branch
defect
Not set
normal

Tracking

()

UNCONFIRMED

People

(Reporter: matma.rex, Unassigned)

Details

(Keywords: reproducible, testcase)

User Agent: Opera/9.80 (Windows NT 6.1; WOW64) Presto/2.12.388 Version/12.17

Steps to reproduce:

Firefox gets confused about cursoring in a contenteditable element after the selection is changed programatically.

Minimal test case: http://jsfiddle.net/ybawstce/1/

0. Have a contenteditable element where the native handling of left/right arrow keys is overridden (but behaves sanely)
1. Place cursor in large body of text in that contenteditable
2. Cursor up then down, everything is fine
3. Cursor right a dozen or so times, then up







Actual results:

The cursor jumps up and left to the same place it was after (2).


Expected results:

The cursor should appear in the location it was after (3), on the different line.
Calling nativeSelection.collapseToStart() at the end seems to magically fix the erroneous behavior (http://jsfiddle.net/ybawstce/3/).

This was encountered in the VisualEditor project (https://www.mediawiki.org/wiki/VisualEditor) which implements different left/right arrow handling for some non-text elements. Downstream bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=70724

Seems to be a fairly recent regression.
OS: Windows 7 → All
Hardware: x86_64 → All
A copy of the test case, for posterity:

<div id="ce" contenteditable>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</div>

$( '#ce' ).on( 'keydown', function ( e ) {
	var leftArrow = 37, rightArrow = 39;
	if ( e.keyCode === leftArrow || e.keyCode === rightArrow ) {
		e.preventDefault();

		var direction = e.keyCode === leftArrow ? -1 : 1;

		// Get current selection state
		var nativeSelection = window.getSelection();
		var range = nativeSelection.getRangeAt( 0 );

		// Simulate the effect of pressing arrow keys
		var newRange = document.createRange();
		newRange.setStart( range.startContainer, range.startOffset + direction );

		// Replace current range with ours
		nativeSelection.removeAllRanges();
		nativeSelection.addRange( newRange );
		// nativeSelection.collapseToStart(); // Adding this line restores correct behavior

		this.focus();
	}
} );
(In reply to Bartosz Dziewoński from comment #1)
> Seems to be a fairly recent regression.

Same behavior in FF17 and FF8, so probably an old bug.
Component: Untriaged → Editor
Product: Firefox → Core
(In reply to Bartosz Dziewoński from comment #2)
> // nativeSelection.collapseToStart(); // Adding this line restores correct behavior

Actually not true. It sometimes magically fixes cursoring, and sometimes throws very ugly-looking NS_ERROR_FAILURE exceptions. See https://bugzilla.wikimedia.org/show_bug.cgi?id=71580. (I don't have a minified test case for this.)
You need to log in before you can comment on or make changes to this bug.