Description: Despite the system-level accessibility prefs, under certain circumstances, LibreOffice will fire flashing "marching ants" animation, making it painful to look at that part of the screen, making it impossible to see what cells you just selected, and causing migraines. Steps to Reproduce: 1. set system-level accessibility prefs to reduce flashing and other animation. 2. open a LibreOffice spreadsheet. 3. select a group a cells and select "Copy." Actual Results: There are painful flashes on the screen. Expected Results: No "migraine ants!" Reproducible: Always User Profile Reset: No Additional Info: I could have sworn an earlier version had fixed this-- I'd selected LibreOffice for spreadsheets because of that! I've had bad results, and migraines, in 7.5.0.3, and 7.0.0.3.
Thanks for the report, MarjaE! Confirmed with Ventura 13.2.1 and: Version: 7.5.4.2 (X86_64) / LibreOffice Community Build ID: 36ccfdc35048b057fd9854c757a8b67ec53977b6 CPU threads: 2; OS: Mac OS X 13.2.1; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Michael, thoughts? Do we even have an expert configuration for turning that off?
(In reply to Stéphane Guillou (stragu) from comment #1) > Michael, thoughts? > Do we even have an expert configuration for turning that off? I didn't see any option for this while analyzing this. In the options, there are 2 settings related to animation in the Accessibility section, but they are unrelated to this: "Allow animated images", "Allow animated text" One idea might be to add another option there to reduce motion/animations and give it three possible values (similar to the Light/Dark theme setting in the "View" section: enable/disable/automatic, where "automatic" (the default?) would use the value from the OS/desktop environment. And if that setting is enabled, avoid animations like the one mentioned here. At a quick glance, "gtk-enable-animations" seems to be a similar setting for GNOME/Gtk: https://docs.gtk.org/gtk4/property.Settings.gtk-enable-animations.html Any thoughts on that? Relevant place in code: The animations stops with this test change in place: diff --git a/sc/source/ui/view/overlayobject.cxx b/sc/source/ui/view/overlayobject.cxx index 2be20070e4a0..4cd337bed916 100644 --- a/sc/source/ui/view/overlayobject.cxx +++ b/sc/source/ui/view/overlayobject.cxx @@ -49,7 +49,8 @@ void ScOverlayDashedBorder::Trigger(sal_uInt32 nTime) { SetTime(nTime + DASH_UPDATE_INTERVAL); mbToggle = !mbToggle; - pMgr->InsertEvent(*this); + // DEMO: disable animation of the dashed border + //pMgr->InsertEvent(*this); objectChange(); } }
(In reply to Michael Weghorn from comment #2) > One idea might be to add another option there to reduce motion/animations > and give it three possible values (similar to the Light/Dark theme setting > in the "View" section: enable/disable/automatic, where "automatic" (the > default?) would use the value from the OS/desktop environment. And if that > setting is enabled, avoid animations like the one mentioned here. I like that idea. Do you envision this exposed in Tools > Option > LibreOffice > View, or hidden away in expert configuration (with the sensible default of "automatic")? Copying Design/UX team in for input.
(In reply to Stéphane Guillou (stragu) from comment #3) > I like that idea. Do you envision this exposed in Tools > Option > > LibreOffice > View, or hidden away in expert configuration (with the > sensible default of "automatic")? I was initially thinking about Tools > Options > LibreOffice > Accessibility, where the other 2 options I mentioned are also located. This would allow changing this easily even if the platform/OS doesn't provide any way. Thinking about it again: This page suggests that there's a similar setting for Windows and KDE Plasma as well: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion If that's actually the case, then I tend to think that having just an expert option might be enough, since user-configured platform value should usually be fine.
Solved with bug 35077, and AnimationsEnabled does stop the ants from marching. Follow-up ticket is bug 115688 to have this in the UI. My take: no UI option but some expert setting to override the system default. Going to make this a duplicate. *** This bug has been marked as a duplicate of bug 115688 ***
(In reply to Heiko Tietze from comment #5) > Solved with bug 35077, and AnimationsEnabled does stop the ants from > marching. Follow-up ticket is bug 115688 to have this in the UI. My take: no > UI option but some expert setting to override the system default. > > Going to make this a duplicate. > > *** This bug has been marked as a duplicate of bug 115688 *** Great to know there's already an option that I just didn't see. Let's continue discussion in bug 115688 then.
Is this really a duplicate? IMHO, I think sc/source/ui/view/overlayobject.cxx:37 should be changed from: mbAllowsAnimation = officecfg::Office::Common::VCL::AnimationsEnabled::get(); to: mbAllowsAnimation = (officecfg::Office::Common::VCL::AnimationsEnabled::get() && !Application::UseReducedAnimation()); Application::UseReducedAnimation() would return false in SalInstance::useReducedAnimation(). Then, each platform subclass of SalInstance (e.g. AquaSalInstance) would have the option to implement a native implementation. For SalInstance::useReducedAnimation(), I was thinking of returning the following: [[NSWorkspace sharedWorkspace] accessibilityDisplayShouldReduceMotion] I'll write a Gerrit change, but not commit it, this weekend that all of you can look at it.
(In reply to Patrick Luby from comment #7) > Is this really a duplicate? IMHO, I think > sc/source/ui/view/overlayobject.cxx:37 should be changed from: > > mbAllowsAnimation = officecfg::Office::Common::VCL::AnimationsEnabled::get(); > > to: > > mbAllowsAnimation = (officecfg::Office::Common::VCL::AnimationsEnabled::get() > && !Application::UseReducedAnimation()); That fits with the suggestion in bug 115688 comment 15 and sounds reasonable to me. > Application::UseReducedAnimation() would return false in > SalInstance::useReducedAnimation(). Then, each platform subclass of > SalInstance (e.g. AquaSalInstance) would have the option to implement a > native implementation. > > For SalInstance::useReducedAnimation(), I was thinking of returning the > following: > > [[NSWorkspace sharedWorkspace] accessibilityDisplayShouldReduceMotion] > > I'll write a Gerrit change, but not commit it, this weekend that all of you > can look at it. Great, thanks! I could take a look at doing the Windows and Linux implementations if there's a consensus that this is the way to move forward. Let's reopen this bug for now.
I have uploaded the following patch that implements my proposed change: https://gerrit.libreoffice.org/c/core/+/154752 Checking the native macOS "reduce motion" preference is in the new AquaSalInstance::UseReducedAnimation() method in vcl/osx/salinst.cxx. All other platforms return false. Not sure if the following helps, but below are the SalInstance subclasses that have their own AddToRecentDocumentList() method that aren't empty and have implemented native code. Not sure if it is a useful list or not, but my guess is that the platforms that implement some native code in AddToRecentDocumentList() are the superset of platforms where it might be possible to implement of UseReducedAnimation(): vcl/inc/unx/gtk/gtkinst.hxx vcl/inc/win/salinst.h vcl/inc/osx/salinst.h And for completeness, below are the other SalInstances that are empty or have not implemented native code: vcl/inc/unx/salinst.h vcl/inc/headless/svpinst.hxx vcl/inc/qt5/QtInstance.hxx
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9d68c794d67259a38de1465090f6f1e7fb588d62 tdf#155414 include system "reduce animation" preferences It will be available in 24.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.
Marking as resolved/fixed.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/e50d4d5c65ad1d43bb33d72e0f801a5083af6fbc tdf#155414 include system "reduce animation" preferences It will be available in 7.6.0.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.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e320460f9793608ef79aab402b3a03dc28ba7dd5 tdf#155414 gtk3 a11y: Honor gtk setting to reduce animation It will be available in 24.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.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f3a4b6e1d71ed40d84ef65c6626fb7eb77a13545 tdf#155414 kf a11y: Honor KDE Plasma setting to reduce animation It will be available in 24.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.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/609ed2944b030a692c942428afa8bf7c3ac93672 tdf#155414 win a11y: Honor system setting to disable animations It will be available in 24.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.
(In reply to Michael Weghorn from comment #8) > Great, thanks! I could take a look at doing the Windows and Linux > implementations if there's a consensus that this is the way to move forward. That's done as well now. What I noticed during testing on Windows is that in my local master build (as of commit 88790291ddc00bfa18d3f7bcc0825b1ce14cb490 ), the "Marching Ants" animation doesn't work on Windows at all (independent of my change, independent of whether Skia is enabled or not), but still works work in the last commit in the Windows bibisect repo (source commit 4ab8dc5628499b47a065ed2ba54cdd4a90ca43a0). Do others see that as well or is that just an issue with my local build?
(In reply to Michael Weghorn from comment #16) > What I noticed during testing on Windows is that in my local master build > (as of commit 88790291ddc00bfa18d3f7bcc0825b1ce14cb490 ), the "Marching > Ants" animation doesn't work on Windows at all (independent of my change, > independent of whether Skia is enabled or not), but still works work in the > last commit in the Windows bibisect repo (source commit > 4ab8dc5628499b47a065ed2ba54cdd4a90ca43a0). Do others see that as well or is > that just an issue with my local build? I just did a git pull -r in my master build and rebuilt on macOS and the the marching ants animation in Calc works. The march "speed" is only a few redraws per second so it appears like a slow march.
(In reply to Patrick Luby from comment #17) > I just did a git pull -r in my master build and rebuilt on macOS and the the > marching ants animation in Calc works. The march "speed" is only a few > redraws per second so it appears like a slow march. Thanks for testing. Linux (gtk3/kf5) also works fine for me, I only see this in my Windows build.
(In reply to Patrick Luby from comment #17) > I just did a git pull -r in my master build and rebuilt on macOS and the the > marching ants animation in Calc works. The march "speed" is only a few > redraws per second so it appears like a slow march. I would consider that a fail. There should be no animation at all when this is triggered. A few per second is still annoying and distracting. It should act the same as if Tools -> Options -> Advanced -> Open the expert configuration -> AnimationsEnabled is set to False. On Linux systems that I checked in the past (and just now), AnimationsEnabled=False stopped the marching ants completely (there is zero movement, it just shows the dashed line around the copied/pasted selection). Although I have not tested on anything newer than 7.3.7.2, so I hope this hasn't been "revised" or something.
(In reply to crxssi from comment #19) > I would consider that a fail. There should be no animation at all when this > is triggered. A few per second is still annoying and distracting. It > should act the same as if Tools -> Options -> Advanced -> Open the expert > configuration -> AnimationsEnabled is set to False. Who said it does anything differently than the above? Did you look at my patch or test this morning's (25 July 2023) night build that contains my change for macOS? The nightly build works fine for me (I have the system "reduce motion" preference checked on my machine): https://dev-builds.libreoffice.org/daily/master/current.html I had outlined my logic for my patch starting at the following comment: https://bugs.documentfoundation.org/show_bug.cgi?id=155414#c7 @Michael Weghorn and I were comparing behaviors on multiple platforms when animations are *enabled* since he noticed an unexpected behavior on Windows and I was just confirming that the ants march on macOS when AnimationsEnabled is true and the system "reduce motion" preference is unchecked on macOS.
(In reply to Patrick Luby from comment #20) > Who said it does anything differently than the above? Sorry, I misread.
(In reply to Michael Weghorn from comment #16) > (In reply to Michael Weghorn from comment #8) > > Great, thanks! I could take a look at doing the Windows and Linux > > implementations if there's a consensus that this is the way to move forward. > That's done as well now. > > What I noticed during testing on Windows is that in my local master build > (as of commit 88790291ddc00bfa18d3f7bcc0825b1ce14cb490 ), the "Marching > Ants" animation doesn't work on Windows at all (independent of my change, > independent of whether Skia is enabled or not), but still works work in the > last commit in the Windows bibisect repo (source commit > 4ab8dc5628499b47a065ed2ba54cdd4a90ca43a0). Do others see that as well or is > that just an issue with my local build? Yes, I have found this behavior yesterday in LOdev 24.2 and in LOdev 7.6.1. I have reported Bug 156506.
Created attachment 188639 [details] Default Calc General settings on macOS
(In reply to Patrick Luby from comment #23) > Created attachment 188639 [details] > Default Calc General settings on macOS I cannot reproduce this on macOS. I see the "sleeping ants" when I have Accessibility > Display > Reduce motion checked in the System Preferences application and "marching ants" if it is unchecked. Are any of the LibreOffice preferences shown in the following screen snapshot different on your machine?: https://bugs.documentfoundation.org/attachment.cgi?id=188639
(In reply to Patrick Luby from comment #24) > Are any of the LibreOffice preferences shown in the following screen > snapshot different on your machine?: > > https://bugs.documentfoundation.org/attachment.cgi?id=188639 @Michael Weghorn: I wonder if the unexpected Windows behavior is caused by this part of my patch. If you remove block of code after the "Fix failure to stop the animated border when a copy action is performed in a different document" comment, does the copy border appear?: diff --git a/sc/source/ui/view/cellsh.cxx b/sc/source/ui/view/cellsh.cxx index ec5914a..1a8216e 100644 --- a/sc/source/ui/view/cellsh.cxx +++ b/sc/source/ui/view/cellsh.cxx @@ -557,6 +557,18 @@ IMPL_LINK( ScCellShell, ClipboardChanged, TransferableDataHelper*, pDataHelper, rBindings.Invalidate( SID_PASTE_AS_LINK ); rBindings.Invalidate( SID_PASTE_TEXTIMPORT_DIALOG ); rBindings.Invalidate( SID_CLIPBOARD_FORMAT_ITEMS ); // Fix failure to stop the animated border when a copy action is // performed in a different document by cancelling the animated border. // This transferable has lost ownership of the system clipboard so, // in essence, the previous copy action that created this transferable // has been cancelled. if ( !GetViewData().IsAnyFillMode() ) { GetViewData().SetPasteMode( ScPasteFlags::NONE ); // Clear CopySourceOverlay in each window of a split/frozen tabview GetViewData().GetView()->UpdateCopySourceOverlay(); } } namespace {
(In reply to Patrick Luby from comment #25) > @Michael Weghorn: I wonder if the unexpected Windows behavior is caused by > this part of my patch. If you remove block of code after the "Fix failure to > stop the animated border when a copy action is performed in a different > document" comment, does the copy border appear?: @Patrick Luby: It does indeed appear, so that looks like a Windows-only regression from that commit. I'll comment in tdf#156506 as well, probably makes sense to keep further discussion in there.
(In reply to Michael Weghorn from comment #26) > @Patrick Luby: It does indeed appear, so that looks like a Windows-only > regression from that commit. I'll comment in tdf#156506 as well, probably > makes sense to keep further discussion in there. Thanks for checking. I'll add more comments in tdf#156506.