I don't understand the problem, do you think you could record the screen a video/gif and maybe that would help me understand what you mean?

Here's a GIF recording of the bug

https://imgur.com/xou5cdA


SOFTWARE/OS VERSIONS

Operating System: Arch Linux 
KDE Plasma Version: 5.18.5
KDE Frameworks Version: 5.70.0
Qt Version: 5.14.2
Kernel Version: 5.4.41-1-lts
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-3770 CPU @ 3.40GHz
Memory: 31.3 GiB of RAM

okular 1.10.1

I still can figure out what is wrong with the video, could you describe second by second what you are doing and what you're expecting it would happen?

Seconds 0-5, scrolling with scroll wheel works normally.
Seconds 5-12, clicking the scroll bar to scroll works as expected until trying to scroll with the scroll wheel. Meaning that scrolling with the scroll wheel after having clicked the scroll bar causes the reader (Okular) to jump back to the position in the document before I clicked on the scroll bar.

After that in the video is a repeat of Seconds 0-12, but I clicked the scroll bar to scroll down. and then up a bit, and ends by scrolling the scroll wheel which still causes the document position to jump to where it was before.

New information was added with comment 4; changing status for inspection.

Ok, now i understood:
 * Start in page 1
 * Left click on the scrollbar below the slider it self until some pages change and say you're now in page 10
 * use the wheel in the viewport (not the scrollbar), you're back to page 1

Another regression caused by the QScroller patches.

I tried to write a unit test for this, but I failed to find a way to send wheel events to the PageView object.  This seems to be a known problem:

   https://stackoverflow.com/questions/50996997/how-to-simulate-mouse-wheel-events-using-qtestlib-qt5

I see TabletEvents being sent in parttest.cpp by calls to

    qApp->notify( qApp, &enterProximityEvent );

but that doesn't seem to work for wheel events.

Is there a secret trick to it, or do we have to live without a test?

(In reply to Oliver Sander from comment #8)
> but I failed to find a way to send wheel events to the PageView object.

xdotool should work. But that would depend on the test environment. If only the GitLab CI can run this test, would that be enough? (Does GitLab run the autotests?)

Thanks, I hadn't heard of of xdotool.  But I need something that works from within the QTest framework.  And yes, gitlab does run the autotests.

This makes the pageview scroll

void PartTest::testWheelInPageView()
{
    QVariantList dummyArgs;
    Okular::Part part(nullptr, nullptr, dummyArgs);
    QVERIFY(openDocument(&part, QStringLiteral(KDESRCDIR "data/file2.pdf")));
    part.widget()->resize(600, 400);
    part.widget()->show();
    QVERIFY(QTest::qWaitForWindowExposed(part.widget()));
    QTest::qWait(3000);
    auto we = new QWheelEvent({}, {}, {}, {0, -150}, Qt::NoButton, Qt::NoModifier, Qt::NoScrollPhase, false);
    QCoreApplication::postEvent(part.m_pageView->viewport(), we);
    QTest::qWait(3000);
}



The QWheelEvent definition is a bit "bogus" in which it doesn't define pos nor globalPos, just abuses the knowledge that PageView::wheelEvent just uses the angleDelta().y()

Thank you!  There is a now a test at

  https://invent.kde.org/graphics/okular/merge_requests/188

This behavior also occurs when scrolling a document while the mouse cursor is over the scrollbar (both horizontal and vertical). Tested on pdf files, text files and images.

A possibly relevant merge request was started @ https://invent.kde.org/graphics/okular/-/merge_requests/292

Git commit 17c266993deda05713171f824669cb4e09a6ee65 by David Hurka.
Committed on 12/10/2020 at 11:16.
Pushed by ngraham into branch 'release/20.08'.

Fix scrolling with scrollbar when the slider is not clicked

This fixes scrolling with the scrollbar,
so it is not reset when scrolling on the viewport afterwards.

PageView’s QSroller was not correctly updated by update_scroller,
because it was connected to QAbstractSlider::sliderMoved and sliderReleased,
which are only emitted while the “slider is down”,
i. e. not when the user scrolls the scrollbar other than dragging the slider.
Now update_scroller is connected to actionTriggered(),
which is emitted for all user interactions.

Note that scrolling using the scrollbar calls QAbstractScrollArea::scrollContentsBy(),
and so bypasses smooth scrolling of the QScroller. This could be considered a feature,
otherwise it is more a bug in Qt than in Okular, because we can not ignore scrollContentsBy().

Steps to reproduce:
1. Open a long document
2. Click on the vertical scrollbar below the slider
3. Okular scrolls one page down
4. Scroll in the viewport
5. Okular starts scrolling from the position from step 1.

Test plan:
* Scroll using scrollbar
  + Click on the vertical scrollbar below the slider
  + Middle-click on the vertical scrollbar below the slider
  + Click on the little arrow of the vertical scrollbar
  + Scroll using a scrolling device (e. g. `xdotool click 4`) on the vertical scrollbar
  + Drag the slider of the scrollbar
* “cross-product” verify QScroller state
  + Scroll using a scrolling device on the viewport
  + Scroll using Browse tool dragging
  + Scroll the viewport by clicking a point in the thumbnails view
  + Scroll the viewport using arrow keys and Page Up/Down keys

M  +7    -4    ui/pageview.cpp

https://invent.kde.org/graphics/okular/commit/17c266993deda05713171f824669cb4e09a6ee65

*** Bug 425376 has been marked as a duplicate of this bug. ***