Bug 67917 - Moving by word right moves to the beginning of next word, not end of current word on OS X
Summary: Moving by word right moves to the beginning of next word, not end of current ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All macOS (All)
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: a11y-macOS
  Show dependency treegraph
Reported: 2013-08-08 19:35 UTC by Boris Dušek
Modified: 2022-05-10 03:29 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:
Regression By:


Note You need to log in before you can comment on or make changes to this bug.
Description Boris Dušek 2013-08-08 19:35:45 UTC
When moving by word right on OS X (e.g. using Option-right arrow), the text cursor ends right before the first character of the next word instead of right after the last character of the current word. This is inconsistent with other apps on OS X and probably causes VoiceOver to also read in a way inconsistent with other apps on OS X when moving word right.

Steps to reproduce:
1. Have this text in Writer: "The quick brown fox jumps over the lazy dog"
2. Put cursor right before "q" in the word "quick"
3. (optional) Turn on VoiceOver (e.g. using Cmd+F5)
4. Press Option-right arrow to move word right

Expected results:
The cursor ends right after "k" in word "quick" and before the space. If optional step 3. was taken, then VoiceOver will read word "quick"

Actual results:
The cursor ends right before "b" in word "brown" and after the space. If optional step 3. was taken, then VoiceOver will read word "brown"

Tested on OS X 10.8.4 with LO 4.2 master (commit 39a78087890fb9255a5e47220bac6cfb956fcfe0).

LO behavior is inconsistent with how other apps behave - for example of the apps:
* TextEdit
* Pages
* Mail
* Safari
* TextMate
* pretty much any app on OS X

I also think this is the cause of why VoiceOver reads inconsistently with these other apps when moving by word right.

What is more "amusing" is that the documentation for -[NSResponder moveWordRight:] basically says LO way is right even though no OS X app behaves that way and instead behaves according to "Expected results" above :-)
Comment 1 Urmas 2013-08-09 16:45:33 UTC
The move-by-word command is moving it to the beginning of words.
It has always been moving it to the beginning of words.
Comment 2 Boris Dušek 2013-08-09 17:52:36 UTC
You make it sound like a natural law even though it is a matter of definition and it seems the definition on OS X is not how LO behaves.

I also don't think you should close my (or anyone's) bug without discussing my (their) concerns mentioned in the bug report - or you think the reference OS X apps like TextEdit, Pages, Mail, TextMate I mentioned are buggy in this regard?
Comment 3 Boris Dušek 2013-08-09 17:54:39 UTC
Just to make it clear - I am discussing behavior of LibreOffice on OS X, not on any other platform.
Comment 4 Urmas 2013-08-10 05:06:21 UTC
The cross-platform products require a stable behavior. The same keypress/macro command cannot give unpredictable results.
Comment 5 Boris Dušek 2013-08-13 19:26:34 UTC
I tend to disagree. I think even cross-platform products should as much as possible adhere to the conventions of the platform they run on. Because users of that platform will not compare the behavior of such software with behavior of the same software on a different platform. They will compare the behavior of such software with behavior of other software on the *same* platform in case there is a convention.

For OS X user, it's of no use for the alt-arrow to behave consistently with Windows or other platforms they don't use. For OS X user, it's of great use for alt-arrow to behave the same as the rest of the system, which they do use and the way they are used to. And the same IMHO holds if you substitute "OS X" for "GNOME", "Windows", or any other platform.

Note that on OS X, already many shortcuts behave differently because of text conventions - e.g. Ctrl+P does not start printing, but moves in text line up (in fact, a whole bunch of emacs shortcuts work in text components on OS X and therefore LO). Printing is instead done by Cmd+P. Because that's what the OS X user expects. Etc.

I personally find the behavior of LO confusing exactly because I am used from other OS X apps to the OS X convention of what alt-arrow means. Not because the convention is "better" in any way. But because it is consistently used by OS X apps, Apple and non-Apple ones, and I am used to such behavior. And I don't care how LO behaves on other platforms as I don't use those platforms.

So this is approximately how I think about it. Not cross-platform consistency, but platform consistency.
Comment 6 خالد حسني 2013-08-31 21:18:21 UTC
Is this behaviour new in 4.2? If not, then the version field needs to be adjusted.
Comment 7 retired 2013-09-01 10:31:43 UTC
Not sure if I agree. alt + right-arrow moves to beginning of the next word. If you  end on the word you are in or end at the start of the next word is just a design choice. It does neither improve nor degrade a workflow.

Boris, do you know if this is a recommendation in some Apple Design Guideline? If so, could you link to that?

Just checked and indeed all other softwares behave as you describe, so for the sake of consistency this should be changed. Not sure if this goes for all platforms or only OS X, though.

Khaled, this behavior is not new to LO 4.2. It exists already in Not sure about older versions but I'd guess they behave the same.
Comment 8 Boris Dušek 2013-09-01 14:10:11 UTC
Hello James, now I looked into the OS X HIG and found this:

Shift-Alt-right arrow: Extend selection to the end of the current word, then to the end of the next word.

It's at https://developer.apple.com/library/mac/documentation/userexperience/Conceptual/AppleHIGuidelines/KeyboardShortcuts/KeyboardShortcuts.html#//apple_ref/doc/uid/TP40002725-SW2

While this is not "Alt-right arrow" but that with Shift added, it can be deduced from that how "Alt-right arrow" behaves - it should move to the end of the current word, then to the end of the next word, i.e. the cursor is at the end of some word after that action.
Comment 9 oscar valenzuela 2014-10-26 18:47:55 UTC
Confirmed in LibreOffice (Dev) 4.4.0 alpha1 under Mac OS X 10.10 (Yosemite) x86-64
Comment 10 QA Administrators 2015-12-20 16:09:54 UTC Comment hidden (obsolete)
Comment 11 Boris Dušek 2015-12-20 18:21:12 UTC
The bug is still present in LibreOffice 5.0.4 on OS X 10.11.2.

(Testing with 3.3.0 asks for installing Java which I have, and I am not successful at adding the installed Java to LO there, so giving up on it).
Comment 12 Yousuf Philips (jay) (retired) 2016-09-15 17:37:34 UTC
So we have to weigh whether its more important for users who switch from OS to OS to have the same behaviour in LO or to make LO feel more at home with other mac apps. The last time this issue was brought up (cant remember which bug it was in :D), we went with consistency of LO across platforms.

@steve, @alex: Can you check what other cross platform apps do about this behaviour on their mac versions?

@tomaz: would it be simple to implement a different behaviour for ctrl+right arrow?
Comment 13 steve 2016-09-15 17:38:19 UTC
MS office on macOS moves to the next word and is always on the left side of that word. (input requested by jay)
Comment 14 Tomaz Vajngerl 2016-09-15 18:14:05 UTC
Heh.. interesting that people notice this things. I was using various editor with mixed behavior and never noticed it - only now when I checked. Oh well..

> @tomaz: would it be simple to implement a different behaviour for ctrl+right
> arrow?

Probably not too hard to change, yes. Could be an easy hack.. possibly together with other similar changes. But probably needs changes on multiple places as Writer does its own thing.
Comment 15 Heiko Tietze 2016-09-15 21:16:43 UTC
(In reply to Yousuf Philips (jay) from comment #12)
> So we have to weigh whether its more important for users who switch from OS
> to OS to have the same behaviour in LO or to make LO feel more at home with
> other mac apps.

We should prefer OS/DE typical behavior. Most users do not switch frequently.
Comment 16 Daniel T. 2016-09-23 14:45:41 UTC
Seems fixed / Can no longer reproduce in the following version

Build ID: 1:5.1.5~rc2-0ubuntu1~trusty1
Comment 17 V Stuart Foote 2016-09-23 14:52:39 UTC
Lets let Borris make that call as to WFM, no indication it has been fixed with a commit at the 5.1.5 or in 5.2 or master. Back to NEW
Comment 18 Boris Dušek 2016-09-23 15:13:16 UTC
I can say that with LO 5.2.1 for macOS just downloaded from libreoffice.org, on macOS 10.12, the issue is still reproducible: After following the "Steps to reproduce", I still do not get the "Expected results", but rather the "Actual results".
Comment 19 Heiko Tietze 2016-09-24 07:38:37 UTC
Setting EASYHACK following Tomaz' comment 14. Please add codepointers.
Comment 20 steve 2016-09-24 07:56:27 UTC Comment hidden (no-value)
Comment 21 Heiko Tietze 2016-09-24 08:08:39 UTC Comment hidden (no-value)
Comment 22 jani 2016-09-26 05:37:30 UTC
Changing multiple places in writer is not really an easyHack.
Comment 23 Xisco Faulí 2017-09-29 08:49:36 UTC Comment hidden (obsolete)
Comment 24 Boris Dušek 2017-09-29 14:31:10 UTC
with LibreOffice (Build ID: ea7cb86e6eeb2bf3a5af73a8f7777ac570321527)
on macOS 10.13 (17A365).

The result is that the "non-optional" part of the bug is still reproducible (i.e. the actual behaviour is "The cursor ends right before "b" in word "brown" and after the space.").

However the "optional" part of the bug is no longer reproducible (i.e. the actual behaviour is "If optional step 3. was taken, then VoiceOver will read word "quick"). At first look this is however most likely due to a change in VoiceOver itself in its newer releases, not due to any change in LibreOffice itself.
Comment 25 Heiko Tietze 2017-10-01 08:34:12 UTC Comment hidden (no-value)
Comment 26 QA Administrators 2018-10-02 02:57:11 UTC Comment hidden (obsolete)
Comment 27 eisa01 2020-05-09 22:03:05 UTC
Still present, and also in LO 3.3

Build ID: f14691683900f6b28737be8c599e1ee4e8386e14
CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 28 QA Administrators 2022-05-10 03:29:23 UTC
Dear Boris Dušek,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team