Bug 115781 - The edit cursor should move to the newly added row
Summary: The edit cursor should move to the newly added row
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.7.2 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Cell-Selection
  Show dependency treegraph
 
Reported: 2018-02-16 13:44 UTC by Telesto
Modified: 2018-02-28 19:55 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Example (10.79 KB, application/vnd.oasis.opendocument.text)
2018-02-22 16:25 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2018-02-16 13:44:32 UTC
Description:
Adding a new row (above/below) has no effect on the mouse cursor. I would expect it to move the new row. 




Steps to Reproduce:
1. Open the attached file
2. Add a row below or below the row containing BBB. 

Actual Results:  
Adding a new row has no effect on the mouse cursor

Expected Results:
I would expect it (similar to other text editors)


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 6.1.0.0.alpha0+
Build ID: 3c913c3844acae8ee0d80ab174133bdc7677efea
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-02-14_00:19:27
Locale: nl-NL (nl_NL); Calc: CL


User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Comment 1 Heiko Tietze 2018-02-17 08:58:15 UTC
I would refrain from this convenience feature. Like any other automatic interaction it may result in the opposite. For example you select a column and right click / insert before - wouldn't you expect the selection to be persistent to not loose the overview? So my take here is WONTFIX as the use case is undefined (or just for convenience).

On the other hand Calc works exactly like suggested. Focus stays on B1 when you insert a column left, meaning the cell content is moved to the right. In Writer the focus remains on the current input and the selection moves with the input. (I prefer the Writer way here.)

Opinions?
Comment 2 Telesto 2018-02-22 16:25:07 UTC
Created attachment 140060 [details]
Example

It's a rather small bug, I'm aware of that. I know only one user case. Say, I have small screen device (Windows Surface; iPad, or like a Macbook Air 11 inch). I'm looking at single page table. zoomend in (making it readable). Seeing only half a page (or less). I want to a add a new row, between the existing ones. 
(a) Clicking on the 'add row below' doesn't seem to work; no visual change
(b) I have two swipe to the new row. Which can be hard if the table cell is rather large (key down will work for keyboard, but not for other swipe only devices)
(c) I sometimes want to add a few rows (say 5), so I click on add a new row multiple times. I can't actually how many a added; I have to really count the clicks)
(d) A non argument: It's a bit of a workaround for the table autosave jumping bug. You have to restart of swiping for the freshly added row if the autosave kicks in while swiping..

Another reason I noticed it is because quite a lot of programs do scroll. For example Google Docs, Microsoft Word.
Comment 3 V Stuart Foote 2018-02-27 17:32:03 UTC
In the general case there are uses for supporting such movements in the GUI.

Clearly as here where some movement is needed. And other areas, for example bug 105610, where repositioning the edit cursor focus and panning the view of the document canvas to a consistent position (centered L/R & T/B) is going to be needed.

But think that would need to include dropping a mark/reminder of some sort for a return of positioning (i.e. for using Navigator in Reminder mode).
Comment 4 Cor Nouws 2018-02-27 18:55:37 UTC
(In reply to Telesto from comment #0)
> Adding a new row (above/below) has no effect on the mouse cursor. I would
> expect it to move the new row. 

It does not have in Calc either..
Comment 5 Thomas Lendo 2018-02-28 00:06:01 UTC
Is component 'Writer' the right one? If changed, it should be changed in all components as well as in Calc.

(In reply to Heiko Tietze from comment #1)
> On the other hand Calc works exactly like suggested. Focus stays on B1 when
> you insert a column left, meaning the cell content is moved to the right. In
> Writer the focus remains on the current input and the selection moves with
> the input. (I prefer the Writer way here.)
Calc only works as intended in this bug report if you insert columns left or rows above. Not for columns right and rows below (because in fact the selection doesn't change).

I'm not in favor of changing neither keeping the behavior, I haven't paid attention to this in the past to say what's better.

But if we change it, to which cell should the cursor moving especially in RTL, CTL, CJK languages when several rows/columns are added? In LTR it's the top-left cell I assume. In Calc it's easier as the whole cell selection should move to the newly added rows/columns.
Comment 6 Heiko Tietze 2018-02-28 19:55:02 UTC
Taking into account that any solution would have uncertainties and likely ends up in inconsistent behavior plus the doubts on the use case, the recommendation after discussion in the design meeting is WONTFIX.