Is the feature relevant to the Firefox PDF Viewer?
Yes
Feature description
Summary
The Ctrl+scroll zoom handler in the PDF.js viewer derives its scale delta from the raw wheel event deltaY. On Windows (and likely other platforms), users who configure a high "lines per notch" scroll speed in OS mouse settings produce large deltaY values per wheel tick. This causes the viewer to jump through zoom levels in very large steps (e.g. 100% → 370% per notch), making fine zoom control with the mouse wheel impractical.
There is currently no way for embedders or users to configure the sensitivity of Ctrl+scroll zoom.
Steps to reproduce
On Windows, set mouse scroll speed to a high value (Settings → Bluetooth & devices → Mouse → "lines to scroll" = 10 or higher).
Open any PDF in the PDF.js viewer.
Hold Ctrl and scroll the mouse wheel by one notch.
Observe: zoom jumps by a very large step. Fine control requires multiple slow reverse-scrolls to recover.
Expected behaviour
The zoom step per wheel notch should either be capped to a fixed maximum (e.g. 10–15% per notch), or be configurable via a viewer parameter such as wheelZoomSensitivity (default 1.0, lower = slower zoom).
Notes
This is distinct from issue #14476 (which was a Firefox/Wayland regression causing exponential jumps). That issue is fixed. The present report is about the user-facing configurability of the sensitivity on platforms with high OS-level scroll speed.
A simple clamp in the wheel handler — deltaY = Math.sign(deltaY) * Math.min(Math.abs(deltaY), MAX_DELTA) — would address the most common case without a new API. Alternatively, exposing wheelZoomSensitivity as a PDFViewerApplicationOptions entry would give embedders control.
Platform
OS: Windows 11 Pro (high scroll speed configured)
Viewer context: LaTeX Workshop VS Code extension (PDF.js embedded in a VS Code webview)
Other PDF viewers
No response
Is the feature relevant to the Firefox PDF Viewer?
Yes
Feature description
Summary
The Ctrl+scroll zoom handler in the PDF.js viewer derives its scale delta from the raw wheel event deltaY. On Windows (and likely other platforms), users who configure a high "lines per notch" scroll speed in OS mouse settings produce large deltaY values per wheel tick. This causes the viewer to jump through zoom levels in very large steps (e.g. 100% → 370% per notch), making fine zoom control with the mouse wheel impractical.
There is currently no way for embedders or users to configure the sensitivity of Ctrl+scroll zoom.
Steps to reproduce
On Windows, set mouse scroll speed to a high value (Settings → Bluetooth & devices → Mouse → "lines to scroll" = 10 or higher).
Open any PDF in the PDF.js viewer.
Hold Ctrl and scroll the mouse wheel by one notch.
Observe: zoom jumps by a very large step. Fine control requires multiple slow reverse-scrolls to recover.
Expected behaviour
The zoom step per wheel notch should either be capped to a fixed maximum (e.g. 10–15% per notch), or be configurable via a viewer parameter such as wheelZoomSensitivity (default 1.0, lower = slower zoom).
Notes
This is distinct from issue #14476 (which was a Firefox/Wayland regression causing exponential jumps). That issue is fixed. The present report is about the user-facing configurability of the sensitivity on platforms with high OS-level scroll speed.
A simple clamp in the wheel handler — deltaY = Math.sign(deltaY) * Math.min(Math.abs(deltaY), MAX_DELTA) — would address the most common case without a new API. Alternatively, exposing wheelZoomSensitivity as a PDFViewerApplicationOptions entry would give embedders control.
Platform
OS: Windows 11 Pro (high scroll speed configured)
Viewer context: LaTeX Workshop VS Code extension (PDF.js embedded in a VS Code webview)
Other PDF viewers
No response