https://bugs.documentfoundation.org/show_bug.cgi?id=165763
Bug ID: 165763
Summary: After adding a toolbar item, saving apparently hangs
Product: LibreOffice
Version: 24.8.4.2 release
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Calc
Assignee: [email protected]
Reporter: [email protected]
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.
--
You are receiving this mail because:
You are the assignee for the bug.
