Bug Hunting Session
Bug 42405 - toolbars may become irrevocably locked in place
Summary: toolbars may become irrevocably locked in place
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
3.3.4 release
Hardware: Other All
: medium normal
Assignee: Ivan Timofeev (retired)
URL:
Whiteboard: target:3.6.0.0.beta2 target:3.7.0 tar...
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-30 10:09 UTC by Yury
Modified: 2013-04-17 18:06 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
proofpic (52.06 KB, image/png)
2011-10-30 10:09 UTC, Yury
Details
LibO 3.3.4: locked toolbars (22.18 KB, image/png)
2011-10-30 12:21 UTC, manj_k
Details
LibO 3.4.4 · Toolbars: initial state (56.46 KB, image/png)
2011-11-13 06:10 UTC, manj_k
Details
LibO 3.4.4 · Toolbars: switched over to 'Page preview' (73.65 KB, image/png)
2011-11-13 06:15 UTC, manj_k
Details
proof (18.00 KB, image/jpeg)
2013-04-17 14:27 UTC, Yury
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yury 2011-10-30 10:09:02 UTC
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.
Comment 1 manj_k 2011-10-30 12:21:58 UTC
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.
Comment 2 Rainer Bielefeld Retired 2011-11-13 01:35:54 UTC
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"?
Comment 3 manj_k 2011-11-13 03:34:44 UTC
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 ...
Comment 4 Yury 2011-11-13 03:40:26 UTC
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.
Comment 5 Rainer Bielefeld Retired 2011-11-13 04:48:02 UTC
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?
Comment 6 manj_k 2011-11-13 05:22:47 UTC
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.
Comment 7 Yury 2011-11-13 05:50:34 UTC
As far as I can tell, everything added-on here, which has its own toolbar, is affected. OOOLatex, Typograpy, ParaDTP, COOoder, CropOOo.
Comment 8 manj_k 2011-11-13 05:56:03 UTC
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 ...
Comment 9 manj_k 2011-11-13 06:10:00 UTC
Created attachment 53475 [details]
LibO 3.4.4 · Toolbars: initial state

Initial state: the most part of the toolbars are unlocked and movable
Comment 10 manj_k 2011-11-13 06:15:32 UTC
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'.
Comment 11 Rainer Bielefeld Retired 2011-11-13 07:53:07 UTC
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?
Comment 12 Yury 2011-11-13 09:19:36 UTC
No, at least, not after `Page Preview'.
Comment 13 Björn Michaelsen 2011-12-23 13:25:38 UTC
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.
Comment 14 Yury 2011-12-23 21:36:57 UTC
In 3.5, this problem is still there, in build made from git checkout, too.
Comment 15 Rpnpif 2012-03-04 09:29:11 UTC
...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.
Comment 16 Rpnpif 2012-03-04 09:55:18 UTC
(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.
Comment 17 Ivan Timofeev (retired) 2012-06-08 09:41:28 UTC
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!
Comment 18 Not Assigned 2012-06-08 11:35:22 UTC
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.
Comment 19 Not Assigned 2012-06-08 11:35:49 UTC
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
Comment 20 manj_k 2012-06-10 15:26:20 UTC
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
Comment 21 Not Assigned 2012-06-11 08:10:30 UTC
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.
Comment 22 Rainer Bielefeld Retired 2012-08-03 09:12:44 UTC
We need exact and correct target information for automated lists in Wiki and LibO Web Site.
Comment 23 Yury 2013-04-17 14:24:20 UTC
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).
Comment 24 Yury 2013-04-17 14:27:54 UTC
Created attachment 78136 [details]
proof
Comment 25 Joel Madero 2013-04-17 15:21:36 UTC
As this is already assigned, going to change status to Assigned
Comment 26 Rainer Bielefeld Retired 2013-04-17 17:12:34 UTC
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.
Comment 27 Ivan Timofeev (retired) 2013-04-17 17:23:36 UTC
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 28 Rainer Bielefeld Retired 2013-04-17 18:06:22 UTC
Comment on attachment 78136 [details]
proof

I obsoleted latest screenshot, but will be available in new "Bug 63651 - toolbars may become irrevocably locked"