I can't reproduce it in

Version: 5.4.0.0.alpha0+
Build ID: 2356bfdb1b99a93fcb35fefc0f587158e7d160c2
CPU threads: 1; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-03-20_00:30:32
Locale: es-ES (es_ES); Calc: group

Can not reproduce on Windows 10 Pro 64-bit en-US with
Version: 5.3.1.2 (x64)
Build ID: e80a0e0fd1875e1696614d24c32df0f95f03deb2
CPU Threads: 8; OS Version: Windows 6.19; UI Render: default [or OpenGL]; Layout Engine: new; 
Locale: en-US (en_US); Calc: group

1. Open attachment 131823 [details]
2. Print preview
3. Ctrl+<Mouse scrollwheel> to zoom preview in or out

correct zoom+/zoom- on scroll wheel movement.

Ctrl+<Mouse scroll> also effective in status bar's multi-page view.

hi buovjaga,
Still reproducible on master?

Does not work in master (Win only).

Win 10
Version: 6.0.0.0.alpha0+ (x64)
Build ID: 2404a17e157273430d40ceaa1ab1275e7b50ba6e
CPU threads: 4; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2017-06-16_23:41:27
Locale: fi-FI (fi_FI); Calc: group

Works in:
Version: 5.3.3.2 (x64)
Build ID: 3d9a8b4b4e538a85e0782bd6c2d430bafe583448
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; 
Locale: fi-FI (fi_FI); Calc: group

Also no repro on Windows 7 and Windows 10 with LO 6.0+. 
Buovjaga, I guess you need to find a cause.

(In reply to Timur from comment #5)
> Buovjaga, I guess you need to find a cause.

No, I don't need to find a cause. I have reproduced it on two completely different systems: a Win 7 laptop and a Win 10 VM.

Still can not confirm.

On Windows 10 Pro 64-bit en-US with nVidia GTX 750ti
Version: 6.0.0.0.alpha0+
Build ID: 28b382b7b0a32417e0aedd4ae415a69e479fe60b
CPU threads: 8; OS: Windows 6.19; UI render: GL; 
TinderBox: Win-x86@39, Branch:master, Time: 2017-07-23_03:20:41
Locale: en-US (en_US); Calc: CL

With single page or multi-page document rendered in Print preview zoom level changes are smoothly applied with <Ctrl>+<mouse wheel scroll>

OpenGL is very smooth, hardware acceleration a bit less, even CPU only rendering functions if a bit choppy.

Still confirmed.

Win 10
Version: 6.0.0.0.alpha0+ (x64)
Build ID: 98782932280d20ece450fa06a90c202fb8e2a26e
CPU threads: 4; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2017-07-26_12:33:46
Locale: fi-FI (fi_FI); Calc: group

(In reply to Buovjaga from comment #8)
> Still confirmed.
> 
> Win 10
> Version: 6.0.0.0.alpha0+ (x64)
> Build ID: 98782932280d20ece450fa06a90c202fb8e2a26e
> CPU threads: 4; OS: Windows 6.19; UI render: default; 
> TinderBox: Win-x86_64@42, Branch:master, Time: 2017-07-26_12:33:46
> Locale: fi-FI (fi_FI); Calc: group

Hardware? Got a different mouse to check...

(In reply to V Stuart Foote from comment #9)
> Hardware? Got a different mouse to check...

Already confirmed with 2 mice, now confirmed with a third. I should try to pinpoint at least the minor point release this appeared in...

I cannot confirm the bug with Win bibisect builds! This is very strange.

It works in 5.4 RC1, so the difference must be in the Tinderbox build configs.

Win 10
Version: 5.4.0.1 (x64)
Build ID: 962a9c4e2f56d1dbdd354b1becda28edd471f4f2
CPU threads: 4; OS: Windows 6.19; UI render: default; 
Locale: fi-FI (fi_FI); Calc: group

Still repro.

Version: 6.0.0.0.alpha1+ (x64)
Build ID: 7e03c4eed72452fdfb87341214a21956c08ba969
CPU threads: 4; OS: Windows 10.0; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2017-10-26_00:58:29
Locale: fi-FI (fi_FI); Calc: group

Not reproduced.


Version: 6.0.1.1 (x64)
Build ID: 60bfb1526849283ce2491346ed2aa51c465abfe6
Locale: ja-JP (ja_JP); 
OS:Winsows7 Home Premium x64
CPU:Intel(R)celeron(R)2.00GHz

(In reply to IWAMOTO from comment #14)
> Not reproduced.
> 
> 
> Version: 6.0.1.1 (x64)
> Build ID: 60bfb1526849283ce2491346ed2aa51c465abfe6
> Locale: ja-JP (ja_JP); 
> OS:Winsows7 Home Premium x64
> CPU:Intel(R)celeron(R)2.00GHz

Note that you have to use a build from Tinderbox 42: https://dev-builds.libreoffice.org/daily/master/Win-x86_64@42/current/

Bah, it was something in my profile - safe mode fixed it.

I just had this issue because I was trying to retest Bug #99928.

(I ONLY zoom using Ctrl+Mouse-Wheel... so when I opened Writer's Print Preview, I naturally did it.)

- - -

CANNOT "mouse-scroll zoom":

Version: 24.2.0.3 (X86_64) / LibreOffice Community
Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1
CPU threads: 8; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

skia.log:

RenderMethod: vulkan
Vendor: 0x10de
Device: 0x2504
API: 1.3.271
Driver: 551.92.0
DeviceType: discrete
DeviceName: NVIDIA GeForce RTX 3060
Denylisted: no

- - -

CAN "mouse-scroll zoom" in Safe Mode:

Version: 24.2.0.3 (X86_64) / LibreOffice Community
Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1
CPU threads: 8; OS: Windows 10.0 Build 22631; UI render: default; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

- - -

Aaaaand Comment #16:

> Bah, it was something in my profile - safe mode fixed it.

Yep, same thing happened to me. Resetting profile completely fixed it.

Hmmm...

I didn't even change much in my LO, since I recently had a completely fresh new hard drive + Windows/LO install. (Maybe 1 week of barely any LO usage, with not many changes in options besides toggling Light/Dark mode.)

Not sure we can call this a WFM, it is *forcing* a profile clear on migration from 7.6 to 24.2

On Win10 system upgraded from 7.6.4.1 to 24.2.0.3, with normal profile migration (i.e. did not clear profile).

Same result, <Ctrl> <mousewheel> scrolling was non-functional.

Attached soffice.bin to WinDbg session with symbols, no First or Second chance issues while attempting to zoom scroll with mousewheel--just no response to the mousewheel. Zoom bar + - buttons unaffected.

Cleared (renamed) old profile from 7.6.4, allowing a new 24.2.0 profile to be built and retest mousewheel zoom for the Print Preview. With new profile, no issue with the zoom in or out.

Attaching to WinDbg and again no First or Second chance events.

Of course once new user profile in place, issue resolved. But if common will cause some grief for folks upgrading.

=-testing-=

Version: 24.2.0.3 (X86_64) / LibreOffice Community
Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

(In reply to V Stuart Foote from comment #18)
> Cleared (renamed) old profile from 7.6.4, allowing a new 24.2.0 profile to
> be built and retest mousewheel zoom for the Print Preview. With new profile,
> no issue with the zoom in or out.

It would be nice to try to nail down which setting(s) cause the problem.

(In reply to Mike Kaganski from comment #19)
> (In reply to V Stuart Foote from comment #18)
> > Cleared (renamed) old profile from 7.6.4, allowing a new 24.2.0 profile to
> > be built and retest mousewheel zoom for the Print Preview. With new profile,
> > no issue with the zoom in or out.
> 
> It would be nice to try to nail down which setting(s) cause the problem.

OK, I restored the 7.6.4 level profile a from saved copy. Discovered that the non-functional <Ctrl>+<Mousewheel> zoom is only affecting the Print preview (.uno:PrintPreview) for Writer. 

And that the Print Preview zoom for Calc is not affected with the old 7.6.4 profile used with 24.2.0 build.   The sd and sm modules don't implement the Print Preview of course.

Manually diffed the two registrysettings.xcu but nothing jumps out related to zoom or print previews (Writer or Calc). Some other config file in the profile?

(In reply to V Stuart Foote from comment #18)
> Not sure we can call this a WFM, it is *forcing* a profile clear on
> migration from 7.6 to 24.2
> 
> On Win10 system upgraded from 7.6.4.1 to 24.2.0.3, with normal profile
> migration (i.e. did not clear profile).

Hmmm... I wonder if I ran across a user with another odd "Print problem" / "corrupt profile-on-upgrade".

- https://www.reddit.com/r/libreoffice/comments/1akxtna/problem_with_print_multiple_pages_in_242/kpg68w9/?context=3

They were perfectly fine on LO 7.6. (And this only started on upgrade to 24.2.)

Theirs involved:

1. File > Print

2. Under "Pages per sheet":

- Pages per Sheet: 2
- Order: Left to right, then down.

- - -

Instead, LO 24.2.0 was displaying as:

  1
  2

instead of

  1 2

- - -

2 things seemed to have worked:

1. A simple Close/Reopen on the dialog made it display "1 2" properly again.
   - 1st open = buggy.
   - 2nd open = fine.

OR

2. Going into Safe Mode.

- - -

I told them to submit an issue to Bugzilla, so hopefully there will be a Bug # soon.

For what it's worth, I could not reproduce on Linux with a new profile created with 7.6.6.3 and reused by 24.2.2.2. I tested the gen and gtk3 VCL plugins.

I could reproduce on Windows 11, replacing a 24.2.1.2 profile with a 7.6.6.3 profile.
But, trying again with a brand new 7.6 profile, I can't reproduce anymore, so couldn't compare two minimal profiles.