1417662 - Ctrl-shift-navigation works in opposite direction in right-to-left text

Status: RESOLVED DUPLICATE of bug 1138419

(Core :: DOM: Selection, defect, P3)

Description

[Mehdi Sadeghi]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20171114100042

Steps to reproduce:

I typed some Persian text (RTL) and pressed down Ctrl+Shift+left/right arrow keys to select some text. The cursor moved in opposite direction. I tried in every possible text box, rendered text boxes (such as Twitter and this very textarea on this bug report page) and Firefox address bar or search bar. No difference.

Very similar bug on GTK is fixed, if it helps: https://bugzilla.gnome.org/show_bug.cgi?id=790341


Actual results:

The cursor counter intuitively moves in the opposite direction.


Expected results:

The cursor should move in the same direction as the glyph on the arrow key.

Comment 1

[Mehdi Sadeghi]

You can use this text (to save you some time):

سلام رفقا. بیاید این باگ رو با هم تعمیر کنیم!

Comment 2

[Mehdi Sadeghi]

Provided some hints I would be happy to work on this bug. I have not worked on Firefox before so it is new to me. Since word-by-word movement works fine when holding Ctrl + arrow keys, I guess it is already implemented and the machinery should be in place. We only need to add the case for Ctrl + Shift to it.

Comment 3

[Aidin Gharibnavaz]

I confirm that this bug exist in Firefox 57.0. I tested it on GNU/Linux Mint 18.1 64bit.

The bug also exist in the debug build of latest "mozilla-central" source.

Comment 4

[Mehdi Sadeghi]

I'm looking for somebody to mentor me on this bug. Asking on IRC yielded no results, so I leave this comment here.

Comment 5

[Makoto Kato [:m_kato]]

caret behavior isn't related to editor.  It is nsFrameSelection (in /layout/generic).  But when investigating root cause, it will be changed to Core:Selection.

Comment 6

[Mehdi Sadeghi]

I literally added a breakpoint to every function defined in nsFrameSelection but I was unable to find the function (if any) handing the Shift+Arrow Keys event. I realized however, that there is an event system capturing key presses and dispatching them, but got no further.

The source code is huge and complex, so some more hints are really appreciated.

Comment 7

[Mehdi Sadeghi]

(In reply to Makoto Kato [:m_kato] from comment #5)
> caret behavior isn't related to editor.  It is nsFrameSelection (in
> /layout/generic).  But when investigating root cause, it will be changed to
> Core:Selection.

Sorry, I forgot to attach the more information flag. Thanks.

Comment 8

[Makoto Kato [:m_kato]]

sorry for delay.

Now, key binding is defined in XBL (ex dom/xbl/builtin/textareas-base.inc, dom/xbl/builtin/unix/platformHTMLBindings.xml and etc).  When pressing key, cmd_* command is assigned, then nsIControllerCommand (ex. dom/base/nsGlobalWindowCommands.cpp etc.) is called with this command.

Most commands that uses arrow key is mapped to nsFrameSelection (ex. nsFrameSelection::CaracterMove).

Comment 9

[(no longer active)]

Simple test case for my testing with RTL/LTR text mixed on a single line

Comment 10

[Mehdi Sadeghi]

Info for future visitors landing on this page.

If you are using Firefox on a Linux distro you can set bidi.edit.caret_movement_style=1 in about:config. According to my tests on Arch Linux this temporariyl fixes the above problem without messing the behaviour for Latin text. However this key might be removed in future alltogether (at least based on some discussion over irc with :ehsan).

If you are on Mac the behaviour is different and AFAIK changing this key breaks selection in many ways dealing with Latin text.

Comment 11

[David D Lowe]

This seems to be similar to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1138419