Issue 55248

Summary: Incorrect cursor key movement between table cells of different directionality
Product: Writer Reporter: eyalzvi <eyal>
Component: editingAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Trivial    
Priority: P4 CC: issues
Version: OOo 1.0.0Keywords: BIDI, oooqa
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 114236    
Attachments:
Description Flags
Simple demonstration of the issue none

Description eyalzvi 2005-09-29 16:11:11 UTC
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
selectes 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 curosr 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
preceeds 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 michael.ruess 2005-09-30 09:20:39 UTC
MRU->SBA: please have a loo, it is about cursor movement in tables in CTL.
Comment 2 lohmaier 2005-10-10 23:35:03 UTC
Please attach a sample document to reproduce.
Comment 3 eyalzvi 2005-10-11 00:46:00 UTC
Created attachment 30296 [details]
Simple demonstration of the issue
Comment 4 lohmaier 2005-10-12 23:52:37 UTC
Hmm. Not sure whether this is a bug. Anyway - confirming. At least with visual
cursor movement I'd expect the right-arrow key to move to the right cell...
Comment 5 jack.warchold 2005-10-20 14:02:58 UTC
confirmed on 680m3 and 680_m131

reassigend to fme

target OOo later
changed prio to p4
Comment 6 shivjin 2006-01-23 23:33:47 UTC
I was also able to reproduce the defect by following the steps provided in the
sample file.  This defect was reproducible with the following:

	Windows 2000 Professional and Open Office 2.0
	Windows XP and Open Office 2.0

In addition to reproducing the defect I ran some follow up testing:

Test 1 - Test to see if the behaviour of the cursor moving the left if the right
arrow key is pressed and vice versa in any other situations.  I was also able to
reproduce this behaviour in a frame.  These are the steps that I used:

1) Open Office Writer
2) Click insert->frame
3) Click on the options tab
4) Set the text direction to Right to Left (horizontal)
5) Click ok and the frame should occur on the screen
6) Click anywhere off the frame and then click back on it
7) The cursor should now be flashing in the frame 
8) Type the words test
9) Place the cursor between the t and the e and press the left arrow key

The left arrow key will move the cursor to the right which is the same
unexpected behaviour that happens in the table cells when the cell direction is
set to right to left.

Test 2 – Test the behaviour of the delete key and the backspace key in the right
to left cell to see if they delete the character to the left of the cursor like
they are suppose to or if they perform the same defect and move to the right
just because the cell direction is set to right to left.  These two keys both
moved to the left of the cursor in a cell defined as left to right and right to
left, so there is no problem with these keys.

I agree with the previous statements that this behaviour can be quite confusing
and disappointing to users.  At the same time I don't think its importance is
too high because once the user realizes that the arrow keys are moving the
cursor in the opposite direction they will still be able to move though their
table.  This behaviour is only seen when the cell direction is set to right to
left and I think only a few users will be utilizing this option. 
Comment 7 eyalzvi 2006-08-04 10:52:35 UTC
>> This behaviour is only seen when the cell direction is set to right to
>> left and I think only a few users will be utilizing this option.

This is typical to people who think that Left-To-Right languages are "correct"
and all RTL languages are "wrong" and therefore are used by "only a few users".

There are well over 500,000,000 people who's native language is RTL. Not only
they are users, almost every multi-national corporation produces documents for
markets where the language is RTL.

To the point of this bug - this is a very COMMON problem in RTL documents,
because very often table cells are used for Latin text (eg. email addresses) or
numbers.

In order to have correct directionality of such data, the cells containing the
data must be switched to LTR, and it then becomes impossible to navigate using
the arrow keys.

>> At the same time I don't think its importance is too high because once 
>> the user realizes that the arrow keys are moving the cursor in the 
>> opposite direction they will still be able to move though their table.

Believe me there is NO WAY to get used to keys that behave differently in each
cell. I'm a programmer with 25 years of experience and I used more than a few
bad programs, and this bug drives me mad to the point that I give up and switch
to MS Word.

Therefore, for RTL users, fixing this bug IS important.
Comment 8 Martin Hollmichel 2011-03-16 11:42:08 UTC
set target 3.x since not relevant for 3.4 release.