Problem description: When editing a document in Writer, the position of the cursor on the line is not maintained when moving up or down through intermediate lines shorter than the original position or the cursor on the line. Steps to reproduce: 1. In a document with many lines of text with differing lengths, place the cursor near the end of one of the longer lines. 2. Using the arrow keys on the keyboard move the cursor up or down through an intermediate line which is shorter than the original cursor position. Current behaviour: The cursor position is reset to the length of the shortest intermediate line. Sometimes, if the cursor has only been moved up or down by 2 lines, the position is maintained as expected. However this appears to be a rare occurrence, and I could not see the difference in the scenario where this worked and where it did not. Expected behaviour: As long as no further editing or sideways movement has been done, the position on the line of the cursor should be maintained, as near as possible, for each line moved to using the up and down keys. If the cursor is moved up or down by any number of lines, and returned to the original line using only the up and down keys (or the "page up" and "page down" keys) it should be in exactly the same place it started from. Operating System: Windows 7 Version: 4.0.2.2 release
do you still see this with recent LibO 4.1.1.2 release? if yes, please attach a test document where you reproduce the bug.
I just downloaded and installed: Version: 4.1.1.2 Build ID: 7e4286b58adc75a14f6d83f53a03b6c11fa2903 to try this again. I saw exactly the same behaviour as before. With this text: ABCDEFGHIJKLMNOPQRSTUVWXYZ ABCDEFGHIJKLMNOP abcdefghijkl If you place the cursor at the end of the first line, use the arrow keys to move the cursor down 2 lines and then back up again, it will end up between L and M. Interestingly, trying the same thing while typing this message on the website, it behaves as it should. When I move the cursor back up with the arrow key it returns to exactly where it started, as it should.
I confirm issue in current 4.1.1.2 and in older releases up to 3.6.0.4, while it works fine in 3.5.7.2 and earlier releases, hence this is a regression of early 3.6 branch. if you click very fast the "up" and "down" arrow keys the cursor keeps the correct last character position at every line regardless of its length instead if you click those arrow keys slowly, letting the cursor blink, the cursor position starts to follow the last character position of the shorter line as reported by Patrick @Ivan Timofeev it's this something in your field of should I ping Writer experts?
(In reply to comment #3) > it's this something in your field No, I can't help here.
Having bibisect results would be great I think.
6091cff9527caea089e10f9bea3d3226e396b2c6 is the first bad commit commit 6091cff9527caea089e10f9bea3d3226e396b2c6 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Sun Dec 9 12:51:45 2012 +0000 source-hash-c77918bb03974ff9be90c889f77e62ea0755052f commit c77918bb03974ff9be90c889f77e62ea0755052f Author: Fridrich Štrba <fridrich.strba@bluewin.ch> AuthorDate: Fri May 25 16:46:41 2012 +0200 Commit: Fridrich Štrba <fridrich.strba@bluewin.ch> CommitDate: Fri May 25 16:47:23 2012 +0200 Revert "Make SotStorage and SotStorageStream dtors public" This reverts commit 90f3840e4c767154266c6be1c532f5e748e8c3f7. :100644 100644 47fc08bcb6b81a39c425a16ee19220b7b637afa4 2ad69d587a3dbb530b124ca188a9aacbe13e566a M ccache.log :100644 100644 9bc93b355bcfaa521aa0ca3588d0268bd9f2c48e 24f4193db656f1c3bd7c23c41ef8fe621b6bf939 M commitmsg :100644 100644 bede6e618b464a611e192c4934b53da1693b81e2 b6897ddf2de6a28990f99b99f11ef442d0763ced M dev-install.log :100644 100644 4a031992d23365ca44f90dfb60b91b27fdcc0e93 37937bba561b73fa49b90c06110eecd1c6086d30 M make.log :040000 040000 5d57d976d13f21bb45270c905ebfc3707d3bcc87 203c334b30e41b02d037d5e0713c725884e10297 M opt # bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4 # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # bad: [16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9] source-hash-099198a4224778fe6e43f5dc13b5b9b1b4dc828c git bisect bad 16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9 # good: [598083cdb5699e7f45183da8b750815f62ff5485] source-hash-ecb1599ad00e71dfe05f3ae9a71bdce5f7540a40 git bisect good 598083cdb5699e7f45183da8b750815f62ff5485 # good: [cc1fc072dd691da3da43742dfc3fdd126157257b] source-hash-18c661f715a0b6850d30b374e5556dc14a377d2b git bisect good cc1fc072dd691da3da43742dfc3fdd126157257b # good: [fb0ce84a03588593a081ac3a26b2ada2d960b76c] source-hash-1aa91a2d8e7db5cebff5b47f3005f1acff64d25e git bisect good fb0ce84a03588593a081ac3a26b2ada2d960b76c # good: [d9be4b56c2e61bb94c677582dc92419f8468a927] source-hash-ef7a460fa51140782b7ad4d87aa782ca007c56ca git bisect good d9be4b56c2e61bb94c677582dc92419f8468a927 # good: [6d6e5252d2c81fa930cb89f3eaf0efadf09cb87f] source-hash-e3633f60b349022994e291aa3d1a0c90c3403b2e git bisect good 6d6e5252d2c81fa930cb89f3eaf0efadf09cb87f # good: [d51fc64c5993aab4a267af8b9425b2b24c2cd3ce] source-hash-877c96a601e6e50d0c7a8f704d57baec22f089c5 git bisect good d51fc64c5993aab4a267af8b9425b2b24c2cd3ce # bad: [5478f58adef21d3378257c60396d29a8653bafd3] source-hash-c52ba433491afbca70aa1977a624c795bdd5b9ef git bisect bad 5478f58adef21d3378257c60396d29a8653bafd3 # bad: [6091cff9527caea089e10f9bea3d3226e396b2c6] source-hash-c77918bb03974ff9be90c889f77e62ea0755052f git bisect bad 6091cff9527caea089e10f9bea3d3226e396b2c6 # first bad commit: [6091cff9527caea089e10f9bea3d3226e396b2c6] source-hash-c77918bb03974ff9be90c889f77e62ea0755052f
Restricted my LibreOffice hacking area
Bulk change: Bibisected bugs can be assumed to be regressions.
Freeing this bug. Björn if you still want to work on this, please re-take. Version: 5.1.0.0.alpha1+ Build ID: 571f0abb95e1d4aa1cb7cad20b783b17ba7ac99d TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2015-06-29_23:42:31 Locale: de-DE (de.UTF-8) Since there is no specific commit fixing this issue, setting to WORKSFORME. FIXED is used only when a commit exists. Feel free to reopen this issue if you still can reproduce this particular problem or if I did miss something peculiar.
@steve the bug was always reported against Windows so I'll check tonight if it's gone for good... your test was done on Mac so in case of a Windows specific issue we cannot be sure that it's fixed in other O/S as well
retested under Win8.1 x64 bug is not present anymore in 4.4.3.2 and recent 5.1.0.0 alpha so it's really RESOLVED WORKSFORME on Windows as well
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]