https://bugs.documentfoundation.org/show_bug.cgi?id=169480

--- Comment #2 from [email protected] ---
Thank you for a very speedy response!

I want to clarify that technically speaking this go back/forward future works
as intended and I do not suggest any modifications to the back/forward stack
management of this feature. I do understand that "scrolling" the document does
not drop a 'Recency' event and I fully agree that it should not.

Only thing I am suggesting is, that in order to make this functionality more
intuitive and useful for a regular user, there should be a special handling for
situations when a user has scrolled/moved the view so that the cursor is no
longer visible. To handle this, the function go back should check if the cursor
is in the view and if not, then scroll/move the view to make the cursor visible
without any manipulation of the back/forward stack. 

Consider the following:

1. user scrolls to paragraph 20 and modifies/inputs some text
2. user scrolls to paragraph 40 and modifies/inputs some text
3. user scrolls to paragraph 60 to read some text and then wants to change the
previously written text to paragraph 40

Under the current implementation, if the user now presses the back button, then
the user is taken straight to paragraph 20, which I think this is not what most
would expect in this situation. The previous paragraph the user was editing was
paragraph 40 and most users would expect to go back there. 

Yes, the user could go back to the expected place (paragraph 40) by just
clicking mouse somewhere and press the go back button after that. The problem
is, that 99,99% of users would not know that. Also, why would you require the
user to do that, if this could be handled automatically with a small change to
the code.

With my suggestion, the go back function would check that cursor is not in the
view and the go anywhere where back/forward stack pointer points to, without
changing the stack in any way. Now, if the user would press back button again,
while the cursor is visible, the back function would goto paragraph 20 and
update the stack as it allways has.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Reply via email to