Issue 121193 - Alt+Arrow & Cmd+Arrow move cursor in the opposite directions, in RTL text editing
Summary: Alt+Arrow & Cmd+Arrow move cursor in the opposite directions, in RTL text edi...
Alias: None
Product: Internationalization
Classification: Code
Component: BiDi (show other issues)
Version: 3.4.1
Hardware: Mac Mac OS X, all
: P3 Major with 2 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Keywords: accessibility, Arabic, BIDI, Hebrew
Depends on:
Reported: 2012-10-10 11:56 UTC by Tal
Modified: 2017-05-20 11:51 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: 4.1.0-dev
Developer Difficulty: ---
jsc: 4.1.0_release_blocker-

Hebrew sentence, for example, with instructions to recreate bug (9.33 KB, application/vnd.oasis.opendocument.text)
2013-09-20 13:54 UTC, Tal
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Tal 2012-10-10 11:56:09 UTC
While editing a Hebrew/Arabic texts, Alt + Left/Right-arrows moves to the previous/next word, but in Hebrew, the arrows behavior is reversed. 

Make sure Alt+Left/Right move in the direction the arrow requests. 
The same goes to Alt+Shift+Left/Right.
Just like in English, when you ask to Alt+Left to move to the word on your left.

In other words: 
Alt+Right jumps left, instead of to the right (original intent is to jump to the previous word location, meaning... right, in Hebrew/Arabic).
Alt+Shift+Right - same reversed behavior.
In the same way, Alt+Left and Alt+Shift+Left should jump to left, instead of to the right.

This relates to the 92224 bug, which was initiated at 2008 and reported of awkward keyboard shortcuts behavior on the Mac, but this is an annoying issue I find rather annoying while editing RTL texts. I'm using build 9593 of OpenOffice (3.4.1).

Just to be clear, I've checked other applications on the Mac, and this behavior works fine in TextEdit, Mail, and Notes applications. This is an OpenOffice issue.

Comment 1 Tal 2012-10-17 20:38:02 UTC
I've found that Cmd+Right/Left Arrows works on MAC just as the Alt+Left/Right Arrow should work. So I guess this is a bypass for all MAC users, which results from Windows Ctrl+Right/Left Arrow behavior. However, MAC users are more used to Alt+Arrows to move between words and adding the Shift to select words within a sentence. Cmd+Arrows are used on MAC to go to the start/end of the line.
Comment 2 Tal 2013-09-18 13:00:05 UTC
Bug is persistent in version 4.0 too now (opened bug in version 3.4). 

Current description of the bug: 
On Mac, while editing text in Writer, Alt+Right arrow moves left one word, instead of moving right. Command+Right-arrow moves the opposite way to, to the left, instead of to the right.

Please fix, or let me know how can I solve this annoying bug.
Comment 3 Tal 2013-09-18 13:03:33 UTC
Confirmed bug still exists in version 4.0.
Tested on a Hebrew text, Mac OS 10.6.8
Comment 4 Tal 2013-09-18 13:11:44 UTC
Relevant thread:
Comment 5 Oliver-Rainer Wittmann 2013-09-20 08:51:03 UTC
@Tal: Could you provide a sample file containing Hebrew/Arabic text? This would make it easier for others to reproduce the defect and later on to verify the fix. Thanks in advance.
Comment 6 Tal 2013-09-20 13:54:36 UTC
Created attachment 81587 [details]
Hebrew sentence, for example, with instructions to recreate bug

The document demonstrates the reversed behavior of Alt(Option)+Arrows command, as well as Command+Arrow command, on the Mac.
Comment 7 Tal 2013-10-10 09:52:01 UTC
Found out that on Windows cursor moves fine with modifier keys (Alt/Ctrl). 
This issue is only for the Mac, AFAIK.

Initial attempts to fix the code failed:
Tried to change editeng/source/editeng/impedit2.cxx, which seemed to most promising candidate. changed MoveCursor function to call WordRight() instead of WordLeft() on KEY_LEFT/KEY_RIGHT, but the final application wasn't affected by this change.

Possible directions for checking: 

? check that GetLocale function works fine on Mac, since the code works perfectly on Windows. 

? find a better code location that has an effect on text editing?

? check KeyEvent::LogicalTextDirectionality function (how?)

? May be related to sun's star text library previousWord/nextWord (same on Mac/Win?)

Any further assistance would be appreciated.
Comment 8 Tal 2014-03-27 14:15:06 UTC
Moved to Internationalization > BIDI.
Comment 9 Tal 2014-03-31 07:42:03 UTC
Reverted Version to 3.4.1; the 1st version I noticed this bug. Still evident in 4.1 dev snapshots.
Comment 10 Andrea Pescetti 2014-04-01 14:05:17 UTC
Tal Daniel asked to raise this RTL bug as a stopper, see QA list. He doesn't have the required privileges, so I'm nominating this bug on his behalf.

This seems to break the usability of CTRL-left and CTRL-right when editing RTL text (including Hebrew). Honestly, since I don't use RTL functionality, I cannot evaluate how annoying it is. No patches currently available (but some technical analysis is in the issue). Sample docs attached to issue.
Comment 11 mroe 2014-04-01 14:28:41 UTC
I can confirm the described behaviour with OOo 3.3 and later, MacOS 10.8.2.

The issue doesn't occur under Linux/Ubuntu.
Comment 12 jsc 2014-04-01 14:40:47 UTC
it is no regression and it exists for some time, I agree that we should fix this asap but I am not sure if it is really a showstopper.

Anyway we will analyze it and will decide later.
Comment 13 jsc 2014-04-01 14:45:44 UTC
it is definitely an annoying issue for user of the RTL feature but we should keep in mind that Hebrew is new and came in late after the translation deadline. I am in favor to move on with the release and use the Hebrew version for a deep analysis and test how well we work for such languages in general. We can fix it asap on trunk together with more expected issues ... But I don't think that we should stop the release for this.
Comment 14 jsc 2014-04-02 15:11:46 UTC
no showstopper, will be fixed on trunk asap
Comment 15 Tal 2016-11-07 22:23:03 UTC
(In reply to jsc from comment #14)
> no showstopper, will be fixed on trunk asap

Thanks. Confirmed for v4.1.3, OS X 10.11.6. I'd appreciate a fix for that, as it makes editing counterintuitive, in RTL languages.