Description: Toolbar ‘Locked’ status is not being read from user/registrymodifications.xcu at startup. Steps to Reproduce: 1. Delete user profile: %APPDATA%\libreoffice\4\user folder does not exist 2. Open Writer (not on an existing document) 3. Close Writer 4. Rename new user\registrymodifications.xcu to registrymodifications_base.xcu 5. Open Writer (not on an existing document) 6. Right-click Standard Toolbar, and un-check ‘Lock Toolbar Position’ 7. Close Writer 8. Compare registrymodifications_base.xcu and registrymodifications.xcu. The only meaningful difference is that the ‘Locked’ status for the writer standard toolbar has changed from ‘True’ to ‘False’. 9. Open Writer (not on an existing document) Actual Results: The standard toolbar will start as locked, even though the registrymodifications.xcu has the locked status as False. Expected Results: Standard toolbar will be unlocked at startup. Reproducible: Always User Profile Reset: Yes Additional Info: The same behaviour occurs in Calc, Draw and Impress, and for all of various toolbars I have tested.
Confirmed that opening Writer sets back the Locked flag to True even though it was unlocked in the previous session. This started in 7.2. I can reproduced in: Version: 7.2.7.2 / LibreOffice Community Build ID: 8d71d29d553c0f7dcbfa38fbfda25ee34cce99a2 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Not in: Version: 7.1.0.3 / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded This started with the fix 086fa727cabf46eacfec1a0fd4f6dfe916aa2f04 for bug 131817. (checked with the linux-64-7.2 bibisect repo) In the release notes: https://wiki.documentfoundation.org/ReleaseNotes/7.2#General Heiko, shouldn't unlocked toolbar persist between sessions?
(In reply to Stéphane Guillou (stragu) from comment #1) > Heiko, shouldn't unlocked toolbar persist between sessions? Yes, it should. My patch changed the global locked state, which obviously overrules the individual. It has been questioned a lot- and I wouldn't object if the patch is reverted (needs to be done manually). OTOH, why do we have a global state at all? It sounds like the better solution to me to fix the issue by evaluating both options.