Bug 92122 - UI: Floating panels cannot be docked, if "Show window contents while dragging" is disabled in Windows visual effects
Summary: UI: Floating panels cannot be docked, if "Show window contents while dragging...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All Windows (All)
: low minor
Assignee: Not Assigned
: 90176 104299 107478 (view as bug list)
Depends on:
Blocks: Desktop-Integration Panel-Docking
  Show dependency treegraph
Reported: 2015-06-16 18:58 UTC by Jérôme
Modified: 2022-07-11 03:29 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:
Regression By:

the slides overview window which can't be docked is rounded in red (42.21 KB, image/png)
2015-06-16 18:58 UTC, Jérôme
the Windows XP setting for performance (10.97 KB, image/png)
2015-06-16 19:03 UTC, Jérôme

Note You need to log in before you can comment on or make changes to this bug.
Description Jérôme 2015-06-16 18:58:48 UTC
Created attachment 116591 [details]
the slides overview window which can't be docked is rounded in red

Microsoft Windows XP

LO Build ID: 40ff705089295be5be0aae9b15123f687c05b0a

When the Microsoft XP performance setting that shows the window content during the move is deactivated, then I can't dock a flying slides viewer which was previously undocked.

This occurs with the normal view of Impress.
Comment 1 Jérôme 2015-06-16 19:03:16 UTC
Created attachment 116592 [details]
the Windows XP setting for performance

The setting which makes this bug appear is rounded in blue.
Comment 2 Adolfo Jayme Barrientos 2015-06-16 22:53:04 UTC
(Please note that version – as you’ve indicated in the Version field — is no longer supported by The Document Foundation. Do not report bugs against unsupported versions. Please upgrade to the most recent stable version, 4.4.4, and try again.)
Comment 3 Buovjaga 2015-06-17 09:15:11 UTC Comment hidden (obsolete)
Comment 4 QA Administrators 2015-12-27 20:31:13 UTC Comment hidden (obsolete)
Comment 5 Jérôme 2016-01-27 21:08:19 UTC
This bug is still present with :
- version
- buildid 8a35821d8636a03b8bf4e15b48f59794652c68ba
- OS Microsoft Windows XP
Comment 6 Buovjaga 2016-01-28 08:28:44 UTC Comment hidden (obsolete)
Comment 7 Jérôme 2016-01-28 20:10:05 UTC
I'm able to test the bug with Windows XP only on the computer of my office and I can't install an other version ( is the version which has been validated for my organisation). At home I have only Linux boxes.
Comment 8 tommy27 2017-01-09 17:06:28 UTC
any news about this bug status with recent LibO releases?
Comment 9 Jérôme 2017-01-11 21:11:24 UTC
This bug still occurs with :
- M. Windows 7 service pack 1 64 bits (x86_64)
- LibreOffice 32 bits (x86)
Comment 10 tommy27 2017-01-12 06:25:13 UTC
thanks for retesting but you should do it with latest LibO release ( 
the release you used is obsolete.
Comment 11 Jérôme 2017-01-12 20:24:52 UTC
My work will always use an older release since it is more tested. Maybe in a few months I will get a new version at my office but I assume the 5.2 version will be outdated then.

Can someone else test it on a Windows 7 box ?
Comment 12 Buovjaga 2017-01-13 12:14:19 UTC
I confirm this on Win 10.

This PC - Properties - Advanced system settings - Performance settings - Visual effects: Show window contents while dragging

I cannot dock the slide pane, if the setting is disabled.

Version: (x64)
Build ID: 3d5603e1122f0f102b62521720ab13a38a4e0eb0
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
Locale: fi-FI (fi_FI); Calc: group
Comment 13 Maxim Monastirsky 2017-12-04 21:56:44 UTC
*** Bug 107478 has been marked as a duplicate of this bug. ***
Comment 14 Maxim Monastirsky 2017-12-13 13:30:13 UTC
Had no chance to play with a Windows build yet, but I think the problem here is that we try to detect whether a floating window is above the docking area when we get notified that the window was moved (in Win32 via a WM_MOVE message). But if "Show window contents while dragging" option is disabled, the window isn't actually moved during dragging (only a fake outline is shown), so no "window moved" notification is sent until the user releases the mouse, which is too late. There is however another "window is moving" message (WM_MOVING), which works regardless of the OS dragging setting, so it might be possible to somehow use that for docking instead of WM_MOVE. Another approach might be to stop using system window titles for floating panels, and use our own drawn titles like the gray title bar we draw for floating toolbars. That probably will give us more control over the dragging process.
Comment 15 QA Administrators 2018-12-14 03:56:17 UTC Comment hidden (obsolete)
Comment 16 Jérôme 2018-12-15 15:05:03 UTC
I have no access to a Windows 7/8/10 OS with a version more recent than 5.2.
Comment 17 V Stuart Foote 2019-11-02 13:45:22 UTC
This issue is remains with Windows 10 Home 64-bit en-US with Intel Graphics 620 and current master/6.4.0alpha1+
Version: (x64)
Build ID: 80109586e6cb6d3e2e0a53a9079c3125ec9b8368
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded


Version: (x64)
Build ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded

With 'Show windows contents while dragging' not checked enabled, the docking target does not appear.
Comment 18 V Stuart Foote 2019-11-02 13:46:58 UTC
*** Bug 90176 has been marked as a duplicate of this bug. ***
Comment 19 V Stuart Foote 2019-11-02 13:47:19 UTC
*** Bug 104299 has been marked as a duplicate of this bug. ***
Comment 20 V Stuart Foote 2019-11-02 14:04:02 UTC
So this remains an issue on Windows. Is there a comparable DE control with similar affect on Linux DEs (bug 104299 and see also bug 64438 suggest so)?  

And, possibly also affecting macOS (see also bug 128543).
Comment 21 QA Administrators 2022-07-11 03:29:49 UTC
Dear Jérôme,

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