Bug 50651 - Toolbar: room for toolbar remains after closing from context menu
Summary: Toolbar: room for toolbar remains after closing from context menu
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
3.4.1 RC1
Hardware: Other All
: medium minor
Assignee: Ivan Timofeev (retired)
URL:
Whiteboard: target:3.6.0.0.beta1 target:3.7.0
Keywords: regression
: 36475 52466 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-06-03 13:29 UTC by Thomas Arnhold
Modified: 2012-08-03 09:26 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Toolbar before close (49.26 KB, image/png)
2012-06-03 13:29 UTC, Thomas Arnhold
Details
Toolbar after closing with issue (44.05 KB, image/png)
2012-06-03 13:29 UTC, Thomas Arnhold
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Arnhold 2012-06-03 13:29:25 UTC
Created attachment 62464 [details]
Toolbar before close

There is a repaint issue after closing a toolbar with "Close Toolbar" from the context menu.

Steps to reproduce:

1. Right click on any toolbar (i.e. Formatting Toolbar or List Toolbar) and select "Close Toolbar" from the context menu. If it is the last toolbar in this "row" there is a repaint issue. See attachments.

Specs: Linux, 32 bit, master (27cd9157ac0e824197aa40c67fe6a4bfab3b2e38)
Comment 1 Thomas Arnhold 2012-06-03 13:29:51 UTC
Created attachment 62465 [details]
Toolbar after closing with issue
Comment 2 Thomas Arnhold 2012-06-03 13:32:26 UTC
Also affects Libo 3.5.4 release (not checked earlier releases).
Comment 3 Rainer Bielefeld Retired 2012-06-04 08:51:20 UTC
I am not 100% sure whether I understand the problem.

If the problem is that the place for the toolbar remains I can reproduce the problem with "LibreOffice 3.5.4.2  German UI/Locale [Build-ID: 165a79a-7059095-e13bb37-fef39a4-9503d18] on German WIN7 Home Premium (64bit):

1. Open a new empty WRITER document
2. Arrange toolbars so that only docked Find Bar remains at the bottom.
3. <control+f> will make the Find Bar appear
   (as expected
4. <esc> will make the Find Bar disappear, and as expected also the room
   for the toolbar disappears
5. <control+f> will make the Find Bar appear
6. right click on find Bar
7. Context menu 'Close Toolbar'
   Expected: as on step 4
   Actual: unexpectedly the room for the toolbar remains

Room also disappears when I close toolbar from Menu 'View'.

The inconsistence I observed was not in 3.3.3 (I tested with DRAWING toolbar in WRITER), but already in 3.4.1RC

@Thomas:
Did I describe the correct problem? Please feel free to revert my changes if I am wrong.
Comment 4 Thomas Arnhold 2012-06-04 09:07:41 UTC
Rainer: Yes, absolutely correct. This issue remains with all toolbars, if they are the one and only in one "row" like the Findbar. For example: Right click on the standard toolbar and close it within the context menu. The room will remain until the window gets resized.
Comment 5 Rainer Bielefeld Retired 2012-06-04 09:15:17 UTC
@Ivan:
Willing to do some more UI cleanup?
Comment 6 Ivan Timofeev (retired) 2012-06-05 12:17:00 UTC
Hmm... I am not an expert in this area, but...

commit a81b5347 [1] fixed "Bug 67769 - Toolbar closed with toolbar menu "Close ..." reappears unexpectedly"[2] using DockingWindow::Close (toolbar is a subclass of DockingWindow) instead of LayoutManager::destroyElement, claiming that LayoutManager is a listener, so it will react on toolbar closing. And the fix was verified, so it worked at that time (2007). But now it does not work, it seems LayoutManager does not aware of toolbar closing. No idea of why and how it was broken between 3.3 and 3.4 (I wonder why it worked before).

If I place back the old destroyElement call, this bug is not reproducible and the old Bug 67769 is... still not reproducible! :) So, probably that is what I will do.

[1] http://cgit.freedesktop.org/libreoffice/core/commit/?id=a81b5347
[2] https://issues.apache.org/ooo/show_bug.cgi?id=67769

P.S. Reproducible also with AOO 3.4, I did not test 3.3...
Comment 7 Ivan Timofeev (retired) 2012-06-06 00:41:55 UTC
> If I place back the old destroyElement call, this bug is not reproducible and
> the old Bug 67769 is... still not reproducible!

No, it is reproducible, with the "Form Controls" toolbar...

Actually there was a huge refactoring, and now ToolbarLayoutManager is a listener for toolbar closing, not LayoutManager.
Comment 8 Not Assigned 2012-06-06 00:43:37 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=04ffb240d904d04875f91efae333efa605233ad5&g=libreoffice-3-6

fdo#50651: update layout after toolbar destruction


It will be available in LibreOffice 3.6.
Comment 9 Not Assigned 2012-06-06 00:44:03 UTC
Ivan Timofeev committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ca9967344682a0d3e25d7ebcc9df2c679cb082f8

fdo#50651: update layout after toolbar destruction
Comment 10 Korrawit Pruegsanusak 2012-06-06 01:40:52 UTC
*** Bug 36475 has been marked as a duplicate of this bug. ***
Comment 11 Rainer Bielefeld Retired 2012-08-03 09:19:14 UTC
We need exact and correct target information for automated lists in Wiki and LibO Web Site.
Comment 12 Ivan Timofeev (retired) 2012-08-03 09:26:31 UTC
*** Bug 52466 has been marked as a duplicate of this bug. ***