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.
it is - http://www.openoffice.org/issues/show_bug.cgi?id=55248
This is a Writer table, so I guess putting Cedric in CC would be more appropriate.
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?
(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.
(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?
[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
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.
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.
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.
Removed EASYHACK from summary
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
Restricted my LibreOffice hacking area
Please read this message in its entirety before responding. Your bug was confirmed at least 1 year ago and has not had any activity on it for over a year. Your bug is still set to NEW which means that it is open and confirmed. It would be nice to have the bug confirmed on a newer version than the version reported in the original report to know that the bug is still present -- sometimes a bug is inadvertently fixed over time and just never closed. If you have time please do the following: 1) Test to see if the bug is still present on a currently supported version of LibreOffice (preferably 4.2 or newer). 2) If it is present please leave a comment telling us what version of LibreOffice and your operating system. 3) If it is NOT present please set the bug to RESOLVED-WORKSFORME and leave a short comment telling us your version and Operating System Please DO NOT 1) Update the version field 2) Reply via email (please reply directly on the bug tracker) 3) Set the bug to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link: https://wiki.documentfoundation.org/QA/BugTriage There are also other ways to get involved including with marketing, UX, documentation, and of course developing - http://www.libreoffice.org/get-help/mailing-lists/. Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
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
Migrating Whiteboard tags to Keywords: (easyHack)
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.
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC) [NinjaEdit]
I have committed a patch to fix this issue and also tested it on my system. Please review it. Thanks
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.
seems solved
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.
@Khaled I've seen you have already fixed Bug 101361. Are you still working on a better fix for the current report?
(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.
let's put it back to NEW to see if there's someone who wants to pick it.
Sill happens in LibreOffice 5.4.1 (Debian, 64bit)
Still happens in: Version: 5.4.2.2.0+ Build ID: 1:5.4.2-3~bpo9+1 CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: gtk2; Locale: en-US (en_US.utf8); Calc: group OS: Debian Stretch (Debian 9.2, with some backported packages)
Bug still manifests with: Version: 6.1.1.2 Build ID: 5d19a1bfa650b796764388cd8b33a5af1f5baa1b CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk2; Locale: en-GB (en_GB.UTF-8); Calc: group threaded Note that in the example file, pressing the right arrow while in the row with text should move you rightwards from cell to cell to cell, but in the RTL cell, you are moved back to the previous LTR cell, so right-arrow'ing puts you an infinite back-and-forth.
Dear Eyal, 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Eyal, 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 MassPing-UntouchedBug
The bug is still present as described in my initial report. Checked again with MS Word and it behaves as expected, ie. in a table with mixed directionality cursor movement is consistent with the main directionality. NOTE: In Word, the role of the cursor keys is reversed when switching from the main directionality to the opposite directionality. For example, if the main directionality is LTR, with an RTL word (or table cell) in the middle, then using the right cursor key keeps moving to the next character, even when in the RTL word, so in effect the right cursor key visually moves the cursor to the left. Let's say LLL represents LTR text and RRR represents RTL text. The cursor is at the beginning of the text, and the users just presses the right-arrow key. This is hos the cursor moves: LLL RRR LLL >>>><<<>>>> It doesn't matter whether this is plain text or table cells.
Bug still manifests with: Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 6c81a09e3ef239a2d7a991d00fe3620a67298b99 CPU threads: 4; OS: Linux 5.18; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US
... and note also the equivalent bug in Impress/Draw. In Calc this can't happen since keyboard movement is either among cells or within a single cell.