Open Bug 1417662 Opened 3 years ago Updated 2 months ago

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


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





(Reporter: msk1361, Unassigned)




(Keywords: rtl)

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:

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.
You can use this text (to save you some time):

سلام رفقا. بیاید این باگ رو با هم تعمیر کنیم!
Component: Untriaged → Editor
Keywords: rtl
Product: Firefox → Core
Priority: -- → P3
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.
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.
Ever confirmed: true
OS: Unspecified → Linux
Hardware: Unspecified → All
I'm looking for somebody to mentor me on this bug. Asking on IRC yielded no results, so I leave this comment here.
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.
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.
(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.
Flags: needinfo?(m_kato)
sorry for delay.

Now, key binding is defined in XBL (ex dom/xbl/builtin/, 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).
Flags: needinfo?(m_kato)

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

See Also: → 1521586
Component: Editor → Selection

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.

You need to log in before you can comment on or make changes to this bug.