Description: If you select the zoom to view the entire page, pressing PgUp or PgDn should advance or rewind exactly one page, and it is not. I do not know if there is any configuration parameter to correct this. Greetings Actual Results: N/A Expected Results: N/A Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.76 Safari/537.36
At 100% zoom, with default single-page view, the Page-Down & Page-Up accelerators should move the document canvas in full page views. Similar to the page movement implemented in the Navigator Sidebar deck.
That's an old bug inherited from OpenOffice.org https://bz.apache.org/ooo/show_bug.cgi?id=88716 (Page Up and Page Down doesn't scroll a full page the first time)
*** Bug 90005 has been marked as a duplicate of this bug. ***
*** Bug 115979 has been marked as a duplicate of this bug. ***
With work on bug 101211 to provide UNO commands for customization assignment to move to Next Page / Previoous Page -- leaving default pgDn/pgUp under os/DE control for scrolling AND consistent selection use; no longer see the advantage to grabbing control of the PgUp / PgDwn key bindings uniquely for Single Page mode. Suggests another default shortcut binding perhaps <Ctrl>+PgUp/<Ctrl>+PgDwn might be the better choice--with the UNO command available to customize for other page modes.
*** Bug 133314 has been marked as a duplicate of this bug. ***
Ctrl+PgUp/PgDown are bound to "To Header" and "To Footer", quite handy shortcuts. But Alt+PgUp/PgDown are free and are perfectly suited. .uno:GoToStartOfNextPage / .uno:GoToStartOfPrevPage PAGEDOWN_MOD2/PAGEUP_MOD2 in officecfg/registry/data/org/openoffice/Office/Accelerators.xcu We could also bind the corresponding selection commands .uno:GoToStartOfNextPageSel / .uno:GoToStartOfPrevPageSel PAGEDOWN_SHIFT_MOD2/PAGEUP_SHIFT_MOD2 Please also add a nice tip of the day in cui/inc/tipoftheday.hrc
*** Bug 134961 has been marked as a duplicate of this bug. ***
diwanshu885 committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b2cb08e0a0fc09cfe48006a45acc346deb279576 tdf#105776 Add page-down & page-up navigation It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 141443 has been marked as a duplicate of this bug. ***
Copied from my comment in Bug 141443 : Hmmm... You can "consider" PgUp and PgDn as "scrolling" but the users don't! Making Alt-PgUp and Alt-PgDn working as PgUp and PgDn should have been working is completely anti-intuitive! The very names of the keys are exactly "Page Up" and "Page Down", and that's what is expected of them to do. If you want "scrolling" that much with these keys, then the Alt- versions should have been assigned so, not the bare keys alone.
(In reply to al20878 from comment #11) > Copied from my comment in Bug 141443 : > > Hmmm... You can "consider" PgUp and PgDn as "scrolling" but the users > don't! Making Alt-PgUp and Alt-PgDn working as PgUp and PgDn should have > been working is completely anti-intuitive! The very names of the keys are > exactly "Page Up" and "Page Down", and that's what is expected of them to > do. If you want "scrolling" that much with these keys, then the Alt- > versions should have been assigned so, not the bare keys alone. Sorry, but that is what you get to work with. Also, think about the effect of PgDn/PgUp when used in Calc, or Draw, or Impress. We opted for consistency, cross module. The <Alt>+<PgDn>/<Alt>+<PgUp> (with <Shift> mods for selection) are appropriate.
> Sorry, but that is what you get to work with. Very strange, why? > Also, think about the effect of PgDn/PgUp when used in Calc, or Draw, or Impress. I'm only talking about the Writer where the document separation into pages is natural and obvious. It's like browsing a paper version -- you use PgUp and PgDn to quickly get to a page of interest -- having to hold Alt with that is really awkward. Also, who would want "scrolling" if the page is already fully fitting its viewport? It's a different story if it doesn't, though: then sure, go ahead and scroll it with how it currently handles it.
(In reply to al20878 from comment #13) > > Sorry, but that is what you get to work with. > > Very strange, why? Implementers choice. And for folks who prefer, now able (with work on bug 101211) to use the Tools -> Customize... dialog to reassign the Keyboard shortcuts from defaults. Default keyboard assignments are: PdDn -- .uno:PageDown (view port dependent scroll) PgUp -- .uno:PageUp (view port dependent scroll) <Alt><PgDn> -- .uno:GoToStartOfNextPage <Alt>+<PgUp> -- .uno:GoToStartOfPrevPage With <Shift> assignments to include selection. <Ctl>+<PgDn> -- .uno:JumpToFooter <Ctl>+<PgUp> -- .uno:JumpToHeader All can be customized to Keyboard shortcut, Menu, Context Menu or Toolbar.
> Implementers choice. Hmmm... Lame. How about users? > Tools -> Customize... dialog to reassign the Keyboard shortcuts from defaults. Do you really think that's a user-friendly approach?
(In reply to al20878 from comment #15) > > Implementers choice. > > Hmmm... Lame. How about users? > Code submission is welcome... > > Tools -> Customize... dialog to reassign the Keyboard shortcuts from defaults. > > Do you really think that's a user-friendly approach? Yes
> Code submission is welcome... Oh wow. My mom can't do that, sorry > > Do you really think that's a user-friendly approach? > Yes Sad. Obviously no UX