Description: Characters don't appear when pressing with CMD+Z pressed for couple of seconds and track changes record enabled Steps to Reproduce: 1. Open attachment 177175 [details] (bug 146452) 2. Punt the cursor at the end of the paragraph 3. Press and hold backspace for say 20 seconds 4. Press and hold CMD+Z Actual Results: Cursor moves, but glyphs don't appear (paint) Expected Results: On each undo a character shows Reproducible: Always User Profile Reset: No Additional Info: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e60ef8651cfb30335471d1622e58c13eebc7d58b CPU threads: 8; OS: Mac OS X 13.4.1; UI render: default; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Fine on Windows with Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c9916d9be9c060d43fc063b76d70629162650fea CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded
Seems specific to macOS as I can't repro on Linux with any UI Arch Linux 64-bit, X11 Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5e9c8d21874eea8cb5adf2ecab1905295af2308f CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 26 September 2023
Reproduced in: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d88779fc86385dde1215fd28b78a69eacc6b4f97 CPU threads: 2; OS: Mac OS X 13.2.1; UI render: Skia/Raster; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded View does not refresh until keys released. Not reproduced in: Version: 7.4.6.2 / LibreOffice Community Build ID: 5b1f5509c2decdade7fda905e3e1429a67acd63d 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 ...in which the view is refreshed word-by-word.
In my local master build, I can reproduce this bug with Skia/Metal, Skia/Raster, and Skia disabled. But in all 3 cases, when I do steps 3 and 4 in https://bugs.documentfoundation.org/show_bug.cgi?id=157130#c0 a second time, I cannot reproduce the bug. So I don't think this is a Skia flushing bug. Maybe Writer is doing some post-document loading work that is blocking repainting? Version: 24.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 77243143dfe8c462a3e4e74a1f5a8a1e58046635 CPU threads: 8; OS: macOS 14.0; UI render: Skia/Metal; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded
I'm really not sure about the result of my bibisect... dennis@dennis mac64-7.5 % git bisect start master oldest Bisecting: 2720 revisions left to test after this (roughly 11 steps) [e6b389930873cd3f4e81c8f22bf7f25ca335fd1a] source cda1dbd978dba5bb8cd64ab28173a579133d4711 dennis@dennis mac64-7.5 % open LibreOffice.app dennis@dennis mac64-7.5 % git bisect bad Bisecting: 1358 revisions left to test after this (roughly 10 steps) [1fbf96da29560805e511ff5983e216b0091ca966] source 59b8813606f084d62dbd3debed7f6b468d916459 dennis@dennis mac64-7.5 % open LibreOffice.app dennis@dennis mac64-7.5 % git bisect bad Bisecting: 678 revisions left to test after this (roughly 9 steps) [e64dcc4a191ab6c8e3e30766b189e2baa201de78] source db63000ea7805ddd762521a7cf39de203dbe6c3f dennis@dennis mac64-7.5 % open LibreOffice.app dennis@dennis mac64-7.5 % git bisect good Bisecting: 339 revisions left to test after this (roughly 8 steps) [865b6c4ce1c96fe67f2d103bfacc34ad51fbc0c9] source 981ba02267af461792c3ff30b8fecc5cd73497a3 dennis@dennis mac64-7.5 % open LibreOffice.app dennis@dennis mac64-7.5 % git bisect bad Bisecting: 169 revisions left to test after this (roughly 7 steps) [5d005a1390a8d6dd9983c19ce32cf26395faae6f] source 53c71a0fa29b98d997ced6c9684c627442cfff94 dennis@dennis mac64-7.5 % open LibreOffice.app dennis@dennis mac64-7.5 % git bisect bad Bisecting: 84 revisions left to test after this (roughly 6 steps) [b583d75aa3d8afac32c493f2738eb3e979df4625] source 86977309bf5ff716ecf74e337a70f0f7f8edb5cd dennis@dennis mac64-7.5 % open LibreOffice.app dennis@dennis mac64-7.5 % git bisect bad Bisecting: 41 revisions left to test after this (roughly 5 steps) [e8b3f452f99f7e236dd879f22a9c0326ef73a812] source 19347d219fb017eeffb998c7ebd857585f263752 dennis@dennis mac64-7.5 % open LibreOffice.app dennis@dennis mac64-7.5 % git bisect bad Bisecting: 20 revisions left to test after this (roughly 4 steps) [483d489f31be2b2775d7b67bb166a83a437c4e7a] source 7c0f0afd58c00211236b138ddd4804099c5aec83 dennis@dennis mac64-7.5 % open LibreOffice.app dennis@dennis mac64-7.5 % git bisect bad Bisecting: 10 revisions left to test after this (roughly 3 steps) [51179611fd2e4763610b4052da85235d9fadf222] source f5ca3291e4f2c25fbff49301d6f3a7ed0017a708 dennis@dennis mac64-7.5 % open LibreOffice.app dennis@dennis mac64-7.5 % git bisect bad Bisecting: 4 revisions left to test after this (roughly 2 steps) [c9e42c881afd3fe01519331ea7f22eed076803d9] source a5d25a06a48b32fd35148265f3c328a28d21f73e dennis@dennis mac64-7.5 % open LibreOffice.app dennis@dennis mac64-7.5 % git bisect bad Bisecting: 2 revisions left to test after this (roughly 1 step) [026d0d46eec6caf0e3a06074ed2adaa6d8fe6e9e] source 18dacc47b212bec440a5f729a2787aa91db89b44 dennis@dennis mac64-7.5 % open LibreOffice.app dennis@dennis mac64-7.5 % git bisect bad Bisecting: 0 revisions left to test after this (roughly 0 steps) [7c097e4eaa85b10b68b6e6695612d8cff017df1b] source 9b558357a3e7a4c908084134d56770809116b4f1 dennis@dennis mac64-7.5 % open LibreOffice.app dennis@dennis mac64-7.5 % git bisect bad 7c097e4eaa85b10b68b6e6695612d8cff017df1b is the first bad commit commit 7c097e4eaa85b10b68b6e6695612d8cff017df1b Author: libreoffice <libreoffice@libreoffices-MacBook-Air.local> Date: Fri Jul 15 05:06:30 2022 +0200 source 9b558357a3e7a4c908084134d56770809116b4f1 source 9b558357a3e7a4c908084134d56770809116b4f1 .../Contents/Frameworks/libchartcorelo.dylib | Bin 3363400 -> 3363400 bytes .../Contents/Resources/config/images_breeze.zip | Bin 1941259 -> 1941259 bytes .../Resources/config/images_breeze_dark.zip | Bin 1937875 -> 1937875 bytes .../Resources/config/images_breeze_dark_svg.zip | Bin 1604530 -> 1604530 bytes .../Resources/config/images_breeze_svg.zip | Bin 1602119 -> 1602119 bytes .../Contents/Resources/config/images_colibre.zip | Bin 2838289 -> 2838289 bytes .../Resources/config/images_colibre_dark.zip | Bin 2738335 -> 2738335 bytes .../Resources/config/images_colibre_dark_svg.zip | Bin 2991210 -> 2991210 bytes .../Resources/config/images_colibre_svg.zip | Bin 3186041 -> 3186041 bytes .../Resources/config/images_elementary.zip | Bin 4259202 -> 4259202 bytes .../Resources/config/images_elementary_svg.zip | Bin 5559010 -> 5559010 bytes .../Resources/config/images_karasa_jaga.zip | Bin 4926692 -> 4926692 bytes .../Resources/config/images_karasa_jaga_svg.zip | Bin 19377292 -> 19377292 bytes .../Contents/Resources/config/images_sifr.zip | Bin 2152720 -> 2152720 bytes .../Contents/Resources/config/images_sifr_dark.zip | Bin 2157114 -> 2157114 bytes .../Resources/config/images_sifr_dark_svg.zip | Bin 1798110 -> 1798110 bytes .../Contents/Resources/config/images_sifr_svg.zip | Bin 1794156 -> 1794156 bytes .../Contents/Resources/config/images_sukapura.zip | Bin 3061989 -> 3061989 bytes .../Resources/config/images_sukapura_svg.zip | Bin 4393321 -> 4393321 bytes LibreOffice.app/Contents/Resources/setuprc | 2 +- LibreOffice.app/Contents/Resources/versionrc | 2 +- 21 files changed, 2 insertions(+), 2 deletions(-) Checking that commit https://git.libreoffice.org/core/+/9b558357a3e7a4c908084134d56770809116b4f1 reveals some chart stuff. Any ideas @stragu ? Ask Noel?
@Dennis: can you: - checkout [7c097e4eaa85b10b68b6e6695612d8cff017df1b] in your repo - confirm _bug_ is there with new profile - checkout HEAD~1, confirm that: - it is source commit db63000ea7805ddd762521a7cf39de203dbe6c3f (i.e. make sure nothing was skipped) - bug is _not_ there with new profile
(In reply to Patrick (volunteer) from comment #4) > But in all 3 cases, when I do steps 3 and 4 > in https://bugs.documentfoundation.org/show_bug.cgi?id=157130#c0 a second > time, I cannot reproduce the bug. Yeah, I'm trying to do some bibisecting it again, but having the problem that it sometimes works - although I do know that "MASTER" is not correctly working in this Interestingly there were some changes: when bibisecting I had to skip source commits 7a7a831809fdcf8a25b907ab7f576cb5210d7b47 and 03e4114097f21f82c7a6a8a64dd08684f09a99b8 because revert was not working at all in these bot builds by keep cmd+z holding. I still try to find some way to bibisecting this again...
does this help: https://gerrit.libreoffice.org/c/core/+/174905 ?
(In reply to Noel Grandin from comment #8) > does this help: https://gerrit.libreoffice.org/c/core/+/174905 ? to clarify: I have "manually" bibisect the bug at the conference back to commit 16429ec437f4bf2acf33b4b2d968b45548f779b4 (with many reboots!) and asked Noel if it is possible, that this bug could cause this behavior. I'm still not sure if this is really the bad commit. I'm unable to build on/for mac. @Patrick as you were able to reproduce this glitch at least once, could you test it?
(In reply to Dennis Roczek from comment #9) > I'm unable to build on/for mac. @Patrick as you were able to reproduce this > glitch at least once, could you test it? I retested this bug on macOS in my local master build with Noel's patch and I cannot reproduce this bug: Version: 25.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 633fad32611e39620218319327428050405a6b1a CPU threads: 8; OS: macOS 15.0.1; UI render: Skia/Metal; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded But...what I do see is that if I follow the steps in comment #0 and I press and hold the Delete key until "Who" is deleted, undoing will stop working (and the Edit > Undo menu item will be disabled) after only half the deleted text is undone if I press and hold Command-Z. Maybe that is normal and I the large number of deletes exceeds some internal "maximum undo steps" limit?
(In reply to Patrick (volunteer) from comment #10) > But...what I do see is that if I follow the steps in comment #0 and I press > and hold the Delete key until "Who" is deleted, undoing will stop working > (and the Edit > Undo menu item will be disabled) after only half the deleted > text is undone if I press and hold Command-Z. > > Maybe that is normal and I the large number of deletes exceeds some internal > "maximum undo steps" limit? LibreOffice - Preferences - LibreOffice - Advanced - Open expert configuration: search for undo and scroll until you see preference name Undo, property Steps. There you can change the value.
(In reply to Buovjaga from comment #11) > LibreOffice - Preferences - LibreOffice - Advanced - Open expert > configuration: search for undo and scroll until you see preference name > Undo, property Steps. There you can change the value. Thanks for the steps. I increased the undo steps from 100 to 1000 in my local master build and I cannot reproduce this bug. All deleted characters are reinserted immediately with no lag in drawing if I press and hold Command-Z. I also increased the undo steps in my LibreOffice 24.2.5.2 and 24.8.2.1 installations and I cannot reproduce this bug with either version so maybe we can marked this as resolved?
(In reply to Patrick (volunteer) from comment #12) > I also increased the undo steps in my LibreOffice 24.2.5.2 and 24.8.2.1 > installations and I cannot reproduce this bug with either version so maybe > we can marked this as resolved? You mean changing the option without using Noel's commit? (if so, I want to reproduce this nasty bug)
(In reply to Dennis Roczek from comment #13) > You mean changing the option without using Noel's commit? > (if so, I want to reproduce this nasty bug) Correct. I tested with the official LibreOffice 24.2.5.2 and 24.8.2.1 releases (i.e without Noel's patch) and the only non-default preference change I made was to increase the maximum undo steps from 100 to 1000. I only tested my local master build with Noel's patch.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/148fa9e9405b143f9fc228d9b5f967cad3139967 tdf#157130 undo and track changes not restoring characters (macOS) 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.
With Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f6c9d1012d20541f6373b51ff3c25d8fd7bc8c69 CPU threads: 4; OS: macOS 11.7.10; UI render: Skia/Raster; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded I can still reproduce the glitch. (In reply to Patrick (volunteer) from comment #12) > (In reply to Buovjaga from comment #11) > > LibreOffice - Preferences - LibreOffice - Advanced - Open expert > > configuration: search for undo and scroll until you see preference name > > Undo, property Steps. There you can change the value. > > Thanks for the steps. I increased the undo steps from 100 to 1000 in my > local master build and I cannot reproduce this bug. All deleted characters > are reinserted immediately with no lag in drawing if I press and hold > Command-Z. Also didn't change the behavior for me. Any idea what I can do? I do see in the status bar, that the counter of characters/words is increasing while holding, but the redraw "on the paper" is missing.
(In reply to Dennis Roczek from comment #16) > Any idea what I can do? I do see in the status bar, that the counter of > characters/words is increasing while holding, but the redraw "on the paper" > is missing. I retested in my local master build and I still cannot reproduce the bug: Version: 25.2.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 6668f6e34860b7f42a1ee06a062496a0cb63ce8e CPU threads: 8; OS: macOS 15.1; UI render: Skia/Raster; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded I had switched to Skia/Raster to match your Help > About output so the only differences that I see is that you are using macOS Big Sur on Intel and I am using macOS Sequoia on Silicon Mac. Have you tried restarting LibreOffice using the Help > Restart in Safe Mode? Do you see any change?
(In reply to Patrick (volunteer) from comment #17) > Have you tried restarting LibreOffice using the Help > Restart in Safe Mode? > Do you see any change? Yes, and did it again, but no change at all. I'm also able to reproduce this bug with different machines: MBA 13" 2019 Retina Intel: Version: 24.8.2.1 (X86_64) / LibreOffice Community Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 CPU threads: 4; OS: macOS 14.7; UI render: Skia/Raster; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded MBP 13" Mid2014 Intel (all repros above) MBP 13" Mid2018 Intel i7 Version: 24.2.5.2 (X86_64) / LibreOffice Community Build ID: bffef4ea93e59bebbeaf7f431bb02b1a39ee8a59 CPU threads: 8; OS: macOS 15.1; UI render: Skia/Raster; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded I can also test following devices: * MBP M1 * MB 2015 (?) * MB 2016 (?) but these devices are in use at this moment. So long story short: either this is an Intel-based bug or something else is fishy. The profile reset does not help, doesn't depend on macos version, nor UI locale. (In reply to Dennis Roczek from comment #16) > I do see in the status bar, that the counter of > characters/words is increasing while holding, but the redraw "on the paper" > is missing. BTW: interestingly, the Status Bar is not updated immediately when removing characters. (is this a bug or a feature ^^)
(In reply to Dennis Roczek from comment #18) > I can also test following devices: > * MBP M1 > * MB 2015 (?) > * MB 2016 (?) Version: 24.8.2.1 (AARCH64) / LibreOffice Community Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 CPU threads: 10; OS: macOS 14.7.1; UI render: Skia/Metal; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded MBP 14" 2021 M1 Also repro.
Created attachment 197306 [details] quickly taken screenshot of my MBP2014 Just to be sure everybody is talking about the same glitch: using the keyboard shortcut for taking a screenshot of the full screen, I do see the attached cursor in the middle of the paper. Shortly after, the text appears. On all mentioned systems with and without resetting the profile folder. (and independent of the gerrit patch through this is only tested on the mbp2014)
(In reply to Dennis Roczek from comment #20) > Just to be sure everybody is talking about the same glitch: using the > keyboard shortcut for taking a screenshot of the full screen, I do see the > attached cursor in the middle of the paper. Shortly after, the text appears. > On all mentioned systems with and without resetting the profile folder. (and > independent of the gerrit patch through this is only tested on the mbp2014) So from your Help > About output in comment #19, you were able to reproduce this bug on the same hardware as me (i.e. a 14" M1 MacBook Pro): Version: 24.8.2.1 (AARCH64) / LibreOffice Community Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 CPU threads: 8; OS: macOS 15.1; UI render: Skia/Metal; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded The problem is that I still cannot reproduce this bug on my machine. I even rebooted into macOS Sonoma on my machine but still could not reproduce this bug. I wonder what is different between our Silicon Mac machines? I am not familiar with the Writer code but IIRC Writer usually does not draw immediately after a key event but instead waits to do all drawing to the window in a painting timer. In your screen snapshot, the cursor and status bar have been redrawn so my first guess is that one or more of Writer's painting timers are never getting a chance to run and they are continually deferred because LibreOffice is not finished processing a key event before another one is in the queue. Only when you stop adding new key events to the queue and LibreOffice has no new input to process does the painting timer finally get a chance to run and draw the undone text. We have more or less the same CPU so I wonder if LibreOffice is competing with some other application or background process for CPU and that might be slowing down processing of the Command-Z events enough to delay Writer's painting timers. Another possible thing to look at is if you have any applications using the macOS accessibility subsystem to listen for changes in LibreOffice. Not sure if the above helps. If any Writer developers are reading this bug, I would be interested to hear if they have any ideas.
I committed a fix for tdf#163764 and that bug had some similarities to this bug. I still cannot reproduce this bug but I am curious if the fix for tdf#163764 has any effect on this bug. You can test the fix for tdf#163764 by installing today's nightly master build: https://bugs.documentfoundation.org/show_bug.cgi?id=163764#c11
(In reply to Patrick (volunteer) from comment #22) > I committed a fix for tdf#163764 and that bug had some similarities to this > bug. > > I still cannot reproduce this bug but I am curious if the fix for tdf#163764 > has any effect on this bug. > > You can test the fix for tdf#163764 by installing today's nightly master > build: > > https://bugs.documentfoundation.org/show_bug.cgi?id=163764#c11 still repro using :-( Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 65caa58206bb64c6fa6e482dbd847af1b3c2c1b0 CPU threads: 8; OS: macOS 15.1; UI render: Skia/Raster; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded (so daily daily/master/MacOSX-x86_64@tb94-TDF/2024-11-12_17.31.41/)
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/9471401da95e7b31785dfbe24597da5484e8c35d tdf#157130 undo and track changes not restoring characters (macOS) 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.