Open Bug 1417662 Opened 3 years ago Updated 2 months ago
Ctrl-shift-navigation works in opposite direction in right-to-left text
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.
You can use this text (to save you some time): سلام رفقا. بیاید این باگ رو با هم تعمیر کنیم!
Component: Untriaged → Editor
Product: Firefox → Core
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.
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.
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).
You need to log in before you can comment on or make changes to this bug.