Bug 416229 - Zooming out with CTRL+mousewheel does not work correctly anymore
Summary: Zooming out with CTRL+mousewheel does not work correctly anymore
Status: RESOLVED DUPLICATE of bug 342003
Alias: None
Product: okular
Classification: Applications
Component: general (show other bugs)
Version: 1.9.1
Platform: Neon Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-14 08:47 UTC by John van Spaandonk
Modified: 2020-01-16 21:42 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John van Spaandonk 2020-01-14 08:47:30 UTC
SUMMARY
Zooming with CTRL+mousewheel does not work correctly anymore since a while ago.
This behavior changed somewhere in the last half year.

STEPS TO REPRODUCE
1. Open a document in Okular
2. Try to zoom out by holding the CTRL key and rolling the mouse wheel towards you

OBSERVED RESULT
Loosely speaking, Okular can zoom in but cannot zoom out, after zooming in I observe the values in the "zoom input box" under the menu bar jump to "fit width"  and after that I cannot zoom out further than that.

More details (help you find the bug):
After I select 17% zoom value, I can zoom in and out, but if I zoom in past the "fit page" value, then that value becomes the maximum: I cannot zoom out any further.
When I then zoom in still further I meet the "fit width" value and then that value becomes the maximum: I cannot zoom out any further.

So you can zoom in, but cannot zoom out past the fixed values in the "zoom box"  that you encounter along the way.

So somehow when these values are selected, the zooming with the keyboard/mouse is affected.

EXPECTED RESULT
I should be able to zoom all the way out until the maximum value is reached.

SOFTWARE/OS VERSIONS

Linux/KDE Plasma: neon
(available in About System)
KDE Plasma Version: 5.17.5
KDE Frameworks Version: 5.66.0
Qt Version: 5.13.2

ADDITIONAL INFORMATION
1. Zooming in and out in Firefox with CTRL + mouse wheel works as expected
2. I can zoom by selecting (using the mouse) an explicit zoom value in the "zoom input box". So it is just using the described keys that does not work with Okular, reducing its usability (accessibility).
Comment 1 Oliver Sander 2020-01-14 16:05:05 UTC
I cannot reproduce this with Okular from the current git master.  Zoom with ctrl+mouse wheel seems to work as expected.
Comment 2 Yuri Chornoivan 2020-01-14 17:17:08 UTC
Can you tell if the "View -> Trim view -> Trim margins" menu item is selected?

Thanks in advance for your answer.
Comment 3 Albert Astals Cid 2020-01-14 22:43:23 UTC
waiting for the trim margins answer
Comment 4 Nate Graham 2020-01-14 23:10:28 UTC
Works for me too with git master when not using Trim Margins.
Comment 5 John van Spaandonk 2020-01-15 08:45:16 UTC
On 2020-01-14 18:17, Yuri Chornoivan wrote:
> https://bugs.kde.org/show_bug.cgi?id=416229
>
> Yuri Chornoivan <yurchor@ukr.net> changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                   CC|                            |yurchor@ukr.net
>
> --- Comment #2 from Yuri Chornoivan <yurchor@ukr.net> ---
> Can you tell if the "View -> Trim view -> Trim margins" menu item is selected?
>
> Thanks in advance for your answer.
>
Yes indeed, If I deselect "Trim Margins" and also do not select "Trim to 
selection" it works as expected.
I will close this report then.
In all honesty, while I now understand the behavior, my honest 
expectation was that the keyboard controls for zoom would always zoom, 
overriding / disabling any trim views. But I understand why you see the 
keyboard controls as mirroring the behavior of the "zoom level" window, 
and not overriding other settings.
ps. I am very happy that you react instantaneously to this bug report.
Comment 6 John van Spaandonk 2020-01-15 08:49:31 UTC
(In reply to Yuri Chornoivan from comment #2)
> Can you tell if the "View -> Trim view -> Trim margins" menu item is
> selected?
> 
> Thanks in advance for your answer.

[this reply might be double with another reply I did via email but I changed it a bit]
Yes indeed, If I deselect "Trim Margins" and also do not select "Trim to selection" it works as expected.

Please close this bug report if you do not agree to the suggestion below.

I still think this is a usability issue.
While I now understand the behavior, my honest expectation was that the keyboard controls for zoom would always mirror the behavior of the "zoom level" box, so overriding any trim views. 

I think it makes perfect sense if the keyboard controls just mirror making a selection in the "zoom level" window. Therefore they should have the same freedom in entering another zoom level, irrespective of the selected "zoom to" option.
ps. I am very happy that you react instantaneously to this bug report.
Comment 7 Albert Astals Cid 2020-01-15 21:42:28 UTC
I guess then we can mark it as duplicate.

At some point we should either remove trim margins or someone should fix all its bugs

*** This bug has been marked as a duplicate of bug 342003 ***
Comment 8 Oliver Sander 2020-01-16 13:58:27 UTC
> At some point we should either remove trim margins or someone should fix all its bugs

BTW: Where is the code that determines what the margin is?
Comment 9 Albert Astals Cid 2020-01-16 21:42:39 UTC
(In reply to Oliver Sander from comment #8)
> > At some point we should either remove trim margins or someone should fix all its bugs
> 
> BTW: Where is the code that determines what the margin is?

Utils::imageBoundingBox

But I don't think there's any bug there, that code is relatively simple.

The code for this bug is probably somewhere else that gets confused when calculating the zoom.

There's also lots of other bugs related to handling of size of pages since they are no longer the size we expect them to be once you trim the margins.