to reproduce this problem create new Writer document and create there table with 200 rows. Then place cursor in first cell of table and press Ctrl-A. Then press key with arrow on keyboard. Cursor appears in last row of table.
This problem can seriously decrease productivity of users because after each selection of all table they will lose position in table, where they are working. It is especially important when working with huge tables. Even appears danger that user places cursor in wrong cell after selecting all table and makes mistake.
produced on Mandriva 64 bit and windows XP 32 bit using LibreOffice 184.108.40.206 and 220.127.116.11rc1
[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:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
reproduced on LibO 3.5.0 beta 1
Can reproduce the behaviour on Master (to-be 3.6, b878715-39746e8-4a486bf-76be866), but I believe this is not a bug, and instead expected behaviour that prevents worse from happening.
I say that because...
* After selecting text, table cells, ..., the cursor is always put after/before the place that was just selected -- this, in fact, enables selecting stuff continuously
* Ctrl-A behaves like starting a selection at the top left and finishing at the bottom right (debatable, but sensible, I think)
* if, after Ctrl-A, the cursor were now set somewhere in the middle of the table that would completely break selecting via keyboard
So, unless there's something clever we could do that does not break keyboard navigation, I'd recommend resolving this as WONTFIX.
> * if, after Ctrl-A, the cursor were now set somewhere in the middle of the
> table that would completely break selecting via keyboard
My be move cursor in last cell but not scroll to last cell. Goal is than user not lost cell where previously worked.
That might be a solution...
Still, the current behaviour is consistent across texts and tables and is also consistent with what would happen if you'd select a table from top to bottom. So, I still don't see much reason for someone to implement what you propose.