Bug 32531 - Incorrect cursor key movement between table cells of different directionality
Summary: Incorrect cursor key movement between table cells of different directionality
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: Other All
: medium normal
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: RTL-CTL
  Show dependency treegraph
 
Reported: 2010-12-20 11:13 UTC by Eyal
Modified: 2017-03-17 11:03 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Demonstration of wrong cursor movement in RTL cell (10.43 KB, application/vnd.oasis.opendocument.text)
2010-12-20 11:13 UTC, Eyal
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal 2010-12-20 11:13:14 UTC
Created attachment 41307 [details]
Demonstration of wrong cursor movement in RTL cell

When using the cursor keys to move to next/previous cell, the direction of
movement depends on the directionality of the cell (LTR = Left to Right, or RTL
= Right To Left).

For example, when a cell is defined to have LTR direction, and the user presses
the left arrow key, the cursor moves to the previous cell (to the left).

However, if a cell is set to RTL direction, and the uses presses the left arrow
key, the cursor moves to the next cell (to the right).

This is incorrect behavior and very confusing. The user expects the cursor keys
to behave logically - progress to the next cell relative to the direction of the
 table, not to the next cell relative to the direction of text in the current cell.

An example of how this behavior is very confusing:

A user creates a table in a Hebrew document. Hebrew is an RTL language and so
the direction of the document, and by default of the table, is RTL. The then
selects one of the columns and clicks the LTR tool-button, to make all cells in
the column have LTR text. This is because the column is intended for email
addresses, which are always in English.

The user then uses the left arrow key to move from the first (right-most)
column, to the next, then to the next, etc. Then the user reaches the email
column (which is LTR), and again presses the left arrow key.

The user expects the cursor to move to the next column - to the left, however
the cursor moves to the previous column! Repeated presses on the left arrow key
cause the cursor to remain "trapped" among the email column and the column that 
precedes it.

The solution: cursor movement between cells should depend on the direction of
the table, not the direction of the text in the current cell.
Comment 1 Netanel_H 2010-12-21 09:11:33 UTC
it is - http://www.openoffice.org/issues/show_bug.cgi?id=55248
Comment 2 Kohei Yoshida 2010-12-22 07:14:04 UTC
This is a Writer table, so I guess putting Cedric in CC would be more appropriate.
Comment 3 Jared McCannon 2011-12-02 06:17:09 UTC
Does this bug apply to the direction of the cursor in general when navigating through RTL documents in general? As of now, the right arrow makes the cursor go right and the left arrow goes left.  Is this a separate issue or the same?  Also, I'm having trouble locating the code for the language directionality. Any pointers there?
Comment 4 Eyal 2011-12-04 09:50:42 UTC
(In reply to comment #3)
> Does this bug apply to the direction of the cursor in general when navigating
> through RTL documents in general? As of now, the right arrow makes the cursor
> go right and the left arrow goes left.  Is this a separate issue or the same? 

The bug refers only to cursor movement between table cells.

Eyal.
Comment 5 Jared McCannon 2011-12-04 10:53:15 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Does this bug apply to the direction of the cursor in general when navigating
> > through RTL documents in general? As of now, the right arrow makes the cursor
> > go right and the left arrow goes left.  Is this a separate issue or the same? 
> 
> The bug refers only to cursor movement between table cells.
> 
> Eyal.

Ok.  The inversion of the arrow keys is still an issue.  Right means right and left means left.  A way of fixing the cell cursor movement could be to fixing the inverse arrow key movement as well.  Or is that not a concern?
Comment 6 Jared McCannon 2011-12-04 10:56:28 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Does this bug apply to the direction of the cursor in general when navigating
> > through RTL documents in general? As of now, the right arrow makes the cursor
> > go right and the left arrow goes left.  Is this a separate issue or the same? 
> 
> The bug refers only to cursor movement between table cells.
> 
> Eyal.

Ok.  The inversion of the arrow keys is still an issue.  Right means right and left means left.  A way of fixing the cell cursor movement could be to fixing the inverse arrow key movement as well.  Or is that not a concern?
Comment 7 Björn Michaelsen 2011-12-23 11:33:47 UTC
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 8 Björn Michaelsen 2011-12-23 12:57:15 UTC
An EasyHack should have been checked by developers and thus is confirmed regardless of age. Moving back to NEW from NEEDINFO again. Sorry for the hassle.
Comment 9 Gábor Stefanik 2012-05-06 17:20:05 UTC
Seems like this is not just about table cells - it happens whenever the cursor crosses a boundary between LTR and RTL paragraphs / text runs.

Interestingly, it doesn't trigger with RTL words in an otherwise LTR paragraph - the cursor does move right when the Left key is pressed inside the RTL word, but it doesn't get trapped on the boundary.
Comment 10 Gábor Stefanik 2012-05-11 15:46:47 UTC
OK, so this is actually 2 separate bugs:
1. With caret movement set to Logical, caret gets trapped between LTR and RTL text runs (not just table cells).
2. With Visual caret movement, caret is trapped at the end of an RTL cell containing LTR text.

I assume the original poster meant the 2nd bug, the 1st one can be dealt with in a separate bug report.
Comment 11 Florian Reisinger 2012-05-18 08:21:59 UTC
Removed EASYHACK from summary
Comment 12 Björn Michaelsen 2013-10-04 18:46:16 UTC
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.

see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Comment 13 Cédric Bosdonnat 2014-01-20 08:57:19 UTC
Restricted my LibreOffice hacking area
Comment 14 QA Administrators 2014-10-23 17:31:46 UTC Comment hidden (obsolete)
Comment 15 Björn Michaelsen 2014-12-02 10:53:11 UTC
adding LibreOffice developer list as CC to unresolved Writer EasyHacks for better visibility.

see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Comment 16 Robinson Tryon (qubit) 2015-12-10 11:50:45 UTC
Migrating Whiteboard tags to Keywords: (easyHack)
Comment 17 Miklos Vajna 2016-01-04 11:18:09 UTC
Seeing this is marked as an easy hack, but without code pointers:

Writer keyboard input for the main editing area is in general handled in SwEditWin::KeyInput(), sw/source/uibase/docvw/edtwin.cxx. Put a breakpoint at the start of the member function in a debugger, then hit the key you're interested in, that'll allow you to see where the exact code is for the actual use case.
Comment 18 Robinson Tryon (qubit) 2016-02-18 14:52:07 UTC
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC)
[NinjaEdit]
Comment 19 Jaskaran Singh 2016-03-10 13:05:58 UTC
I have committed a patch to fix this issue and also tested it on my system. Please review it. 
Thanks
Comment 20 Commit Notification 2016-04-05 10:23:01 UTC
Jaskaran committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a215cec969f7401b08cabb686c5b2b1d803399d0

tdf#32531 Fix for key movement in table cell of different directionality

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 21 jani 2016-05-05 06:08:19 UTC
seems solved
Comment 22 Khaled Hosny 2016-09-01 11:38:15 UTC
The commit here caused bug 101361, which is rather major usability regression for RTL documents. So I’m reverting this commit and re-opening the bug until a better fix is provided.
Comment 23 tommy27 2017-01-09 06:14:32 UTC
@Khaled
I've seen you have already fixed Bug 101361.
Are you still working on a better fix for the current report?
Comment 24 Khaled Hosny 2017-01-09 14:40:38 UTC
(In reply to tommy27 from comment #23)
> @Khaled
> I've seen you have already fixed Bug 101361.
> Are you still working on a better fix for the current report?

No, I’m not working on this bug.
Comment 25 tommy27 2017-03-17 11:03:25 UTC
let's put it back to NEW to see if there's someone who wants to pick it.