Page MenuHomePhabricator

VisualEditor: Arrow keys move the caret in the opposite direction in RTL environment
Closed, ResolvedPublic

Description

Arrow keys move the caret in the opposite direction in RTL environment. Simple textareas in browsers do this correctly, so as much as possible, the Visual Editor should rely on the browsers' behavior.

See https://www.mediawiki.org/wiki/VisualEditor/Internationalization_requirements .

Related: bug 38000.


Version: unspecified
Severity: normal

Details

Reference
bz38546

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 12:52 AM
bzimport set Reference to bz38546.

orbit wrote:

Amir, I'm pretty sure that this should be working properly in the new contenteditable-based editor. Can you double-check for me? Here's my RTL demo: http://framezero.com/work/wikia/VisualEditor/demos/ve/index.php

Try it with text that is actually RTL :)

Without looking at the code, I guess that you capture keypress events, and if it's a right arrow, you move it one character forward, and vice versa. But for RTL right is backward etc.

Simply reversing the direction for RTL text will not be enough, because an LTR word in the middle of an RTL paragraph will mess things up. And that's just one of the many complications. It took Gecko and Webkit developers years to get it right and both still have bugs.

The best way to handle arrow events is to simply let the browser handle them.

@Amir: Your guess it correct, we are capturing keyboard events (keydown to be specific) and then moving cursor forward (right arrow) or backward (left arrow). We implemented it in this way because it let's us block user from moving cursor inside a non-editable element (alien node - like rendered template for instance). It seems that we will have to work a little bit more on this, I will try to just let browser handle cursor movement but then "fix" it in JavaScript if it ends up in wrong place.

Related URL: https://gerrit.wikimedia.org/r/65703 (Gerrit Change Ic01e110a5e6094cd275327a2e8cea90c900f1bd1)