After undocking the sidebar, the sidebar window is unusably small. It is exactly the same width of of a normal non-expanded docked sidebar, so it only shows the icons for different categories. Clicking on these categories gives no response, since the undocked window does not auto-expand to show the area to the left of the category buttons.
Steps to reproduce:
1. Start with a fresh LO config (remove your .config/libreoffice/4 directory)
2. Create a new Writer document
3. Undock the sidebar (Click sidebar menu button, select undock)
We would expect that the undocked sidebar would be large enough to be usable, showing both category buttons and one of the categories. Failing that, we would expect that clicking one of the category buttons would expand the window to include the appropriate dialog.
As explained above, the sidebar just shows the strip of category buttons. Clicking these buttons does not expand the dialog and the sidebar shows no change.
Luckily, LibreOffice does remember the size of the undocked sidebar, so after resizing it once, a user shouldn't be affected again.
There are other flaws with the undocked sidebar size/positioning:
1. An undocked sidebar needs to auto-expand when a button is clicked.
2. An undocked sidebar currently allows you to make it unusably small. You can currently resize the window to be 1 pixel by 1 pixel.
3. It shows the snapping arrow when it is only slightly wider than the category icon column. It does not snap and this is not a useful feature when the sidebar is undocked.
4. The undocked window appears positioned at the top left of the main LibreOffice window instead of the right side... most of the time. I've reported this in bug 88181.
TESTING with Lo 184.108.40.206 + Ubuntu 14.04
(In reply to tmacalp from comment #0)
> After undocking the sidebar, the sidebar window is unusably small. It is
> exactly the same width of of a normal non-expanded docked sidebar, so it
> only shows the icons for different categories. Clicking on these categories
> gives no response, since the undocked window does not auto-expand to show
> the area to the left of the category buttons.
> Steps to reproduce:
> 1. Start with a fresh LO config (remove your .config/libreoffice/4 directory)
> 2. Create a new Writer document
> 3. Undock the sidebar (Click sidebar menu button, select undock)
> We would expect that the undocked sidebar would be large enough to be
> usable, showing both category buttons and one of the categories. Failing
> that, we would expect that clicking one of the category buttons would expand
> the window to include the appropriate dialog.
> As explained above, the sidebar just shows the strip of category buttons.
> Clicking these buttons does not expand the dialog and the sidebar shows no
CONFIRMED: Skinny sidebar looks kind of svelte and cool, but is basically useless.
Status -> NEW
Time to call in the cavalry. UX posse: time to do your thing!
Component -> ux-advise
Confirming this on Windows 7 sp1, 64-bit en-US
Build ID: a3603970151a6ae2596acd62b70112f4d376b990
That is a bug. With a clear profile, the undocked Sidebar is opening to a width slightly less than that of of the Tabbar, with no indication of the Deck available to the left by drag out. Clicking any Tab element is not opening its content panel in the Deck. Worse, when dragging left to open the deck, an unidentified Arrow is becomes visible before any of the Deck's content panel is exposed.
Adding to 4.4 MAB, this is very broken.
Created attachment 112321 [details]
Undocked Sidebar showing Tabbar being dragged left to open
(In reply to V Stuart Foote from comment #2)
> Adding to 4.4 MAB, this is very broken.
Seems that with an empty profile, and with the Sidebar now opening to display just the Tabbar (no Deck showing) by default, when immediately undocked there is no parent window defined--which would otherwise be used to set the width of the deck when displayed by RequestOpenDeck()
Clicking on any of the Tab buttons does shift to its element--but with no defined width to open to, the Deck does not appear (so drawn with 0 width?).
Seems like maybe some minimum width should be assigned for a newly created deck window to open with. That way the undocked Tabbar would have functional Decks.
This came in with Kendy's "Default to collapsed sidebars everywhere but in Impress." -- http://cgit.freedesktop.org/libreoffice/core/commit/?id=4e8df25adcc930657eb35cdc527bf8d751fc72e7
But, something more is needed to handle case of immediately undocking tabbar when no size for deck had been established.
Couldn't reproduce with the latest master on Debian Stretch. Could you please verify it is still valid?
Build ID: afeff9102c2935139de4efd40fd2286dce396706
CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: gtk3;
Locale: tr-TR (en_US.UTF-8); Calc: group
(In reply to Muhammet Kara from comment #6)
> Couldn't reproduce with the latest master on Debian Stretch. Could you
> please verify it is still valid?
> Version: 220.127.116.11.alpha0+
> Build ID: afeff9102c2935139de4efd40fd2286dce396706
> CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: gtk3;
> Locale: tr-TR (en_US.UTF-8); Calc: group
I can still repro in
Build ID: 1f8c3e3b78e0abb96d06a51eca354ae7ade5deb2
CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: x11;
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-11-01_22:57:04
Locale: en-US (en_US.UTF-8); Calc: group
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
Build ID: 1:6.1.2-0ubuntu1
CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: gtk3;
Locale: en-US (en_US.UTF-8); Calc: group threaded
This is still present, but not an issue on macOS
If you expand the sidebar once after having undocked it, it will remain so for subsequent LibreOffice starts
If I go through the bug prioritization flow chart, this is just a minor, trivial issue, but I'll put it one step above
Version: 18.104.22.168 (x64)
Build ID: a64200df03143b798afd1ec74a12ab50359878ed
CPU threads: 2; OS: Windows 10.0; UI render: default; VCL: win;
Locale: en-US (en_US); UI-Language: en-US
on linux I don't have this issue with resizing.
Build ID: a8c218a52a639b0e7f689dea878a0421702628e0
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5
Locale: en-US (en_AT.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-09-25_22:25:07
*** Bug 135291 has been marked as a duplicate of this bug. ***