I don't think this is a bug, as far as I remember we never had scrollwheel changing the page, because if we do, then people complain about it because they never can read properly the end of the page because a bit more of scrollwheel changes the page.

In my opinion, at most this would be a wish, but would need some real thinking on how to implement it properly so that it's not horrible to use.

Here, scroll wheel always changed the page in non-continuous mode. If the end of the page is nearer than one scroll step, it scrolls only to the end, and the next scroll step goes to the next page.

The problem is with continuous (stepless, non-discrete) scrolling. Scrolling on one page works as expected (per-pixel scrolling), and scrolling from the end of one page to the next page requires at least 15° in one wheel event, which is awkward with continuous scrolling devices.

@Rafa: Are the mentioned mice such continuously scrolling ones?

The problem arises for both, continuous and discrete scrolling. I've been using this functionality for many years without issues. It's very useful to deal for example with PDF files with many page transitions such as the ones generated by latex and the beamer class.

Actually, the scroll takes place (full page view and continuous view) if the mousewheel is rotated very fast, but this is useless for me since I cannot control how many pages move forward or backward.

As I understand these mice, you can add/remove some part or flip a lever that makes the mouse wheel physically spin continuously or in steps. If you change only the mouse wheel to spin in steps, that is maybe not be enough, because the mouse could still sends events for every sub-step.

To check if there is confusion in this area, you can try to use the up/down arrow keys. These are handled the same way as purely discrete mouse wheel events.

(In reply to David Hurka from comment #4)
> As I understand these mice, you can add/remove some part or flip a lever
> that makes the mouse wheel physically spin continuously or in steps. If you
> change only the mouse wheel to spin in steps, that is maybe not be enough,
> because the mouse could still sends events for every sub-step.
> 
> To check if there is confusion in this area, you can try to use the up/down
> arrow keys. These are handled the same way as purely discrete mouse wheel
> events.

Up and down arrow keys work as expected so the problem might be related to my distro (Manjaro).

Same problem here  in a recent upgrade to Kubuntu jammy.

(In reply to kioftes from comment #6)
> Same problem here  in a recent upgrade to Kubuntu jammy.

Btw, I am using a wireless Logitech mouse running Okular v21.12.3. But the same happens with the touchpad of my laptop. And there is also a strange issue: if I scroll really fast (which is easier with two-finger scrolling on the touchpad) then the document scrolls, but it is not possible to control the speed of scrolling (have to scroll really fast).

Is it possible to change the category of the bug to clear the case that it affects multiple distributions and not only manjaro?

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

I tried going back to 21.12.3 in Kubuntu 22.04 from 22.04.2 and that still has issues with the mousewheel scrolling, so could something else be causing this?

Same problem on my machine using Kubuntu 22.04 stock version or latest flatpak 22.04.02 version of Okula on my M720 and MX Master 3
The problem happens if the mouse is configured using libinput. And I could scroll pages if I scroll the mouse wheel really fast, but impossible to control like kioftes described.
If the mouse is configured using evdev, the scroll works as expected. It scrolls one page per one mouse scroll click. But by switching to evdev I lost the high resolution scroll capability for the whole desktop environment.
I guess this problem may be related to high resolution scroll handling.

Here is how I switch the mouse to use evdev.
Add the following lines to /etc/X11/xorg.conf
----- start here -----
Section "InputClass"
    Identifier "evdev-mouse"
    MatchIsPointer "yes"
    Driver "evdev"
EndSection
------ end here -----

I looked into the source code and added few lines to the pageview.cpp to handle the small "delta" value reported in the PageView::wheelEvent for my mice. And now I could scroll in pages in full page view and non-continous mode. (only tested on libinput mode but not in evdev mode)

I don't know how I should request code change. Here's the few lines that I added. Maybe the developers see this and test it or possibly merge into the main branch.

--- okular-21.12.3/part/pageview_orig.cpp	2022-02-28 02:11:02.000000000 +0800
+++ okular-21.12.3/part/pageview.cpp	2022-07-19 00:07:04.332931401 +0800
@@ -3170,22 +3170,32 @@
     if ((e->modifiers() & Qt::ControlModifier) == Qt::ControlModifier) {
         d->controlWheelAccumulatedDelta += delta;
         if (d->controlWheelAccumulatedDelta <= -QWheelEvent::DefaultDeltasPerStep) {
             slotZoomOut();
             d->controlWheelAccumulatedDelta = 0;
         } else if (d->controlWheelAccumulatedDelta >= QWheelEvent::DefaultDeltasPerStep) {
             slotZoomIn();
             d->controlWheelAccumulatedDelta = 0;
         }
     } else {
-        d->controlWheelAccumulatedDelta = 0;
-
+        if (d->controlWheelAccumulatedDelta * delta < 0) {
+            d->controlWheelAccumulatedDelta = 0;
+        }
+        d->controlWheelAccumulatedDelta += delta;
+        if (abs(d->controlWheelAccumulatedDelta) >= QWheelEvent::DefaultDeltasPerStep){
+            delta = d->controlWheelAccumulatedDelta > 0 ? QWheelEvent::DefaultDeltasPerStep : -QWheelEvent::DefaultDeltasPerStep;
+            d->controlWheelAccumulatedDelta = 0;
+        }
+        else {
+            delta = 0;
+        }
+        
         if (delta <= -QWheelEvent::DefaultDeltasPerStep && !getContinuousMode() && vScroll == verticalScrollBar()->maximum()) {
             // go to next page
             if ((int)d->document->currentPage() < d->items.count() - 1) {
                 // more optimized than document->setNextPage and then move view to top
                 Okular::DocumentViewport newViewport = d->document->viewport();
                 newViewport.pageNumber += viewColumns();
                 if (newViewport.pageNumber >= (int)d->items.count())
                     newViewport.pageNumber = d->items.count() - 1;
                 newViewport.rePos.enabled = true;
                 newViewport.rePos.normalizedY = 0.0;

> I don't know how I should request code change

https://community.kde.org/Infrastructure/GitLab#Submitting_a_Merge_Request

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

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

I've the same problem since switching to kubuntu 22.04 (coming from 20.04)
My mouse is a logitech M720

I have the same problem using a Logitech M720.

-----
Kubuntu 22.04
KDE-Plasma-Version: 5.24.7
KDE-Frameworks-Version: 5.92.0
Qt-Version: 5.15.3
Kernel-Version: 5.15.0-58-generic (64-bit)

Hi all, the issue is related to the use of the Logitech dongle. When using Bluetooth there is no problem.

I use the same mouse (Logitech M2S) on two machines. The laptop came first, using BT: never had a problem.
Then I installed a PC, same OS (Debian Bookworm) but I got this same issue. This PC has no BT so I used the dongle and this is when the scrolling issue in okular appeared.
If I use the dongle on the laptop, there's a problem there too.
So those you can use BT, use BT as a work-around.

So I don't know the reason for this, but the issue only comes when using the mouse with its dongle. And it's only okular having this issue, only in page mode. Okular in continuous mode or all other applications are OK.

(In reply to an.inbox from comment #17)
> Hi all, the issue is related to the use of the Logitech dongle. When using
> Bluetooth there is no problem.
> 
> I use the same mouse (Logitech M2S) on two machines. The laptop came first,
> using BT: never had a problem.
> Then I installed a PC, same OS (Debian Bookworm) but I got this same issue.
> This PC has no BT so I used the dongle and this is when the scrolling issue
> in okular appeared.
> If I use the dongle on the laptop, there's a problem there too.
> So those you can use BT, use BT as a work-around.
> 
> So I don't know the reason for this, but the issue only comes when using the
> mouse with its dongle. And it's only okular having this issue, only in page
> mode. Okular in continuous mode or all other applications are OK.

That's great! I've switched to BT (never did that because of laziness) and now this annoying "bug" is gone.
Thanks for this hint!

(In reply to an.inbox from comment #17)
> Hi all, the issue is related to the use of the Logitech dongle. When using
> Bluetooth there is no problem.
> 
> I use the same mouse (Logitech M2S) on two machines. The laptop came first,
> using BT: never had a problem.
> Then I installed a PC, same OS (Debian Bookworm) but I got this same issue.
> This PC has no BT so I used the dongle and this is when the scrolling issue
> in okular appeared.
> If I use the dongle on the laptop, there's a problem there too.
> So those you can use BT, use BT as a work-around.
> 
> So I don't know the reason for this, but the issue only comes when using the
> mouse with its dongle. And it's only okular having this issue, only in page
> mode. Okular in continuous mode or all other applications are OK.

Still not working properly here even with Bluetooth. I have to scroll the wheel quite a bit to get it to move to the next page.

Hi Mark,

I bought a basic USB BT dongle before I saw your comment, and I've been lucky: okular now scrolls fine for me in page mode.

The issue is okular specific, and at the application level how the mouse is connected should not matter: the only thing the application should see are the mouse wheel events. I don't know much in this area, but I fired `xev`, a small application showing X11 events (I'm using KDE with X11). The very weird thing is that I can't see a difference: the same set of events with similar content show up when I scroll the wheel by one click, whether the mouse is connected in BT or through the Logitech dongle. But when I scroll in okular in page mode, it's completely different: perfect with BT, but mostly nothing with the dongle expect a weird jump once in a while when I scroll like mad.

I also checked the output of `xinput list-props` for both cases and except for the device name, node and product id all the other settings are the exact same.

So I'm very puzzled... Not being an expert in GUI and mouse events I don't know what to check. But I have a set-up where it's very easy to switch between OK and KO: I just need to toggle the mouse between two sources. So if someone as suggestions on what to check to understand the difference and help fix this issue, as long as it's not too complex I'll try it.

(In reply to an.inbox from comment #17)

Thank you for noticing that the problem seemed to be related to the mouse itself.  This okular bug has been driving me crazy for the past year or so.  I never associated the start of the issue with my purchase of a new mouse.  I currently use a Logitech MX Master 3, while before I used a MX Master 2.  

As per the suggestions in some previous comments, I tried using my new mouse with bluetooth only instead of the usb wireless dongle.  That did not fix the problem.  I still cannot scroll through a multi-page pdf document with the mousewheel when the okular view option are "single page, non-continuous".  If I scroll a lot, sometime the page will jerk forward to a new one, most of the times not.  

I also have another mouse I use for my laptop.  This is a Logitech Anywhere 2.  I tried this mouse via bluetooth and everything works perfectly.  I can scroll through the document with the mouse wheel.  In fact, I now have both mice connected via bluetooth at the same time and can test both at the same time.  I find that the mx master 3 doesn't scroll while the anywhere 2 does.

I can confirm that this is mouse-related.  Logitech Anywhere 2S works, Logitech Anywhere 3 does not, even though it worked for years.  I am using okular on Fedora Cinnamon, an update last week broke it.  As far as I can tell, the breakage was between okular 23.04.3 and 23.08.3. The issue is annoying, and specific to okular.  So even though the issue is hardware-related, it seems to me that it is okular which is buggy.

This has just started happening for me, so it's not mouse hardware related. When on fit page the mousewheel took me to the next page; now it does not.