Created attachment 52924 [details] proofpic Some moment in time, the toolbars in my 3.4.3/3.4.4rc1 installation became locked in place and not unlockable at that (see screenshot). Move handles are unavailable, as you can see. Turning toolbar off and on again doesn't help.
Created attachment 52926 [details] LibO 3.3.4: locked toolbars I'm bothered by the same obscure phenomenon. LibO 3.3.4/3.4.3 release on WinXP.
Never saw that with "LibreOffice 3.4.4 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:402)]" I am not sure whether I understand the problem correctly. Is that a permanent problem or "comes and goes"?
For me: all toolbars of user-installed extensions have been affected by this behavior. That issue doesn't occur with the first restart after having added the extension(s); there is nothing the matter for a while. When the issue has cropped up (apparently causeless), then it is a permanent problem (the little handles of the toolbar are missing). A workaround: disable the affected extension - restart LibO - enable the extension again - restart LibO - drag the toolbar to the intended place. I've applied this workaround just now in LibO 3.4.4 release, and these toolbars now are unlocked and movable. I'll observe the extension toolbars for a while ...
Yes, it's a permanent problem and yes, just like manj_k points out, it happens all of a sudden. You just notice once that some toolbars are unmovable. Just my guess after looking in the user configs, it *might* be caused by running different language builds, KeyID included. Then again, it might not. I'll keep mine toolbars in this condition for a while, in case some investigation'd be needed.
Now, looking a little more concentrated, I also see the problem with 3.4.4 for the Lorem Ipsum toolbar. All manj_k's observations reproducible. Can we summarize that really ONLY user toolbars of user installed Extensions are affected?
My experience: Yes, I'm quite sure, only toolbars of user-installed extensions. Default toolbars, adjusted toolbars (Tools > Customize > Toolbars ...) and user-created toolbars (Tools > Customize > Toolbars > New) are not affected.
As far as I can tell, everything added-on here, which has its own toolbar, is affected. OOOLatex, Typograpy, ParaDTP, COOoder, CropOOo.
Just tested (LibO 3.4.4): Switching over to 'Page Preview' (then 'Close Preview') has initiated the locked toolbars problem. Maybe there are also other similar sources of error ...
Created attachment 53475 [details] LibO 3.4.4 · Toolbars: initial state Initial state: the most part of the toolbars are unlocked and movable
Created attachment 53476 [details] LibO 3.4.4 · Toolbars: switched over to 'Page preview' All toolbars of user-installed extensions have been locked (missing handles). That will remain unchanged after 'Close Preview'.
You nailed it. My Lorem Ipsum toolbar showed the prolbem after a page preview. My Multipages toolbar in Calc does not show the problem. Has it ever been observed in Calc?
No, at least, not after `Page Preview'.
Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.
In 3.5, this problem is still there, in build made from git checkout, too.
...and with 3.5 final. The problem is also with the new find toolbar. Is it an user's toolbar ? I do not think that.
(In reply to comment #15) > ...and with 3.5 final. The problem is also with the new find toolbar. Is it an > user's toolbar ? I do not think that. Now the toolbar is unlocked. I do not know why. I do not know if it is because the handle is difficult to see. So, it should be a more visible (contrast) handle for toolbars. Thanks.
I am quite annoyed with this bug too, so I am taking this. :) Looks like a regression from commit http://cgit.freedesktop.org/libreoffice/core/commit/?id=c4461665bd030a555a8b7ffa5bd6717cfb787b9d which introduces the following logic to ToolBarManager::UpdateControllers(): if( !m_bCanBeCustomized ) { [...] xLayoutManager->lockWindow( m_aResourceName ); } and addon toolbars have m_bCanBeCustomized = false anyway, therefore they will be locked. Michael, could you please clarify, what was the purpose of that DisableUICustomization option from the commit above? Is it still useful? Thanks!
Ivan Timofeev committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8e8527e8491c1c6bed1514ac6a8692f6a7f772c1&g=libreoffice-3-6 fdo#42405: remove this, nowadays MenuItemAllowed disables menu entries It will be available in LibreOffice 3.6.
Ivan Timofeev committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3768e71344a298d8e7ac07fb38a97ccf58f83a10 fdo#42405: remove this, nowadays MenuItemAllowed disables menu entries
Accept my thanks. :) Verified (on Win XP32b) w/ LibO-Dev_3.7.0alpha0 W2008R2@20-With-Symbol-Bytemark-Hosting MASTER pull time 2012-06-10 08:54:55 core:cf5001f99fe7a855155c5b3facc241163ccf1777
Ivan Timofeev committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f11040c27f60e3b3c4e31c43de6b74f5b8676c31&g=libreoffice-3-5 fdo#42405: remove this, nowadays MenuItemAllowed disables menu entries It will be available in LibreOffice 3.5.5.
We need exact and correct target information for automated lists in Wiki and LibO Web Site.
The bug may have reappeared in 'Version 4.0.2.1 (Build ID: 400m0(Build:1))' on linux, in my DIY build. At least that's how I understand the lack of move handles on the extensions toolbars (only extensions toolbars seem to be affected this time).
Created attachment 78136 [details] proof
As this is already assigned, going to change status to Assigned
Until now NOT reproducible with server installation of "LibO 4.0.2.2 rc - German UI / German Locale [Build ID: 4c82dcdd6efcd48b1d8bba66bfe1989deee49c3)]" {tinderbox: @6, pull time 2013-03-26 12:00(?)} on German WIN7 Home Premium (64bit) with newly created own user profile. I have 3 Extensions with own toolbars and I did not see that behavior until now. To reopen a FIXED bug only because of observation of 1 single user that he observed similar symptoms (without any confirmation) in his do it yourself build is inappropriate. So I am tending to finish this hijacking here, but shit now has happened ... @Yury, Joel: Please do not open new bugs only because you find something what looks similar. <https://wiki.documentfoundation.org/BugReport_Details#How_to_reopen_Bugs>! @Ivan: It would be great if you could check whether really the old problem reappeared. If we have the same problem because of different problem roots we should reopen a new Bug, what will help keeping overview.
I don't know how to reproduce the problem, can't tell anything about the roots of the problem. The scenario from Comment 8 does not lock toolbars for me, so I assume it is a different problem which needs a different report.
Comment on attachment 78136 [details] proof I obsoleted latest screenshot, but will be available in new "Bug 63651 - toolbars may become irrevocably locked"