SUMMARY Navigating a PDF document (probably any other content too) doesn't work properly in okular 1.10.1 with Qt 5.15-rc2, Frameworks 5.70, Plasma 5.18.90. The right-hand scrollbar works. As does grabbing the PDF with the mouse and moving it up and down. But all other ways to move around in the PDF seem to be ignored: mousewheel on the pdf, arrow keys, trying to move the focus in the thumbnails panel, PageUp/PageDown keys, ... There are no error messages in the konsole session from which okular was started. Chances are for some reason okular isn't getting the relevant events when Qt 5.15-rc2 is used. STEPS TO REPRODUCE 1. Update to Qt 5.15-rc2 2. Run okular 3. Try to navigate the document OBSERVED RESULT Mousewheel on the pdf, arrow keys, trying to move the focus in the thumbnails panel, PageUp/PageDown keys, ... do nothing EXPECTED RESULT Mousewheel on the pdf, arrow keys, trying to move the focus in the thumbnails panel, PageUp/PageDown keys, ... work as they always did SOFTWARE/OS VERSIONS Linux/KDE Plasma: kernel 5.7-rc5, glibc 2.31, clang 10.0.1 KDE Plasma Version: 5.18.90 KDE Frameworks Version: 5.70 (with components that have had a 5.70.1 release updated to 5.70.1) Qt Version: 5.15-rc2 ADDITIONAL INFORMATION Chances are for some reason okular isn't getting the relevant events when Qt 5.15-rc2 is used - other applications are not showing similar issues, so chances are it is a changed behavior that needs to be worked around in okular rather than a Qt 5.15 bug.
Just tested as per Albert's request, can't reproduce. Running all fresh master, Qt from: commit 5f03b84e6542f00cf9eccd1d8820f423cee5e2b9 (HEAD -> 5.15, origin/5.15) Author: Heikki Halmet <heikki.halmet@qt.io> Date: Tue Apr 28 14:53:47 2020 +0300
Also can't reproduce on Qt 5.15. Okular is working great for me.
How about toggling Continuous in various places? See Bug 421399.
Finally got around to bisecting this. The culprit is commit 51b90ecd73e37b9646d8a4bbb51e4fa815942912 Author: kezi olio <keziolio123+@gmail.com> Date: Fri Nov 15 16:08:25 2019 +0000 Add kinetic scrolling & smooth navigation with cursor keys
Not a surprise, that patch breaks everything.
The problem seems to be d->scroller->scrollTo(d->scroller->finalPosition() + QPoint(0, 100 * nSteps), 0); in slotScrollDown() in ui/pageview.cpp not having any effect (even though nSteps == 1) when it is called by the keyboard event and wheel event handlers. I've never used QScroller, so I'm not familiar with its internals -- but at a first glance, looks like a Qt bug and makes me wonder why others aren't seeing this (we're using stock qt 5.15).
Created attachment 130671 [details] Partial revert that fixes it The attached patch, a partial revert of the problematic commit, "fixes" the issue (but of course destroys the advantages of using QScroller). I'll keep this in our package until the real problem is sorted out, it's not perfect but better than nothing, at least it restores what was working in 19.12.x
As much as I like the smooth animated scrolling in principle, I think we need to revert those commits and focus on another approach. They just caused too many regressions. :/ Albert, I'd be in favor of doing this for the 20.12 release. What do you think?
(In reply to Nate Graham from comment #8) > Albert, I'd be in favor of doing this for the 20.12 release. What do you > think? Yes, i think they should be reverted, but i was outvoted in the discussion we had in the mailing list to do it for 20.08 Maybe you can join the Okular BoF in Akademy when i plan to bring it up again https://share.kde.org/s/DXtxMkLrPGwHgKA
Still occurs with 20.11.80
Created attachment 133543 [details] Updated patch Updated patch for 20.11.80. Still probably not the best fix since it reverts the QScroller changes, but at least it makes scrolling work.
I've also been having this problem for probably over a year. I'm using Qt 5.15.2, Frameworks 5.79.0, and Okular 20.12.2 on Gentoo. I can't scroll using the mouse wheel, arrow keys, page up/down buttons, navigating to a page by entering the page number and hitting enter, or clicking on clicking/dragging on the thumbnails on the right. As a workaround, I've been scrolling by clicking and dragging on the document itself in "Browse" mode.
Created attachment 136944 [details] Patch for 21.03.80 The problem still persists in 21.03.80. Attaching updated workaround.
Bernhard and abulhair seem to be the only ones who stated to have this problem. @Nate, you confirmed this bug, how did you reproduce it? @Bernhard, you seem to be able to compile Okular. Can you run the autotests and post the results? Maybe that gives us some insight. Additionally, can you run the autotests provided in https://bugreports.qt.io/browse/QTBUG-88249 (and maybe https://bugreports.qt.io/browse/QTBUG-88249 )? These are not made for this problem, but AFAIR do some debugging output on QScroller. Additionally, can you check whether the problem persists if you uncheck “Use smooth scrolling” in the config dialog? A guess on the problem source: QScroller internally relies on QScreen properties. If your physical screen reports some very wrong properties, QScroller doesn’t work.
The problem can be reproduced by disabling scrollbars in Okular's config window. My guess is that internally, this stops the creation of the QScroller widget that now handles all scrolling. Are the rest of you who are experiencing the problem also disabling scrollbars, or is this a separate issue? I know we also have Bug 421822, but when scrollbars are disabled, I get the full set of symptoms indicated in this bug report, not just pageup/pagedown being broken.
I have "show scrollbars" enabled in the Okular config window. I tried experimenting with "Use smooth scrolling" but the behavior is the same. I am able to scroll using the scrollbars. Interestingly, the mouse wheel scroll works if the cursor is over the scrollbar, but not when it's over the document.
(In reply to Nate Graham from comment #15) > The problem can be reproduced by disabling scrollbars in Okular's config > window. [...] I know we also have Bug 421822, but > when scrollbars are disabled, I get the full set of symptoms indicated in > this bug report, not just pageup/pagedown being broken. Can’t reproduce. When I disable scrollbars, only Page Up/Down are affected. Just by chance: I have a 1920x1080 screen at 131.25%. Do you have a second screen, possibly a rotated one to the right? ;)
No xD It happens on both of my Plasma systems: one is a laptop with a single monitor, and the other is a desktop connected to a Denon receiver via HDMI (so Plasma thinks it's a second monitor). I'm using X and not Wayland.
Created attachment 137213 [details] Okular autotest results I'm running Gentoo, so I just compiled the okular tests and ran them.
Thanks! No fails related to QScroller visible. But what’s with “parttest”? ctest didn’t run it, or cmake didn’t compile it? Maybe we can try to look at internal values of QScroller. You will need to install debugging symbols for (at least) Qt5 and Okular. On ubuntu, they are called: libqt5core5a-dbgsym, libqt5gui5-dbgsym, libqt5widgets5-dbgsym, okular-dbgsym. I don’t know how Gentoo works, possible that you don’t need them. Then run: > $ gdb okular > (gdb) set pagination off > (gdb) run > no open a document in Okular and reproduce the bug > ^C (hit Ctrl+C) > (gdb) breakpoint QScroller::scrollTo > (gdb) continue > now reproduce the bug > (gdb) print -pretty on -- *this->d_ptr I will look later at QScroller to see what these values mean. ;)
Apparently parttest seems to have been excluded by Gentoo (https://bugs.gentoo.org/641728), along with mainshelltest, chmgeneratortest, parttest, and annotationtoolbartest. Sure I'll try running okular with gdb now.
Mistake: Instead of this: >breakpoint QScroller::scrollTo it is called this: >break QScroller::scrollTo(QPointF const&, int)
Created attachment 137231 [details] gdb output For some reason there wasn't a symbol 'this' in the QScroller::scrollTo frame (maybe I didn't correctly compile with debug symbols), but I went one frame up to PageView::slotScrollDown (okular-20.12.3/part/pageview.cpp:4831) and did 'print -pretty on -- *d->scroller->d_ptr'. The output of this command is attached. The breakpoint fired when I tried to scroll down with the mouse wheel.
(In reply to David Hurka from comment #22) > Mistake: Instead of this: > > >breakpoint QScroller::scrollTo > it is called this: > > >break QScroller::scrollTo(QPointF const&, int) Ah this worked but the output is the same as before (aside from some differences in pointers in 'xSegments').
Actually I think I may have inadvertently fixed my issue. I tried recompiling all of qtcore, qtwidgets, and okular with debug symbols as well as disabling all optimization and now it's scrolling correctly! I suspect it's one of the optimizations causing the bug. Give me some time to tinker and find exactly which one.
I found the bug, for me, was being caused by compiling qtcore with the flag -ffinite-math-only. I had previously ruled out optimization flags as being the cause since I had recompiled okular and qtwidgets with no optimizations and the bug persisted, and when I saw this reported bug, I thought it must be caused by something else. But I don't know if this is the cause of the issue for Bernhard or others.
Awesome! :) I think QScroller shouldn’t break because of floating point inaccuracy. But its complicated floating point calculations make it seem possible to me. What does -ffinite-math-only mean? That stuff like qNaN does not work, because it is not a finite floating point number? Then QScroller can’t work. Thanks for the gdb output anyway.
Yeah, the compiler assumes that no floating point number is NaN or inf, so it can make optimizations like: `x == x` -> `true`, `x * 1` -> `x`, etc. But I think functions like `isnan` or `isinf` will still work correctly.
Confirmed, it's caused by compiler flags in qtcore.
Which ones?