Description:
This one is strange, please read the whole report.

I have an ODS file. I once upon a time made a custom toolbar and stored it in the ODS file. I wanted to update the toolbar so I deleted it, re-created it, stored in the ODS file, and have been re-adding items.  
  
First I re-added the "About" item and the ODS saves fine.

Adding the next item causes saving to apparently hang. Turns out it's not hung, it just takes a _long_ time.

Doing a test save of a random change saves in a reasonable amount of time.

So the problem is that, a save after adding a toolbar item to a customer toolbar stored in the ODS takes _much_ longer than it should.

Steps to Reproduce:
# Prelude
1. Reset user profile by moving ~/.config/libreoffice/4/user to ~/.config/libreoffice/4/user-backup
2. Open Calc with no file
3. Set macro security to Medium: Tools -> Options -> LibreOffice -> Security -> Macro Security -> Medium
4. Close Calc

# Get example file
5. Download the attached example file
6. Make two copies

# When opening the example files, you'll have to "Enable macros". Doing these steps with macros disabled does not reproduce the problem.
# Please do not trust me/the downloads! Check the macros before enabling them. There's nothing untoward, but better safe than sorry.

# A "reasonable" save
7a. Open one copy, sheet 'Summaryo' should be selected.
7b. Type 'a' in cell A1
7c. Save
7d. Observe that the save proceeds in a reasonable amount of time: I timed this at around 0:07. (This isn't really reasonable actually, saving should be pretty close to instant, but that's a different bug.)

# A "hung" save
8a. Open the other copy
8b. Tools -> Customize -> Toolbars
8c. Scope -> Holdings--save-hang-blank.ods
8d. Target -> HoldingsBar
8e. Category -> Macros
8f. Available Commands -> Holdings--save-hang-blank.ods :: Standard :: Module1 :: Create_Blank
8g. Click the Add Item button to add Create_Blank to the Assigned Commands list, it should be the second item after "About LibreOffice"
8h. Ok
8i. Observe that the custom toolbar now has a text entry "Create_Blank"
8j. Save the ODS
8k. Observe that the save takes an unreasonable amount of time: I timed this at around 1:42.

# Removing sheets from the example speeds up the save, until the "hung" case is reasonable when there's about 1 - 4 sheets remaining.
# So this is dependent on the macros, and the number of sheets.

Actual Results:
Saving takes a very long time; long enough most users will consider Calc to have hung, and kill it.



Expected Results:
Save is as fast in the "hung" case as in the "reasonable" case. There's no reason that changing the toolbar should have this kind of effect.


Reproducible: Always


User Profile Reset: Yes

Additional Info:
Version: 24.8.4.2 (X86_64) / LibreOffice Community
Build ID: 480(Build:2)
CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: en-US (C.UTF-8); UI: en-US
Ubuntu package version: 4:24.8.4~rc2-0ubuntu0.24.04.1~lo1
Calc: threaded


At least it's not really hung, so one can just wait it out. A regular user isn't likely to do that though.
  
I suspect that something with the toolbar-change-save is being done, incorrectly, on a per-sheet basis.

When setting up the example for reproduction purposes, I thought I should remove the python macros too, since they didn't seem to be involved. While doing this I discovered that the Update button on the Summaryo sheet had a python macro bound to the "Mouse button pressed" event, from long ago testing. My initial timing of the "hung" case was 3:04; after removing that event binding the problem dropped to the reported 1:42.
The point here is that whatever is wrong with the toolbar-change-save is also probably wrong with the form-controls-save.