Description: If a value is entered in a cell, control goes to the next cell. Normally Undo will undo the change in the previous cell. However if the sheet has the Selection Changed event linked to a macro that writes a value to a cell somewhere in the spreadsheet, Undo ends up taking control to the cell that was written by the Selection Changed event handler instead of the "last" modified cell. If the Selection Changed event handler writes to a cell in a different sheet, sometimes Undo takes control to the cell in the other sheet and other times the spreadsheet just crashes. It appears that when Undo is hit, it first tries to go back to the previous cell to change it back to its previous state, but the change in the selected cell then causes the Selection Changed handler to start execution before Undo can make its change. The Selection Changed handler takes control to the cell where it does its write and control then goes back to Undo. However, at this point it looks like Undo gets confused because it is now in a different cell, and the situation appears to be worse if that cell is on a different sheet. Steps to Reproduce: 1. Create a spreadsheet with two sheets, Sheet 1, and Sheet 2 2. Create this macro in Sheet 1 Sub CrashTest (Event As Variant) Dim cell as object cell = thisComponent.sheets.getByName("Sheet 2").getCellByPosition(2,2) cell.value = 4 End Sub 3. Create a Selection Changed sheet event in Sheet 1 that is linked to CrashTest. 4. Enter a value in a cell in Sheet 1 and then Undo Actual Results: Either control goes to cell C3 in Sheet 2 or crash. Expected Results: Selection Changed event does not get triggered and instead the previous value entered is undone. Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: Version: 6.3.5.2 (x64) Build ID: dd0751754f11728f69b42ee2af66670068624673 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: CL We are seeing this problem on Windows and Linux running several different versions of LibreOffice.
I noticed that the Event object is passed to the macro when it is triggered. Is there anything contained in Event that would indicate that Selection Changed was triggered by Undo? If so I could work around this by exiting the macro if it was triggered by Undo. There appears to be no problem as long as the event handler does not write to a cell. For our application, we do not want this to happen anyway if the user is just trying to do an Undo.
I can't reproduce it in Version: 7.0.0.0.alpha1+ Build ID: 1ffe59ef31186e36ad0aa7bbcdd32e407ee8d26c CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Created attachment 161053 [details] Demo of Undo Crashes Attached is a small spreadsheet demonstrating the bug we have encountered. To test, enter a value anywhere on Sheet1 and hit <Enter>. The macro will write a "4" to cell C3 on Sheet2, but control will go to the next row on Sheet1. Then either hit CNTR/Z or select Undo from the Edit menu. I have done additional testing and find that about 5% of the time the Undo will succeed. Most of the time control will go to cell C3 on Sheet2 or crash. The failure has occurred with version 6.3.5.2 on Windows and versions 5.4.7.2, 6.0.7.3 and 6.3.3.2 on Linux. Version 6.0.7.3 is the supported version on my Linux distribution. This looks to me like some type of timing issue and therefore might not be reproducible on all systems. It looks like it succeeds if it is able to complete the undo before the Selection Changed event triggers the macro.
A sample spreadsheet has been attached to the previous comment.
Repro Version: 7.0.0.0.alpha1+ (x64) Build ID: 442c7b95e2ee94b66a9854d0cb22f8ecb76532c6 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 and with Version: 5.0.0.0.alpha1+ Build ID: ab465b90f6c6da5595393a0ba73f33a1e71a2b65 Locale: nl-NL (nl_NL) probably also in 3.5.7.2 (did crash, but not exact the same steps)
Created attachment 161098 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today + gen rendering, I had an assertion.
Also crashing in Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
No crash, please retest. Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 2f4f4cbeb8e50081d607b86b0475b93971c40ab8 CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Dear ggordon, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I was able to reproduce this issue on Windows 11 using LibreOffice 25.2.3.0 (x86_64). Steps: 1. Created Sheet1 and Sheet2 2. Added the macro: ``` Sub CrashTest(Event As Variant) Dim cell As Object cell = ThisComponent.Sheets.getByName("Sheet2").getCellByPosition(2,2) cell.Value = 4 End Sub ``` 3. Assigned the macro to Sheet1 > Event: Selection Changed 4. Entered values into multiple cells in Sheet1 (e.g., A1, A2, A3) 5. Pressed Ctrl + Z or Alt + Z **Observed behavior:** - On the first run, pressing Ctrl + Z switched focus to Sheet2 unexpectedly - On repeated execution, LibreOffice Calc crashed This confirms that the bug still occurs in the latest stable version (25.2.3.0) on Windows 11.
Created attachment 201409 [details] The slightly changed demo file mentioned in comment by jag
Tests with V25.8.0.0.beta1 I didn't succeed with getting the bug reproducible, but ... Additional note to get a situation where the bug will show with a higher probability: Show Sheet1 Create a new window and make both winows small enough to see the relevant ranges of both sheets at the same time. Change the selection in Sheet1. Play with both windows and hit Ctrl+Z now and then. MY result: Sooner or later I get the reported crash. Remark: The new attachmenmt contains a small change to the event handling Sub: The assignment for Sheet1.C3 is changed from =4 to =Now(). The number format string applied to the cell is now YYYY-MM-DD HH:MM:SS Additional obervation: The time needed for the loading of the small demo file and getting to the point where permission for macros is aked for is absurdly long.