Hi, Just to let you know why this is so annoying. On mac you use Command and Tab to switch apps. And if a scrolling is still active while switching the app the zoom level changes.

And this is still happening in the latest version from the Mac AppStore

Confirmed: new

This has been bothering me for years. Thanks for filing this issue.

macOS 13.2.1
Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 5f20f4ff21f597e55d899f5ea4dfe1c1fa5824bc
CPU threads: 8; OS: Mac OS X 13.2.1; UI render: Skia/Raster; VCL: osx
Locale: en-US (en_DE.UTF-8); UI: en-US
Calc: threaded

Created attachment 197347 [details]
zoom settings 1

I've also had this for as long as I've used Libreoffice. I've searched many times how to fix, with most of the responses being that it's not a Libreoffice bug. But it is, because I have this problem with no other app. Specifically I never have zoom happen when scrolling and then pressing command key on macOS.

These apps work perfectly without unintended scrolling:
Pages
Microsoft Excel
Discord
Safari
Firefox
Facebook Messenger
Preview
Alacrity
Apple Messages
Mailmate

I've included my settings above as attachment 197347 [details] and I'll update with two more images. Note in here I have nearly every accessibility setting off related to things like this.

Why do people say it is an OS setting? Because there is an OS setting for this "feature" called:
Use scroll gesture with modifier key to zoom

Note I have that disabled in my settings.

The core issue (it seems to me) is Libreoffice decides to ignore Accessibility settings and implement the setting whether or not it is enabled in the system settings.

Forgot to note, I'm on Libreoffice 24.8.0.3 and macOS 15.1 (24B83).

But I've had this fore years, maybe even back to Libreoffice 6.x.

Created attachment 197348 [details]
zoom settings 2

Created attachment 197349 [details]
zoom settings 3

(In reply to JR from comment #4)
> Use scroll gesture with modifier key to zoom
> 
> Note I have that disabled in my settings.
> 
> The core issue (it seems to me) is Libreoffice decides to ignore
> Accessibility settings and implement the setting whether or not it is
> enabled in the system settings.

I think that might be a solution I would be able to implement. Any idea what that system setting's underlying ID string is?

I ran the following in Terminal and nothing seems to change when I toggle that system setting:

defaults -g read | grep -i zoom
defaults read com.apple.universalaccess | grep -i zoom

(In reply to Patrick (volunteer) from comment #8)
> I think that might be a solution I would be able to implement. Any idea what
> that system setting's underlying ID string is?

Found the ID string:

defaults read com.apple.AppleMultitouchTrackpad HIDScrollZoomModifierMask

(In reply to Patrick (volunteer) from comment #9)
> Found the ID string:
> 
> defaults read com.apple.AppleMultitouchTrackpad HIDScrollZoomModifierMask

After some online reading, it seems this other default is a better one to use:

defaults read com.apple.universalaccess closeViewScrollWheelToggle

I have submitted the following patch:

https://gerrit.libreoffice.org/c/core/+/175946

It's a hacky fix but what the patch does is stop LibreOffice from converting vertical scrollwheel events to horizontal scrollwheel events when the Command key is pressed if the "Use scroll gesture with modifier keys to zoom" accessibility setting is disabled in the System Preferences application.

I found that the "Use scroll gesture with modifier keys to zoom" accessibility setting controls zooming of the entire desktop, not within an application so I abandoned the patch in comment #11.

I have submitted a new patch that takes a different approach: limit the special behavior when pressing the Command or Shift keys to only scrollwheel events generated by a mouse. With this new patch, hopefully pressing the Command or Shift keys will no longer have any effect when scrolling with a trackpad:

https://gerrit.libreoffice.org/c/core/+/176410

Patrick Luby committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f5ef5eafdf70a36edd5129147502a9c74df89456

tdf#151423 Only allow modifiers for mouse scrollwheel events

It will be available in 25.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

I have committed a fix for this bug. The fix will be in tomorrow's (15 November 2024) nightly master builds:

https://dev-builds.libreoffice.org/daily/master/current.html

Note for macOS testers: the nightly master build installer does not overwrite any LibreOffice official versions. Instead, it will be installed as a separate application called "LibreOfficeDev" in the /Applications folder.

Because this is a "test" build, you will need to do the following steps before you launch the LibreOfficeDev application:

1. Go to the Finder and navigate to the /Applications/Utilities folder
2. Launch the "Terminal" application
3. Paste the following command in the Terminal application window and press the Return key to execute the command:

   xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app

Verified in Version: 25.2.0.0.alpha0+ (AARCH64) / LibreOffice Community
Build ID: f5ef5eafdf70a36edd5129147502a9c74df89456
CPU threads: 12; OS: macOS 15.1; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

This was a major nuisance to macOS users for many years. Glad it is a thing of the past.

Patrick Luby committed a patch related to this issue.
It has been pushed to "libreoffice-24-8":

https://git.libreoffice.org/core/commit/36cb8c808527d80d947a005b934de585a55b12b6

tdf#151423 Only allow modifiers for mouse scrollwheel events

It will be available in 24.8.4.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

This fix works with Apple's trackpad (pinch to zoom). But with an external mouse zoom via cmd + mouse wheel is no more possible. Or am I missing an hidden option somewhere?

(In reply to siggibugzilla from comment #17)
> This fix works with Apple's trackpad (pinch to zoom). But with an external
> mouse zoom via cmd + mouse wheel is no more possible. Or am I missing an
> hidden option somewhere?

No, there is no hidden option.

I cannot reproduce what you describe with my USB Logitech mouse. What brand/model of mouse do you have?

Currently, to determine if scrolling events come from mouse, we look to see if the scrolling events have both of their "phase" and "momentum phase" attributes set to "none". This is how the following Apple documentation says indicate that the a scrolling event is from a mouse scrollwheel:

https://developer.apple.com/documentation/appkit/nsevent/phase-swift.property?language=objc

So, I suspect that your mouse has some subset of trackpad features that are causing either or both of the "phase" and "momentum phase" attributes to be set to something other than "none".

Not sure how to debug without having the same mouse as you.

(In reply to Patrick (volunteer) from comment #18)
> Not sure how to debug without having the same mouse as you.

If anyone with a local LibreOffice build can reproduce this problem with their mouse, I can post a debug patch that will printf() the values of the "phase" and "momemtum phase" attributes to see if there is some common pattern.

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

(In reply to Patrick (volunteer) from comment #19)
> If anyone with a local LibreOffice build can reproduce this problem with
> their mouse, I can post a debug patch that will printf() the values of the
> "phase" and "momemtum phase" attributes to see if there is some common
> pattern.

Can't reproduce in a local development build on macOS either; zooming using Command+scroll using my Logitech mouse works as expected.

(In reply to Michael Weghorn from comment #21)
> Can't reproduce in a local development build on macOS either; zooming using
> Command+scroll using my Logitech mouse works as expected.

I found the following Apple support page that lists the various trackpad and mouse gestures available. The "Mouse gestures" section about half way down that page shows that, at least on a Magic Mouse, vertical and horizontal scrolling is down using a single finger gesture:

https://support.apple.com/en-ca/102482

Here is my current theory: the Magic Mouse or similar mice are sending gestures so the scroll events have either the "phase" or "momentum phase" set to something. In contrast, USB mice always set both to "none".

So I think I can add code to monitor the "touch" events and then I can limit my original fix for this bug to only ignore the Command and other keys if there are two fingers touching. Fortunately, someone has posted a blog and how to track the number of fingers are touching:

https://blog.rectorsquid.com/detecting-trackpad-scroll-vs-magic-mouse-scroll/

There is also one other problem that I see: after you remove all fingers from the trackpad, a bunch of momentum phase events are sent so I will also need to ignore the momentum phase events if the Command and other keys are pressed. Maybe the Magic Mouse is sending momentum events but the zooming effect is already pretty sensitive so I am hoping that excluding momentum events won't be noticed.

I'll post again when I have some more news.

Reopening since it appears that the original bug fix doesn't properly handle some known Magic Mouse gestures.

My original reports was for a track pad on a MacBook.
The problem remains to this day.

My original report was for writer not calc but the problem still exists for it.

(In reply to Pauli from comment #24)
> My original reports was for a track pad on a MacBook.
> The problem remains to this day.

Well it is confirmed as fixed by several users including me starting in LibreOffice 24.8.4. Can you open the LibreOffice > About dialog. Click on the button in the middle of the dialog to copy the version information, and then paste the info in this bug?

(In reply to Patrick (volunteer) from comment #26)
> Well it is confirmed as fixed by several users including me starting in
> LibreOffice 24.8.4. Can you open the LibreOffice > About dialog. Click on
> the button in the middle of the dialog to copy the version information, and
> then paste the info in this bug?

I forgot to post the version information for my LibreOffice installation:

Version: 24.8.4.2 (AARCH64) / LibreOffice Community
Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002
CPU threads: 8; OS: macOS 15.2; UI render: Skia/Metal; VCL: osx
Locale: en-CA (en_CA.UTF-8); UI: en-US
Calc: threaded

(In reply to Patrick (volunteer) from comment #22)
> So I think I can add code to monitor the "touch" events and then I can limit
> my original fix for this bug to only ignore the Command and other keys if
> there are two fingers touching. Fortunately, someone has posted a blog and
> how to track the number of fingers are touching:
> 
> https://blog.rectorsquid.com/detecting-trackpad-scroll-vs-magic-mouse-scroll/
> 
> There is also one other problem that I see: after you remove all fingers
> from the trackpad, a bunch of momentum phase events are sent so I will also
> need to ignore the momentum phase events if the Command and other keys are
> pressed. Maybe the Magic Mouse is sending momentum events but the zooming
> effect is already pretty sensitive so I am hoping that excluding momentum
> events won't be noticed.

Replying here as requested in https://bugs.documentfoundation.org/show_bug.cgi?id=46429#c40

Personally I very much appreciate this fix avoiding random zooming when scrolling using the Apple Magic Mouse, and am quite happy to live with it completely disabling zooming via  Magic Mouse gestures (on the infrequent occassions I need to zoom, I use the "100%" drop down at the bottom of the page, or keyboard commands).

I would be very disappointed if the Magic Mouse scrolling was changed to reintroduce the problem with zooming randomly starting when pressing keys "too soon" *after* scrolling (the original problem, open 13 years).

I don't think there's any logical reason to restrict this fix to just "two fingers on track pad built into a laptop" as seems to be suggested.

For what it's worth, there's an extremely obvious algorithm for detecting whether zooming should be applied to the scroll event:

1.  Were the cmd/option/etc modifier keys pressed *before the scrolling events started*?

The entire source of this bug was LibreOffice inexplicably treated modifier keys *changing in the middle of a scroll event sequence* as a reason to change what the scrolling event meant (which particularly impacts inertial scroll, as it's not obvious to the user how long they have to wait between stopping the scrolling inger motion and doing something else).

If you want to change the fix to restore the ability to zoom via mouse / trackpad gestures, I'd suggest checking for modifier keys pressed *at the start of the first scroll event*.

If any modifier keys are pressed *at the start*, allow monitoring the modifier keys (including, I guess, into intertial scrolling).

If *no modifier keys* are pressed at the start of scrolling, ignore all modifier key changes until scrolling stops (including intertial scrolling stops), ie the current fix.

Then the UX is:

- press modifier keys, and *then* scroll: page contents zooms

- *do not press modifier keys*, and scroll: page contents scrolls (even if you later press modifier keys soon after finishing the finger scroll movement)

To me that seems a UX that doesn't violate the Principle of Least Surprise.  The previous behaviour (changing what scrolling meant, in interial scrolling, because someone pressed a key after scrolling) definitely violated the Princple of Least Surprise :-/

Ewen

(In reply to Ewen McNeill from comment #28)
> If *no modifier keys* are pressed at the start of scrolling, ignore all
> modifier key changes until scrolling stops (including intertial scrolling
> stops), ie the current fix.
> 
> Then the UX is:
> 
> - press modifier keys, and *then* scroll: page contents zooms
> 
> - *do not press modifier keys*, and scroll: page contents scrolls (even if
> you later press modifier keys soon after finishing the finger scroll
> movement)
> 
> To me that seems a UX that doesn't violate the Principle of Least Surprise. 
> The previous behaviour (changing what scrolling meant, in interial
> scrolling, because someone pressed a key after scrolling) definitely
> violated the Princple of Least Surprise :-/

I like this proposal. To me, it seems a lot less hacky than both my original fix  and my proposal in comment #22.

Unless anyone sees a problem with @Ewen's proposal, I will try to implement.

Patrick Luby committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/b197379e867087413be86bd1a32030b912ecaa8a

tdf#151423 use the same modifier keys during a scrolling session

It will be available in 25.8.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

I have committed a change hopefully implements the behavior described in comment #28. In my latest commit, LibreOffice should only recognize modifier keys that were pressed when a "scrolling session" started.

The change should be in tomorrow's (20 January 2025) nightly master builds.
I am interested to hear how this change works on a Magic Mouse as I have only tested with a trackpad and a simple USB mouse: 

https://dev-builds.libreoffice.org/daily/master/current.html

Note for macOS testers: the nightly master build installer does not overwrite any LibreOffice official versions. Instead, it will be installed as a separate application called "LibreOfficeDev" in the /Applications folder.

Because this is a "test" build, you will need to do the following steps before you launch the LibreOfficeDev application:

1. Go to the Finder and navigate to the /Applications/Utilities folder
2. Launch the "Terminal" application
3. Paste the following command in the Terminal application window and press the Return key to execute the command:

   xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app

Just got the latest update via the AppStore. 

Version: 24.8.4.2 (AARCH64) / LibreOffice Community
Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002
CPU threads: 10; OS: macOS 15.2; UI render: Skia/Metal; VCL: osx
Locale: de-DE (en_DE.UTF-8); UI: de-DE
Calc: threaded

And I'm happy to report that this bug is fixed.

Thanks

Verified, based on comment 32.

(In reply to BogdanB from comment #33)
> Verified, based on comment 32.

Comment #32 only verified the first fix. But that fix made it impossible to zoom with mice that have limited gestures such as the Magic Mouse.

So, I wrote a second fix (see comment #31) that I am still waiting for people to test on the following 3 devices:

- Trackpad
- Magic mouse
- Regular mouse

(In reply to Patrick (volunteer) from comment #34)
> So, I wrote a second fix (see comment #31) that I am still waiting for
> people to test on the following 3 devices:
> 
> - Trackpad
> - Magic mouse
> - Regular mouse

Has anyone had a chance to download a nightly build and test my second fix? Or is my original fix "good enough" even though it disables zooming with a Magic Mouse?

Hi and thanks for your patch. I only have a Trackpad and that works as expected.
I can't test for Magic mouse or Regular mouse.

(In reply to Thomas Lüder from comment #36)
> Hi and thanks for your patch. I only have a Trackpad and that works as
> expected.
> I can't test for Magic mouse or Regular mouse.

Thank you for testing! Good to know that it works on a trackpad as I am trying to reenable the Command key zooming for Magic Mouse users without causing the bug to reoccur to trackpad users. Trying to find the right balance.

Thanks Patrick for working on implementing a more flexible fix to the unintended zoom in/out.   Apologies for taking so long to get around to testing it: I initially thought "I'll wait a couple of days until it's definitely in the daily builds"... and then I got busy, and a month went by.

Today, after confirming it didn't make the 25.2 release (too late), I've tested with the 25.8.0.0.alpha0+ (2025-03-06) daily build, downloaded from:

https://dev-builds.libreoffice.org/daily/master/MacOSX-x86_64@tb92-TDF/2025-03-06_03.08.30/LibreOfficeDev_25.8.0.0.alpha0_MacOS_x86-64.dmg

using an Apple Magic Mouse, on macOS 13.7.4, on an 2020-era Mac Mini (so x86_64).

My impression is that this is *close* to the desired solution, but the timer being used to detect "end of one scroll event" / "start of new scroll event" feels like it needs more tuning (too long).

Successful:

- scrolling with mouse, *then* press command key, continues scrolling

- (after a suitably long gap), *first* press command key, then scroll and it zooms in/out

Unsuccessful:

- after getting into "zooming mode" intentionally, then stopping scrolling for (what felt like) a second (movement stopped), then I expected starting scrolling again without pressing the command key again to scroll up/down -- instead it stayed stuck in "zoom" mode

- after scrolling up/down without pressing the command key, stopping for (what felt like) a  second (movement stopped), then pressing the command key and scrolling I expected zooming to happen -- instead it stayed stuck in "scrolling up/down" mode

I *was* able, with patience, to get it to switch back and forth between modes repeatedly, but it felt like an unrealistically long "don't touch the mouse" gap was needed, to get it to switch modes, with no indication (other than "I've seen the source code") for why it was misbehaving.

I can see from the code that the timeout is supposed to be exactly 1 second:

const static NSTimeInterval fScrollEventTimeoutTime = 1.0f;

but the perceptual delay from "I stopped doing anything on the mouse, my hand hasn't even been near it" to "it's willing to switch modes" is noticably longer than that (feels like maybe 2-5 seconds).

I guess the interial scroll events are continuing for a while longer after removing my hand from the magic mouse, even though the text is no longer "noticably moving", and that's pushing out the timer expiry.

My hunch is to set that timer (which seems to be reset by each scroll event) to about 1/3rd to 1/4th of the current value, so 0.33f or 0.25f.  With the hope that the perceptual delay becomes more like "lift hand, wait a second, can do different action".

But either way, the original use case remains fixed (ie, start scrolling first, then press command as part of something else doesn't trigger zooming) *and* it's possible trigger zooming with the Magic Mouse intentionally (press command first, then scroll).  So I'd call this better than the currently release version, without modification.  And if we can get the timeout right hopefully it's the ideal fix.

Ewen

(In reply to Ewen McNeill from comment #38)
> My hunch is to set that timer (which seems to be reset by each scroll event)
> to about 1/3rd to 1/4th of the current value, so 0.33f or 0.25f.  With the
> hope that the perceptual delay becomes more like "lift hand, wait a second,
> can do different action".

Thank you for testing. This patch is only in master right now because I think it is highly experimental. Right now, trackpad and regular mouse users are happy. It is Magic Mouse users that lost something so I am trying to see if we can restore zooming for Magic Mouse users without causing the old bug to reappear for everybody else.

I know that trackpads and likely the Magic Mouse send "momentum events" after you do a scroll and release the mouse. One problem I can see is that these momentum events seem to keep coming in for a second or more after a big scroll and release on my trackpad.

That is usually where this bug would occur on trackpads: the user would press the Command key while momentum events are still coming in even though they have stopped scrolling. IIRC, setting the time interval below 1 seconds caused the original bug to reoccur on my trackpad.

Reopening thsi bug as I have a feeling that I will need to rethink this. Not sure what to do yet, but it seems that everything revolves around those momentum events.

Patrick Luby committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/3b96af6479ddbbf27834ed93ed9543b91451befb

tdf#151423 revert commit b197379e867087413be86bd1a32030b912ecaa8a

It will be available in 25.8.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

(In reply to Patrick (volunteer) from comment #39)
> Reopening thsi bug as I have a feeling that I will need to rethink this. Not
> sure what to do yet, but it seems that everything revolves around those
> momentum events.

My commit in comment $40 reverts my last attempt to reenable zooming with the Command key on a Magic Mouse. I could not get my last attempt to work reliably even on a trackpad. So now master is back to the same behavior as the recent LibreOffice 25.2.1 release.

After trying various approaches, I really can't find any reliable way to distinguish between a trackpad and a Magic Mouse from within the LibreOffice code.

So, maybe we just need a simpler approach: add a LibreOffice "expert" preference (let's call it "EnableModifiersWhenTrackpadScrolling" for discussion). It would be set to "false" by default which gives us the current bahavior: keys pressed during a scroll are ignored on a trackpad and Magic Mouse.

Changing that to "true" would change that so that keys pressed are handled on a trackpad and a Magic Mouse. It's not a pretty solution, but it would give Magic Mouse users a way to opt out of the new trackpad behavior.

Thanks for continuing to work on this issue.  Sorry to hear you couldn't find a suitable "modifier lock-in/lock-out" timeout :-(

I feel like the "detect start/end of scrolling, lock out modifier changes *during* scrolling sesion" approach is still valid *if* we can figure out a reliable way to detect the user-perceptable "same scrolling finger movement (or interial scroll after effects)".  But it sounds like this is non-trivial as it seems the various commonly used input devices (touchpad, Magic Mouse, regular scroll wheel mouse, etc) send different combinations of events, at different intervals.

FTR, I'd be fine with a "EnableModifiersWhenTrackpadScrolling" setting "for advance users" as an interim work around.

It could even default to enabled (true; ie reproducing the behaviour of the last 10 years), and just have the *option* of being set to false by the user who doesn't use scroll-to-zoom (eg, me), to avoid the misbehaviour.  FWIW, I'm also fine with the current production shipped behaviour (which breaks "zoom to scroll" entirely, to avoid it being accidentally invoked).

Ewen

Based on searching for detecting scrolling events on macOS, I found:

https://blog.rectorsquid.com/detecting-trackpad-scroll-vs-magic-mouse-scroll/

Skim reading it, it sounds like the Magic Mouse is sending Scroll Wheel events (makes sense, given what it is emulating).  (Their use case was to have scroll-on-touchpad and scroll-on-magic-mouse, presumably one under each hand, do different things in their program.)

They also make the interesting observation about the transition into momentum scroll events:

"But then it turns out that there is a call or two to the event handler with no momentum and while no fingers are down just before the momentum-related events show up."

ie, it sounds like there's finger-driven scroll events, some zero-movement scroll events (user lifted finger) and then some momentum emulation synthesised scroll events.

It also seems there's a flag on the momentum events:

"discovered that I can check the momentumPhase value for non-zero to detect momentum"

which might be a useful distinguisher of "user generated" or "driver synthesised".

In particular I'm thinking if the 1 second timer were to only be reset by *non* momentum scroll events (ie, user-finger-generated events), then the user perception would be "lift finger, wait 1 second, then it is willing to switch between up/down and zoom modes".  And that might make for the previous patch having a "basically invisible" transition between modes.

FTR, documentation of the momentumPhase field of NSScrollWheel events:

https://developer.apple.com/documentation/appkit/nsevent/momentumphase
https://developer.apple.com/documentation/appkit/nsevent/phase-swift.struct

Of note, NSEvent.Phase seems to have "began", "ended", and "cancelled" fields (among others).  And seems to be present since macOS 10.7 (which is a bunch of years old).

So my thought is:

- detect start of event stream, as per previous patch
- only events which are *not* momentum scroll reset the timer back to 1 second
- if we get NSEvent.Phase ended / cancelled, also cancel timer and go back to "not in scroll event stream"

and hopefully that'd give us "end of scroll stream is 1 second after last non-momentum event, or when we get event telling us momentum ended".

Ewen

(In reply to Ewen McNeill from comment #42)
> FTR, I'd be fine with a "EnableModifiersWhenTrackpadScrolling" setting "for
> advance users" as an interim work around.

Just to set expectations. This interim solution will likely become the permanent solution.

I am a volunteer with very limited spare time and adding an export preference is the simplest way to restore the old Magic Mouse behavior without forcing LibreOffice's legacy "scroll to zoom" behavior.

I've already spent numerous days of my own personal time to try various approaches. My last attempt was to look for the MayBegin phase as the docs say that that phase only occurs on trackpads. Problem is that macOS only sends the MayBegin phase when we touch the trackpad and not move it for a moment. So that's not reliable. Clearly Apple does not want developers to know what type of scrolling device you are using.

> It could even default to enabled (true; ie reproducing the behaviour of the
> last 10 years), and just have the *option* of being set to false by the user
> who doesn't use scroll-to-zoom (eg, me), to avoid the misbehaviour.  FWIW,
> I'm also fine with the current production shipped behaviour (which breaks
> "zoom to scroll" entirely, to avoid it being accidentally invoked).

Sorry, but I will set this to default to false. Let's be realistic here. Every Mac laptop sold in that last 10+ years has a trackpad so I think it is safe to assume that Magic Mouse users are outnumbered by a significantly larger group of trackpad users.

Many of us trackpad users (me included) hate the old behavior. Setting the default to true would bring back the really annoying trackpad behavior and I am not willing face the ire of a horde of trackpad users for a much tinier group of Magic Mouse users.

Fair :-)

I appreciate you've taken the time to find a solution to the problem that's bugged so many of us for so long.

And your "have an option to re-enable the old (bad) behaviour for those that want scroll-to-zoom" was my original suggestion when I first encountered this bug (a bunch of years ago).  So I'm fine with that being the solution.

I'm also fine with the default being "preserve the new LibreOffice 25.2 behaviour, unless the user chooses otherwise".  As the new behaviour (cannot scroll-to-zoom) is exactly what I'd pick anyway.

Thanks again for spending the time to understand and find a workable solution to a problem that the rest of us have just grumbled about for a decade ;-)

Ewen

Created attachment 199721 [details]
Snapshot of the new IgnoreKeysWhenScrollingWithTrackpadOrMagicMouse expert preference

I have implemented the new expert preference in the following patch:\


The preference name is ugly, but it has most of the common search terms that I could think of so you can find it easily.

This patch still needs review as I am not sure if I have put the expert preference in the right place. In particular, I created a new "macOS" subgroup with the idea that other platforms may add their own preferences as well.

Once this is committed, I can add a wiki page with this snapshot that we can point users to.

(In reply to Patrick (volunteer) from comment #46)
> I have implemented the new expert preference in the following patch:\

Oops. I forgot to include the patch link:

https://gerrit.libreoffice.org/c/core/+/182740

Patrick Luby committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1c4c24042cbe0ede59513d30a676442f7f238b62

tdf#151423 allow trackpad or Magic Mouse to behave like a regular mouse

It will be available in 25.8.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

I have committed my latest change that adds a new LibreOffice "expert" preferences that can reenable the old Command+scroll behavior. The new expert preference is in the Advanced panel of the Options dialog as shown in attachment  #199721 [details].

The change should be in tomorrow's (19 March 2025) nightly master builds: 

https://dev-builds.libreoffice.org/daily/master/current.html

Note for macOS testers: the nightly master build installer does not overwrite any LibreOffice official versions. Instead, it will be installed as a separate application called "LibreOfficeDev" in the /Applications folder.

Because this is a "test" build, you will need to do the following steps before you launch the LibreOfficeDev application:

1. Go to the Finder and navigate to the /Applications/Utilities folder
2. Launch the "Terminal" application
3. Paste the following command in the Terminal application window and press the Return key to execute the command:

   xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app

Patrick Luby committed a patch related to this issue.
It has been pushed to "libreoffice-25-2":

https://git.libreoffice.org/core/commit/38f050a2640b1ecfb05b9d564b86b8b9adfa7dcf

tdf#151423 allow trackpad or Magic Mouse to behave like a regular mouse

It will be available in 25.2.3.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Patrick Luby committed a patch related to this issue.
It has been pushed to "libreoffice-25-2-2":

https://git.libreoffice.org/core/commit/9d6dd24c024de3c22a4f65ac29c2f90bbdf0f694

tdf#151423 allow trackpad or Magic Mouse to behave like a regular mouse

It will be available in 25.2.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Testing with 25.8.0.0.alpha0+ (build ID d9eac4f95649f04e1ddbe5026d8bb323c1fc58d8, built 2025-03-23) on macOS 13.7.4 (x86_64), it seems to me that the "expert option" works as intended with a Magic Mouse:

* in the default state ("IgnoreKeysWhenScrollingWithTrackpadOrMagicMouse" = true), the magic mouse scroll action only causes scroll up/down, whether or not the Command key is pressed in the interial scroll period (original bug) or even at the start (consistent with the shipped work around).

* in the non-default state ("IgnoreKeysWhenScrollingWithTrackpadOrMagicMouse" = false), the historical behaviour of the Magic Mouse scroll is restored -- ie, if the command key is pressed before starting scrolling, it zooms, if not it scrolls up/down -- and if the command key is pressed during interial scrolling it suddenly changes to "surprise zoom" (the original bug).

So this appears to successfully give users an option to choose "original, buggy, behaviour but can scroll-to-zoom when desired too" or "25.2 shipped behaviour, no surprise zooom but also no scroll-to-zoom at all" as they wish.  (I'm going to leave it in the default "25.2 shipped behaviour, no surprise zoom" myself; even when done deliberately the scroll-to-zoom is too twitchy to be useful, so I always use the dialog box to change.)

Thanks for getting this change in Patrick.  Hopefully this makes everyone happy :-)  And it's encouraging that it sounds like it's going to get backported to the 25.2.x branch -- in 25.2.2.

FTR to change the setting you want:  LibreOffice -> Preferences -> LibreOffice -> Advanced -> Expert Configuration (bottom right) -> search for "magicmouse", and then eg, double click on the true/false will toggle the setting, which can can save as usual with "OK".

Ewen