I’m not a great typist and too frequently fumble finger and find myself some weird place in my document with no way to get back without more or less searching through the whole thing. Please consider a hot key that takes the view and cursor back one position.
Use the Navigation toolbar for this purpose (View > Toolbars > Navigation) or assign the commands .uno:NavigateForward / .uno:NavigateBack to your preferred shortcuts.
*** Bug 168291 has been marked as a duplicate of this bug. ***
(In reply to Heiko Tietze from comment #2) > *** Bug 168291 has been marked as a duplicate of this bug. *** We decided to keep the commands for user-customization reassess the situation if more users request a default situation
Bugzilla: Thanks! Works For Me too now that the secret mystic (yes, tongue in cheek) name for the function has been revealed. I would like to suggest that the bug be morphed into a documentation bug. The reason I couldn’t find this feature is because it is described only as ‘Back’. Back what? (with tongue still in cheek). Back page? Back paragraph? Backwards? Back garden? Back to the future? May I suggest that the navigation feature be given a more descriptive name? Perhaps ‘Return Cursor to Previous Position’. It’s kind of wordy but some of the other features have multi-word descriptions and searching the documentation might be more likely to find it. I suggest that the description and help documentation should at least contain the words ‘Return’ and ‘Previous’. Again, Thank You for solving my problem.
(In reply to Hindmost from comment #4) > I would like to suggest that the bug be morphed into a documentation bug. Changed the component
*** Bug 169479 has been marked as a duplicate of this bug. ***
See also Bug 134200 - UI: Alt + left/right arrow keys shortcuts to adjust column width cannot be eliminated
(In reply to Heiko Tietze from comment #1) > Use the Navigation toolbar for this purpose (View > Toolbars > Navigation) I consider this unoptimal solution because it takes an entire new toolbar line of UI space away from the content. And that is just for two small arrow icons. I think these could be included by the default (besides the redo/undo buttons). Keeping the navigator in the recency mode takes even more UI space and it is slow to navigate if you have to change the mode. Also, if my proposal about changing navigation back function to first make sure the cursor is visible (Bug 169480) gets accepted, then the navigate back feature becomes more useful than before, which could justify a more prominent placement / shortcuts.
(In reply to devseppala from comment #8) > I consider this unoptimal solution because it takes an entire new toolbar > line of UI space away from the content. And that is just for two small arrow > icons. I think these could be included by the default (besides the redo/undo > buttons). You can dock this toolbar before or after any other, no need to have an extra row. Or just customize the two buttons where you want it.
(In reply to Heiko Tietze from comment #9) > You can dock this toolbar before or after any other, no need to have an > extra row. Or just customize the two buttons where you want it. Thanks for the tip. I had previously tried to do it, but had not succeeded in it. Now tried it again and realized that I had the "Lock Toolbars" enabled (propably default setting) and after removing it I managed to modify toolbar locations, doh! Also managed eventually to do it by the "Customize" route. I consider my self as a pretty competent IT-professional, and if I was fooled by this, then the 'Benjamins' will have a hard time doing this. The Benjamins are the bulk of the users and in order to attract them as users, things need to work out of the box without much fiddling. This is why I would advocate the <alt>+<left/rigth> hotkeys for navigation, because they are adopted by so many programs for navigation. Hotkeys/shortcuts are powerfull tools, but when the same key-combos are adopted universally by all programs (like <ctrl><c>/<v>), they give users superpowers ;)
(In reply to Heiko Tietze from comment #5) > (In reply to Hindmost from comment #4) > > I would like to suggest that the bug be morphed into a documentation bug. > Changed the component But nothing will happen because the Status of this ticket is “Resolved”. Better to open a new ticket for the documentation request.