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.

Bug is still present in 24.2.4.