Description: With a default installation of LibreOffice Calc, the blue border around the focus cell doesn't reliably update when the current cell is changed with the arrow keys. The shading on the row/column headers does move, showing that it is just the rendering of the border around the cell that is not correctly refreshed. Usually it updates with a lag of a second or two, but sometimes it waits until the next keyboard/mouse interaction, which can result in a situation where the selected cell appears to lag one step behind where it should be. See video at https://www.dropbox.com/scl/fi/y956lhdki9qd325lg5r3y/Skia-hardware-rendering.mov?rlkey=s9sw7j26fy2ln78t5ndxk8poa&dl=0 You can see the cell highlight is not staying in sync with the highlight in the column/row headers. This issue disappears when I select 'force skia software rendering' in LibreOffice preferences. Steps to Reproduce: 1. open Calc and put some values in a few cells 2. Use arrow keys to move the current cell around 3. Observe glitchy update of the cell border Actual Results: Cell border showing which cell has the focus does not refresh to correctly show which cell has the focus. See linked video. Expected Results: Border moves immediately when arrow keys used and stays in sync with the indicators on the column/row headers. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.6.0.3 (AARCH64) / LibreOffice Community Build ID: 69edd8b8ebc41d00b4de3915dc82f8f0fc3b6265 CPU threads: 8; OS: Mac OS X 13.5.2; UI render: Skia/Metal; VCL: osx Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded Hardware is Apple Macbook Air M2 with Ventura 13.5.2
Thanks for filing this. This is a regression from what I can tell and I have been noticing this for a while. Sadly with no clear steps to trigger the mis-alignment of cell highlight and row / column highlight. Even with "Force Skia software rendering" disable having a hard time to reproduce. But I am positive I have seen this many times in recent months. Affecting all macs since I reproduced on intel mac and OP has apple silicon. I am Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b3fdd999f87312447d03915585812b3a5cd48141 CPU threads: 8; OS: Mac OS X 13.5.2; UI render: Skia/Raster; VCL: osx Locale: en-US (en_DE.UTF-8); UI: en-US Calc: threaded
Please disregard the version info I posted, since I am not 100 % sure whether I encountered this issue on main or stable build.
(In reply to steve from comment #2) > Please disregard the version info I posted, since I am not 100 % sure > whether I encountered this issue on main or stable build. Since you have a recent nightly master build, can you run LibreOffice with Skia/Metal enabled from the Terminal, force the bug to be occur in an empty document, quit LibreOffice, and then post any log messages that LibreOffice printed in the Terminal? Nightly master builds usually print a message for many unexpected errors and usually the error messages are unique enough that a can grep for the message to find where in the LibreOffice code the error is occurring. My hope is that this bug is due to some unexpected error that maybe we can handle.
I can reliably reproduce - it seems to happen every time I move into or out of a cell that is not empty. I might be able to try reproducing on the nightly build. What does the part of the directory after the @ mean on the nightly build server? Should I use MacOSX-x86_64@tb81-TDF or MacOSX-x86_64@tb92-TDF ?
(In reply to Seb from comment #4) > I might be able to try reproducing on the nightly build. What does the part > of the directory after the @ mean on the nightly build server? Should I use > MacOSX-x86_64@tb81-TDF or MacOSX-x86_64@tb92-TDF ? The text after the @ character are the build server name. Download from whichever build server has latest time stamp next to it.
(In reply to Patrick Luby from comment #5) > The text after the @ character are the build server name. Download from > whichever build server has latest time stamp next to it. I forgot to mention that the nightly builds are not codesigned so you have to invoke the following Terminal command on the .dmg file before you open it: xattr -d com.apple.quarantine /path/where/you/downloaded/dmg/file Also, when you do the "drag and drop" installation, the nightly builds will create an application called "LibreOfficeDev" in your Applications folder. So, to run the nightly master build from the Terminal, invoke the following command: /Applications/LibreOfficeDev.app/Contents/MacOS/soffice Hope that helps.
This was the only terminal output while I opened Calc, typed 'a' into the first cell, moved right (slightly delayed border move) and moved left again (border left behind). saw@Sebs-MacBook-Air-2 dev % /Volumes/LibreOfficeDev/LibreOfficeDev.app/Contents/MacOS/soffice warn:sfx.control:79221:1214247:sfx2/source/control/dispatch.cxx:1211: Childwindow slot missing: 25917 warn:sfx.control:79221:1214247:sfx2/source/control/dispatch.cxx:1211: Childwindow slot missing: 26189 warn:sfx.control:79221:1214247:sfx2/source/control/dispatch.cxx:1211: Childwindow slot missing: 26190 warn:sfx.control:79221:1214247:sfx2/source/control/dispatch.cxx:1211: Childwindow slot missing: 25917 warn:sfx.control:79221:1214247:sfx2/source/control/dispatch.cxx:1211: Childwindow slot missing: 26189 warn:sfx.control:79221:1214247:sfx2/source/control/dispatch.cxx:1211: Childwindow slot missing: 26190 warn:sfx.control:79221:1214247:sfx2/source/control/dispatch.cxx:1211: Childwindow slot missing: 25917 warn:sfx.control:79221:1214247:sfx2/source/control/dispatch.cxx:1211: Childwindow slot missing: 26189 warn:sfx.control:79221:1214247:sfx2/source/control/dispatch.cxx:1211: Childwindow slot missing: 26190 warn:vcl:79221:1214247:vcl/osx/salmenu.cxx:691: unmapped accelerator key warn:vcl:79221:1214247:vcl/osx/salmenu.cxx:691: unmapped accelerator key warn:vcl:79221:1214247:vcl/osx/salmenu.cxx:691: unmapped accelerator key warn:sfx.control:79221:1214247:sfx2/source/control/dispatch.cxx:1211: Childwindow slot missing: 25917 warn:sfx.control:79221:1214247:sfx2/source/control/dispatch.cxx:1211: Childwindow slot missing: 26189 warn:sfx.control:79221:1214247:sfx2/source/control/dispatch.cxx:1211: Childwindow slot missing: 26190 This is with nightly build Version: 7.6.2.0.0+ (X86_64) / LibreOffice Community Build ID: 72065854ce9af62a009d582e07a894de525dfb4b CPU threads: 8; OS: Mac OS X 13.5.2; UI render: Skia/Metal; VCL: osx Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded Any help?
I get the same messages after changing the setting to software skia rendering so I guess it's no help?
(In reply to Seb from comment #8) > I get the same messages after changing the setting to software skia > rendering so I guess it's no help? I don't see any Skia related messages so unfortunately the output doesn't help. Fortunately, I can now reproduce this bug in my local build Mac Silicon so I can see if I can debug this directly. I will need to do some debugging to see if I can narrow down what is different about Skia/Metal and Skia/Raster that might be causing this bug. My first guess is that drawing with Skia/Metal is not being immediately "flushed" to the screen.
After doing a little debugging, I have a new theory: somewhere in the LibreOffice code is waiting for a key entry event. If you arrow around a range of non-empty cells rapidly (i.e. press several arrow keys in a row), the selected cell border keeps up with the selected column and row. But sometimes there is a lag after the last arrow key is pressed. Next step: see if I can find which LibreOffice code is calling AquaSalInstance::AnyInput(VclInputFlags::KEYBOARD) in a loop.
(In reply to Patrick Luby from comment #10) > Next step: see if I can find which LibreOffice code is calling > AquaSalInstance::AnyInput(VclInputFlags::KEYBOARD) in a loop. I forgot to mention why I think that this "waiting for a key event" might be the cause of this bug. A key piece of data is that the column and row are drawn in a timer and the selected cell border is drawn is a separate timer that fires after the column and row timer. At the end of each timer, all of the drawing done by the timer is flushed to the window. So, when everything runs perfectly. the selected cell cursor draws almost (but not quite) the same time as the column and row. The problem, I think, is that with Skia/Metal flushing can be a lot slower than with Skia/Raster. The slower flushing, in turn, causes some other timer to fire before the selected cell drawing timer. I suspect that this mystery timer is looping waiting for more keyboard events.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f4c2c7c79cfe4464ac596afda37b8904d06969db tdf#157312 Don't change priority 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.
Found the timer that was jumping in front of the timer that repaints the selected cell border. My fix for this bug should be in tomorrow's (23 September 2023) nightly master build.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/41b8243464a0aa4730e4c6177f1c4fd6adc260d9 tdf#157312 Don't change priority It will be available in 7.6.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.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/439f487d14ce4afaa25b8aa23cf954ae2ddaeb26 tdf#157312 Don't change priority It will be available in 7.5.8. 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 tested a new nightly build and can confirm the issue is resolved. Many thanks Patrick!
verified as per https://bugs.documentfoundation.org/show_bug.cgi?id=157312#c16
*** Bug 157507 has been marked as a duplicate of this bug. ***