Description: The page up/page down steps are oddly chosen in Writer Steps to Reproduce: 1. Open the attached file 2. Zoom in so you get the layout as in the screenshot; my case 160% 3. Now press page down (without changing cursor position 4. Now press page down again 5. Scroll up to top again. 6. Put cursor at the position of purple text. en press page up/down Actual Results: First press. Nunc still visible. Second press.. all highlight text gone With cursor at different position the scroll changes again Expected Results: The whole scrolling with page down/page up is terrible unpredictable. If it's relative to cursor. And this madding for orientation within the text Word does behave differently (better) Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: ea4fb1559f7b99a0bfaf18f26cb3b6972c9cde1c CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Created attachment 171144 [details] Example file
Created attachment 171146 [details] Screenshot
Also in LibreOffice 3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
as in dupe, the pgUp / pgDn movements supplement the cursor Up / Down for scrolling. The .uno:PageUp, .uno:PageDown Viewshell movement of the viewport can't be set fixed at full page increments as it needs to vary by the zoom level of the view--or it is no longer a scrolling action. (bug 105576) So for bug 101211 we've implemented the .uno:GoToStartOfNextPage and .uno:GoToStartOfPrevPage and assigned <Alt>+<pgUp>/<Alt>+<pgDn>. The viewport scroll (or with selection) complmenting the Up/Down keys is the greater demand of consistent UI. There is probably some adjustment that could be done to the current .uno:PageUp, .uno:PageDown to viewport positioning glitches like aoo#88716, or bug 141249, or even as here. *** This bug has been marked as a duplicate of bug 81829 ***