Bug 89984 - SIDEBAR: Inconsistent resizing behaviour in the sidebar
Summary: SIDEBAR: Inconsistent resizing behaviour in the sidebar
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
4.2.7.2 release
Hardware: x86-64 (AMD64) All
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 114148 (view as bug list)
Depends on:
Blocks: Sidebar-UI-UX
  Show dependency treegraph
 
Reported: 2015-03-13 08:31 UTC by Gabriel Diosan
Modified: 2020-01-14 15:30 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Sidebar screenshot (124.56 KB, image/png)
2015-03-13 08:31 UTC, Gabriel Diosan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gabriel Diosan 2015-03-13 08:31:29 UTC
Created attachment 114069 [details]
Sidebar screenshot

Inconsistent resizing behaviour in the sidebar.

Steps to reproduce:

1. Open Libreoffice Writer and make sure the sidebar is enabled.
2. Try to reduce the size of the sidebar when the "Properties" tab is selected.
3. Try to reduce the size of the sidebar when the "Styles and Formatting", "Gallery" and "Navigator" tabs are selected.

Current Behaviour:

When the "Properties" tab in the sidebar is selected, the sidebar will only reduce in size to a certain point to allow all elements to be visible. When reducing the size of the sidebar when the other tabs are selected, the sidebar will reduce to nothing (there is no minimum size in these tabs).

Expected Behaviour:

The sidebar should either

1. Reduce only so much to allow all elements to be visible (as per the current "Properties" tab) or
2. Reduce freely as much as the user may want (even allowing a reduction in size to nothing).

One thing to note is that if the user reduces the sidebar without limits, some elements may not be visible and the user may not be aware of them.

I have attached a screenshot to illustrate the problem. Note that this inconsistency is present in Calc, Impress and Draw as well.

Tested with the following setups:

LibreOffice 4.2.7.2 from the Ubuntu 14.04 repo

LibreOffice 4.4.1.2 from the Ubuntu 15.04 repo

LibreOffice Version: 4.5.0.0.alpha0+
Build ID: 33434f47ac44f5cb4612a11b1c28c4582976cb25
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-03-12_00:51:47
Locale: en_AU
Comment 1 A (Andy) 2015-03-13 22:39:58 UTC
Reproducible with LO 4.4.1.2, Win 8.1

I think it should show the behaviour as in 1. of the in the Bug Report mentioned Expected Behaviour, because normal LO dialogs can also not be closed to zero, because it also does not make sense.
Comment 2 tommy27 2016-04-16 07:23:58 UTC Comment hidden (obsolete)
Comment 3 Gabriel Diosan 2016-04-17 04:23:32 UTC
This bug is still present in LibreOffice 5.1.2 on Ubuntu Gnome 16.04.
Comment 4 QA Administrators 2017-05-22 13:24:42 UTC Comment hidden (obsolete)
Comment 5 Xisco Faulí 2017-12-01 12:45:14 UTC
*** Bug 114148 has been marked as a duplicate of this bug. ***
Comment 6 Jan Vlug 2017-12-01 16:06:37 UTC
In reply to comment 4: I confirm that this bug is still there in LibreOffice 5.4.3.2-1.fc27 on Linux Fedora 27.
Comment 7 QA Administrators 2018-12-03 03:58:46 UTC Comment hidden (obsolete)
Comment 8 Gabriel Diosan 2020-01-14 15:30:36 UTC
This bug is still present in the latest LibreOffice 6.5 daily builds.

Version: 6.5.0.0.alpha0+
Build ID: bb9c74189c9d8dd3e4de7efe94b9ba8d158a9133
CPU threads: 12; OS: Linux 5.3; UI render: default; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-01-12_22:58:52
Locale: en-AU (en_AU.UTF-8); UI-Language: en-US
Calc: threaded