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

NEW
Unassigned

Status

()

defect
P3
normal
a year ago
3 months ago

People

(Reporter: msk1361, Unassigned)

Tracking

({rtl})

Trunk
All
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

a year ago
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.
(Reporter)

Comment 1

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

سلام رفقا. بیاید این باگ رو با هم تعمیر کنیم!
Component: Untriaged → Editor
Keywords: rtl
Product: Firefox → Core
Priority: -- → P3
(Reporter)

Comment 2

a year ago
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.

Updated

a year ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

a year ago
OS: Unspecified → Linux
Hardware: Unspecified → All
(Reporter)

Comment 4

a year ago
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.
(Reporter)

Comment 6

11 months ago
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.
(Reporter)

Comment 7

11 months ago
(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/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).
Flags: needinfo?(m_kato)

Comment 9

3 months ago

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

(Reporter)

Updated

3 months ago
See Also: → 1521586

Updated

3 months ago
Component: Editor → Selection
You need to log in before you can comment on or make changes to this bug.