SUMMARY In non-continuous scrolling mode, scrolling backwards over a page boundary (either with scroll wheel, Shift-Space or PgUp) has the effect that the top of the previous page is shown. In earlier versions the bottom of the previous page was shown, which is the expected behaviour (so that Scroll Page Down and Scroll Page Up actions are each others' inverses). STEPS TO REPRODUCE 1. Open any pdf with more than one page in Single Page, non-continuous view mode. Size the window so that a vertical scroll bar is showing. 2. Navigate to the top of page 2 (e.g. by pressing the space bar twice) 3. Scroll up (e.g. by pressing Shift-Space or PgUp, or by mouse wheeling up) OBSERVED RESULT Okular displays the topmost part of page 1 EXPECTED RESULT Okular displays the bottommost part of page 1 SOFTWARE/OS VERSIONS Operating System: Debian GNU/Linux KDE Plasma Version: 5.21.5 KDE Frameworks Version: 5.85.0 Qt Version: 5.15.2 Kernel Version: 5.14.4 OS Type: 64-bit Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-7700 CPU @ 3.60GHz Memory: 31.2 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1070/PCIe/SSE2 ADDITIONAL INFORMATION This bug is not present in version 20.12.3, while it appears in 21.08.0 and 21.08.1.
Can not reproduce with Okular 21.08.1 on KDE Neon user edition. Can you provide screenshots or a screencast of the whole window, so we can try to reconstruct more precisely? Can you provide more information on your configuration? Do you have smooth scrolling enabled (if that makes a difference)? (Besides that, this is an excellent bug report. :) )
Created attachment 141621 [details] new4.png Dear David, Thanks for looking at this. I checked, and smooth scrolling does not matter. Here are four screenshots using a random example PDF I found here https://juventudedesporto.cplp.org/files/sample-pdf_9359.pdf To interpret the file names: old is 20.12.3, new is 21.08.0. The four numbers are as follows: 1) after opening Okular, loading the PDF from the command line 2) after pressing Space once (now we're on the bottom of page 1) 3) after pressing Space once more (now we're on the top of page 2) 4) after pressing Shift-Space. now we're either on the top (new) or bottom (old) of page 1. I'm using Plasma on X, not wayland. The fact that you cannot reproduce it makes me think it is a dependency issue. I noticed that upgrade/downgrade of okular pulls in a matching version of libokular5core9, and changes nothing else on the system. Cheers, Wouter On 16/09/2021 22:36, David Hurka wrote: > https://bugs.kde.org/show_bug.cgi?id=442503 > > David Hurka <david.hurka@mailbox.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Resolution|--- |WAITINGFORINFO > Status|REPORTED |NEEDSINFO > > --- Comment #1 from David Hurka <david.hurka@mailbox.org> --- > Can not reproduce with Okular 21.08.1 on KDE Neon user edition. > > Can you provide screenshots or a screencast of the whole window, so we can try > to reconstruct more precisely? > > Can you provide more information on your configuration? Do you have smooth > scrolling enabled (if that makes a difference)? > > (Besides that, this is an excellent bug report. :) ) >
Created attachment 141622 [details] new3.png
Created attachment 141623 [details] new2.png
Created attachment 141624 [details] new1.png
Created attachment 141625 [details] old4.png
Created attachment 141626 [details] old3.png
Created attachment 141627 [details] old2.png
Created attachment 141628 [details] old1.png
Thanks. I think I recreated all preconditions correctly, but unfortunately still can not reproduce the issue. I don’t know what else could be relevant. If you know how to do that, you may build Okular from source and do a git bisect to find the problem. The source is located at https://invent.kde.org/graphics/okular. The README.md contains a description how to build from source. If you are interested, we can help you with that. :)
Dear David, Sure! 61551d2356ea5f93ba3e921a1c4ab9cca88fdbda is the first bad commit commit 61551d2356ea5f93ba3e921a1c4ab9cca88fdbda Author: Gerd Wachsmuth <gerd.wachsmuth@b-tu.de> Date: Thu Apr 1 11:58:53 2021 +0200 Fix: Viewport coords normalized w.r.t. full page The coordinates in Viewport.rePos are normalized on the full page. In two functions within pageview.cpp, these were treated as coordinates on the cropped page. CCBUG: 198427 This partially fixes the bug 198427 in the case that the cropping of the target pages (and the pages around the target) is known at the time the link is clicked. That is, it works if - One uses 'Trim To Selection' - One uses 'Trim To Margin' and has already viewed at the target page(s). In the case that the cropping of the page at the target is unknown, we still end up at the wrong position. autotests/data/pdf_with_internal_links.pdf | Bin 0 -> 60899 bytes autotests/data/pdf_with_internal_links.tex | 9 ++++++ autotests/parttest.cpp | 44 +++++++++++++++++++++++++++++ part/pageview.cpp | 18 +++++++++--- 4 files changed, 67 insertions(+), 4 deletions(-) create mode 100644 autotests/data/pdf_with_internal_links.pdf create mode 100644 autotests/data/pdf_with_internal_links.tex Here is the full log: git bisect start # good: [6f5b23290fdd2ada8e0e7f44ffada02c978d0c6a] presentation: Show better the status of the "playing" button git bisect good 6f5b23290fdd2ada8e0e7f44ffada02c978d0c6a # bad: [4afd21470147dd7b20f21e8edf20e5f350f98df3] ToggleActionMenu::createWidget(): Do not crash if parent is not a QToolBar git bisect bad 4afd21470147dd7b20f21e8edf20e5f350f98df3 # good: [67325270eca8bc5a725a4a0283537b8078d9c1a6] Fix viewport jumps when drag-scrolling beyond screen edges git bisect good 67325270eca8bc5a725a4a0283537b8078d9c1a6 # bad: [b15accd0ae51c68fbd1b1b09a3d12ffcd24a5f55] Checks whether the pdf is broken or not git bisect bad b15accd0ae51c68fbd1b1b09a3d12ffcd24a5f55 # bad: [394001017e9ddfba941fb0fc9162bbfd10c49392] Merge remote-tracking branch 'origin/release/21.04' git bisect bad 394001017e9ddfba941fb0fc9162bbfd10c49392 # good: [6b3da83f69d1d61baf5f056494d4ae809ee41825] Merge remote-tracking branch 'origin/release/21.04' git bisect good 6b3da83f69d1d61baf5f056494d4ae809ee41825 # bad: [61551d2356ea5f93ba3e921a1c4ab9cca88fdbda] Fix: Viewport coords normalized w.r.t. full page git bisect bad 61551d2356ea5f93ba3e921a1c4ab9cca88fdbda # good: [e8e4cd7c6dc28deead28682a876dd0e2e4ef643d] GIT_SILENT Upgrade release service version to 21.04.0. git bisect good e8e4cd7c6dc28deead28682a876dd0e2e4ef643d # good: [ff5f4cbc453d37f5c70e7c31a6c22105cee994fc] Open the signed document on the page with the new signature git bisect good ff5f4cbc453d37f5c70e7c31a6c22105cee994fc # good: [218c5ab64ea2865272a26f18b22c8047226ad957] GIT_SILENT made messages (after extraction) git bisect good 218c5ab64ea2865272a26f18b22c8047226ad957 # first bad commit: [61551d2356ea5f93ba3e921a1c4ab9cca88fdbda] Fix: Viewport coords normalized w.r.t. full page Hope this helps. Cheers, Wouter On 17/09/2021 13:19, David Hurka wrote: > https://bugs.kde.org/show_bug.cgi?id=442503 > > David Hurka <david.hurka@mailbox.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEEDSINFO |REPORTED > Resolution|WAITINGFORINFO |--- > > --- Comment #10 from David Hurka <david.hurka@mailbox.org> --- > Thanks. I think I recreated all preconditions correctly, but unfortunately > still can not reproduce the issue. > > I don’t know what else could be relevant. > > If you know how to do that, you may build Okular from source and do a git > bisect to find the problem. The source is located at > https://invent.kde.org/graphics/okular. The README.md contains a description > how to build from source. If you are interested, we can help you with that. :) >
Wow, you are fast. Yes, this helps! I guess you have View -> Trim View -> Trim to Selection enabled, but you did not select anything, or something similar. I can reproduce the issue when I enable Trim to Selection and select some area.
Dear David, This is to confirm that the bug occurs when trimming is used. I always use Trim Margins. I tested with 21.08.0. Without any Trimming applied, the problem is absent. With Trim Margins as well as with Trim to Selection the problem is present. Cheers, Wouter On 17/09/2021 20:11, David Hurka wrote: > https://bugs.kde.org/show_bug.cgi?id=442503 > > David Hurka <david.hurka@mailbox.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Summary|Scroll Page Up teleports to |Scroll Page Up teleports to > |top of previous page |top of previous page if in > | |non-continuous view and > | |trimmed view > Status|REPORTED |CONFIRMED > Ever confirmed|0 |1 > > --- Comment #12 from David Hurka <david.hurka@mailbox.org> --- > Wow, you are fast. Yes, this helps! > > I guess you have View -> Trim View -> Trim to Selection enabled, but you did > not select anything, or something similar. > > I can reproduce the issue when I enable Trim to Selection and select some area. >