Version 6.1.6 and below does not have this problem. The regression began with 6.2.0 and still continues in 6.4.5 and in the latest 7.1.0 alpha. I am using the current Debian stable with KDE plasma 5. When using LibreOffice with the gtk3, kde, or qt5 VCLPLUGIN, if the sidebar is undocked, it cannot be re-docked by dragging the frame to the side of the LibreOffice window. If SAL_USE_VCLPLUGIN=gen, then it works by dragging. I discovered this because if the sidebar gets mistakenly undocked then for some reason I sometimes cannot get it to re-dock by using the dock menu command without closing all instances of the program and re-starting LibreOffice. I then discovered that the dragging method never works from version 6.2.0 forward except when using "gen".
confirm in Version: 7.0.0.1.0+ Build ID: 30ea3ba86b110db68c19815c5c67d4d315c091bf Потоков ЦП: 4; ОС: Linux 5.5; Отрисовка ИП: по умолчанию; VCL: kf5 Locale: ru-RU (ru_RU.UTF-8); ИП: ru-RU TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:libreoffice-7-0, Time: 2020-07-03_04:42:21 Calc: threaded
So does keyboard docking <Ctrl><Shift>+<F10>, or <Ctrl>+Double Mouse click dock the Sidebar, or other UI windows? See also bug 92122 identifies issues with Windows WDM where LO is not getting notice of windows movement--Windows "Show window content while dragging--and could be similar with KDE backend(s). =-help ref-= https://help.libreoffice.org/6.4/en-US/text/shared/guide/autohide.html?&DbPAR=WRITER
(In reply to V Stuart Foote from comment #2) > So does keyboard docking <Ctrl><Shift>+<F10>, or <Ctrl>+Double Mouse click > dock the Sidebar, or other UI windows? The key here is that dragging to dock NEVER works except with gen. The other methods work initially but will often quit working (and at the same time) for some as yet unknown reason. I don't know if that's a related or a separate bug. The point here is that when the other methods quit working, I can't try dragging, because that never works. Other UI windows behave the same way. > See also bug 92122 identifies issues with Windows WDM where LO is not > getting notice of windows movement--Windows "Show window content while > dragging--and could be similar with KDE backend(s). But I don't see how that would explain why version 6.1.6 and prior would work by dragging on the same system. > > =-help ref-= > https://help.libreoffice.org/6.4/en-US/text/shared/guide/autohide. > html?&DbPAR=WRITER
Sounds like it was the same as tdf#64438. (In reply to David from comment #3) > But I don't see how that would explain why version 6.1.6 and prior would > work by dragging on the same system. If you want to help figure that out, you can try to bibisect what change introduced the changed behaviour, s. https://wiki.documentfoundation.org/QA/Bibisect/Linux for more information. The reason *might* be that another VCL plugin is used now than before; do you know which one was used for your 6.1.6 case? *** This bug has been marked as a duplicate of bug 64438 ***
(In reply to Michael Weghorn from comment #4) > Sounds like it was the same as tdf#64438. > > > The reason *might* be that another VCL plugin is used now than before; do > you know which one was used for your 6.1.6 case? I used the appimages from https://libreoffice.soluzioniopen.com/index.php/old-versions/ to see where it began to fail. I changed nothing else. > > *** This bug has been marked as a duplicate of bug 64438 *** I disagree. This is obviously a regression from version 6.1.6. Bug 64438 is for an issue starting in version 4. The description for that bug doesn't specify, but for versions 6.2 and later, there is no outline of the frame when trying to drag it when using anything other than gen.
This bug specifically addresses the failure of being able to dock within KDE BY AND ONLY BY dragging when using anything other than gen. Other docking methods still work. This bug is not meant to address if other methods stop working after an indeterminate time for some as yet unknown reason which may or may not be related and which is fixed by closing all instances of LO and restarting. The title for bug 64438 states "Dockable panels in LibreOffice not dockable using KDE" This is not the issue meant to be addressed by this bug. While the initial comment in bug 64438 addresses the failure to be able to dock by dragging, that bug as described by the title and the rest of the comments is about the total failure to dock by any method. The comments in that bug do not give any consistent functional workarounds within LO. I have experimented with versions 4.0.0, 4.1.0, and 4.4.7. In all cases I have been able to dock the navigator by pressing ctrl and double-clicking on an empty spot at the top of the frame. Once the sidebar was introduced, it can also be docked from the menu or by pressing ctrl and double-click on the empty space at the bottom of the frame. So maybe that bug should now be a WFM. Beginning at some point in version 5 (I have not yet tested exactly when), docking could be done by dragging the navigator or sidebar window. This has now failed once again beginning with version 6.2.0, in spite of any of the other docking methods still working. This is in contrast to bug 64438, for which there was no reliable workaround.
So I've tested the TDF LO 6.1.6 release. The build had just gtk (gtk2), kde4 and gen VCL backends. kde4 is basically just a thin wrapper around gen, using X11 everywhere, except for the QStyle to look like KDE. The sidebar docking behavior works in gen and kde4, but not in gtk. AFAIK that feature was introduced in 4.1; at least that's the version, which first has the "Menu/Tools/Options/LibreOffice/Advanced - Enable experimental Sidebar" checkbox, while 4.0 hasn't. I tested the TDF build 4.1.6.2, which has gen, gtk and kde (kde3!) VCL backends. gen works, gtk not and I can't test kde, but I guess it would work, because kde4 works and kde also just wraps the gen backend. While kde4 was just a ported kde, still relying on gen, qt5 and kf5 were developed from scratch just using Qt APIs (there are some patches to build qt5 on Windows and MacOS. LO generally works but has many limitations, like missing printing, native dialogs and some more). My conclusion: this has always been broken for everything other then gen / X11 on Linux. There is nothing to bisect, as it simply never worked. From a users POV it's a regression coming from kde4, but technically it isn't.
So I re-checked this while testing https://gerrit.libreoffice.org/c/core/+/135082/. Quoting from the commit message: (134704) not fixed, because the sidebar window is now a dialog, which is not dockable. FWIW the same has happened to the Navigator (F5), which also renders it non-dockable. No idea, if this is an intentional change. It's, easy to see the difference for toolbars, which have an own title bar painted by LO and not the normal window title bar. Per default these are now fixed since a few LO releases. And AFAIK Wayland doesn't support docking at all. - Maybe this is intentional and can now be closed as WONTFIX? - Maybe UX has some additional general input?
(In reply to Jan-Marek Glogowski from comment #8) > Quoting from the commit message: > > (134704) not fixed, because the sidebar window is now a dialog, which is > not dockable. FWIW the same has happened to the Navigator (F5), which > also renders it non-dockable. No idea, if this is an intentional change. > > It's, easy to see the difference for toolbars... > > - Maybe this is intentional and can now be closed as WONTFIX? > - Maybe UX has some additional general input? The sidebar is typically docked and thus users expect redocking. Works via the context menu but the Navigator does not have it. Ideally we add a button to the dialog interactions. Btw. maximizing the (undocked) sidebar is pointless.
(In reply to Heiko Tietze from comment #9) > (In reply to Jan-Marek Glogowski from comment #8) > > Quoting from the commit message: > > > > (134704) not fixed, because the sidebar window is now a dialog, which is > > not dockable. FWIW the same has happened to the Navigator (F5), which > > also renders it non-dockable. No idea, if this is an intentional change. > > > > It's, easy to see the difference for toolbars... > > > > - Maybe this is intentional and can now be closed as WONTFIX? > > - Maybe UX has some additional general input? > > The sidebar is typically docked and thus users expect redocking. Works via > the context menu but the Navigator does not have it. Ideally we add a button > to the dialog interactions. Btw. maximizing the (undocked) sidebar is > pointless. Yup, I'm aware. But previously you could dock the Navigator with the mouse, just like toolbars. This is not possible anymore. You can not dock the Navigator and just re-dock the sidebar via the menu command. I don't know if it was possible to dock the sidebar on the left side, for example. Docking is a property of the Window type, and with both being dialogs, that is not possible anymore by moving them into docking areas with the mouse (where you see the rectangles showing up in the main window).
(In reply to Jan-Marek Glogowski from comment #10) > Docking is a property of the Window type Feel free to resolve WF. User expectation and UX statement is clear: redocking is expected. And I suggest to realize it per pull down menu as done for the sidebar.
Dear David, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Bug is still present in 24.2.4.