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)
Version:
(earliest affected)
Inherited From OOo
Hardware: All macOS (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: accessibility
Depends on:
Blocks: a11y-macOS
  Show dependency tree / graph
 
Reported: 2013-08-08 19:35 UTC by Boris Dušek
Modified: 2023-07-06 05:35 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

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 
Summary:
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"

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

Notes:
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 4.1.1.2. 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

Version: 5.1.5.2
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 
Tested
with LibreOffice 5.4.1.2 (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

Version: 7.0.0.0.alpha0+
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 Comment hidden (obsolete)
Comment 29 eisa01 2023-03-19 09:30:16 UTC 
Still present. I guess this is more an enhancement to comply with macOS conventions

Version: 7.5.1.2 (AARCH64) / LibreOffice Community
Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129
CPU threads: 10; OS: Mac OS X 13.2.1; UI render: default; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded