Bug 106661 - CTRL + mouse/scrollwheel zoom does not work in print preview, on upgrade now forcing user profile reset
Summary: CTRL + mouse/scrollwheel zoom does not work in print preview, on upgrade now ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.4.0.0.alpha0+
Hardware: All Windows (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, regression
Depends on:
Blocks: Scrolling-PageUpDown Print-Preview User-Profile-Upgrade
  Show dependency treegraph
 
Reported: 2017-03-20 11:46 UTC by Buovjaga
Modified: 2024-04-16 05:31 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Buovjaga 2017-03-20 11:46:44 UTC
1. Open attachment 131823 [details] or another Writer document with several pages.
2. Go to Page Preview.
3. Zoom in with CTRL + mouse wheel.

It works in Calc. It works in 5.2.

Win 7 Pro 64-bit, Version: 5.2.5.1 (x64)
Build ID: 0312e1a284a7d50ca85a365c316c7abbf20a4d22
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
Locale: fi-FI (fi_FI); Calc: CL

Version: 5.4.0.0.alpha0+
Build ID: 2356bfdb1b99a93fcb35fefc0f587158e7d160c2
CPU threads: 4; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-03-20_00:30:32
Locale: fi-FI (fi_FI); Calc: CL
Comment 1 Xisco Faulí 2017-03-20 11:48:23 UTC
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
Comment 2 V Stuart Foote 2017-03-20 12:13:08 UTC
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.
Comment 3 Xisco Faulí 2017-06-19 18:49:52 UTC
hi buovjaga,
Still reproducible on master?
Comment 4 Buovjaga 2017-06-19 18:58:36 UTC
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
Comment 5 Timur 2017-07-26 13:52:02 UTC
Also no repro on Windows 7 and Windows 10 with LO 6.0+. 
Buovjaga, I guess you need to find a cause.
Comment 6 Buovjaga 2017-07-26 14:11:52 UTC
(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.
Comment 7 V Stuart Foote 2017-07-26 14:59:56 UTC
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.
Comment 8 Buovjaga 2017-07-26 15:17:25 UTC
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
Comment 9 V Stuart Foote 2017-07-26 15:19:35 UTC
(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...
Comment 10 Buovjaga 2017-07-26 16:42:02 UTC
(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...
Comment 11 Buovjaga 2017-07-27 13:13:44 UTC
I cannot confirm the bug with Win bibisect builds! This is very strange.
Comment 12 Buovjaga 2017-07-27 14:26:42 UTC
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
Comment 13 Buovjaga 2017-11-03 17:22:58 UTC
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
Comment 14 IWAMOTO 2018-02-20 08:51:01 UTC
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
Comment 15 Buovjaga 2018-02-20 09:06:28 UTC
(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/
Comment 16 Buovjaga 2018-02-20 09:25:27 UTC
Bah, it was something in my profile - safe mode fixed it.
Comment 17 Tex2002ans 2024-02-06 11:10:59 UTC
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.)
Comment 18 V Stuart Foote 2024-02-06 15:03:21 UTC
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
Comment 19 Mike Kaganski 2024-02-07 03:55:46 UTC
(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.
Comment 20 V Stuart Foote 2024-02-07 14:53:30 UTC
(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?
Comment 21 Tex2002ans 2024-02-08 09:13:01 UTC
(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.
Comment 22 Stéphane Guillou (stragu) 2024-04-16 05:31:22 UTC
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.