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

Status: UNCONFIRMED

(Core :: DOM: Editor, defect, P5)

Description

[Bartosz Dziewoński]

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.

Comment 1

[Bartosz Dziewoński]

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.

Comment 2

[Bartosz Dziewoński]

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();
	}
} );

Comment 3

[Loic]

(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.

Comment 4

[Bartosz Dziewoński]

(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.)

Comment 5

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.