Download it now!
Bug 127699 - trail left by objects while dragging them with arrow keys in LibreOffice Impress
Summary: trail left by objects while dragging them with arrow keys in LibreOffice Impress
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
(earliest affected) release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
Keywords: bibisectRequest, regression
Depends on:
Reported: 2019-09-22 15:02 UTC by mirko.pieropan
Modified: 2020-09-17 19:33 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

test presentation (531.91 KB, application/vnd.oasis.opendocument.presentation)
2019-09-22 15:21 UTC, mirko.pieropan
Another example of presentation in order to reproduce the issue (1.46 MB, application/vnd.oasis.opendocument.presentation)
2019-10-03 20:58 UTC, mirko.pieropan
screenshot showing the reported behaviour (1.71 MB, image/png)
2019-10-03 21:00 UTC, mirko.pieropan

Note You need to log in before you can comment on or make changes to this bug.
Description mirko.pieropan 2019-09-22 15:02:26 UTC
When selecteing an object and displacing it using the arrow keys a trail left by the boundary the object is visible until one stops moving the object. The issue first appears in version. In previous versions there is no trail, but the content appears to be delayed with respect to the frame enclosing it, giving rise to a weird "bouncing" effect.

Steps to Reproduce:
1. Insert a text box or picture
2. Select it
3. Press any arrow key on your keyboard to move it

Actual Results:
The object leaves a trail of its displacement while keeping an arrow key pressed to move it. The tracks disappears when the arrow key is released.

Expected Results:
Only the actual position of the object should be visible at any given time.

Reproducible: Always

User Profile Reset: No

Additional Info:
Comment 1 mirko.pieropan 2019-09-22 15:21:12 UTC
Created attachment 154369 [details]
test presentation

Try displacing the text box.
Comment 2 mirko.pieropan 2019-09-22 15:27:58 UTC
I think the issue could be related to (or worsened by) the presence of a background image. The behaviour looks ok if one uses the default white background.
Comment 3 Xisco Faulí 2019-09-23 11:37:49 UTC
Thank you for reporting the bug.
it seems you're using an old version of LibreOffice.
Could you please try to reproduce it with the latest version of LibreOffice
from ?
I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the bug is still present in the latest version.
Comment 4 mirko.pieropan 2019-09-23 12:29:53 UTC
Hi, yes, I do see the bug in the current version of LO (Version:, although you're right that the example I provided seems to work fine with the most recent version. However, I'd prefer not to share the presentation in which I see the bug, as it is for internal use only. I'll see if I can provide another example to allow you to reproduce the issue. I won't change the status until I manage to do so.
Comment 5 QA Administrators 2019-09-24 03:10:59 UTC Comment hidden (obsolete)
Comment 6 mirko.pieropan 2019-10-03 20:58:35 UTC
Created attachment 154742 [details]
Another example of presentation in order to reproduce the issue
Comment 7 mirko.pieropan 2019-10-03 21:00:20 UTC
Created attachment 154743 [details]
screenshot showing the reported behaviour
Comment 8 mirko.pieropan 2019-10-03 21:02:38 UTC
Hello, added another example. 
Try keeping an arrow key pressed in order to move the title.

Again, here are the details about the LO version I'm using:

Build ID: b79626edf0065ac373bd1df5c28bd630b4424273
CPU threads: 4; OS: Mac OS X 10.13.6; UI render: default; VCL: osx; 
Locale: it-IT (it_IT.UTF-8); UI-Language: en-US
Calc: threaded
Comment 9 Xisco Faulí 2019-10-04 13:57:28 UTC
Not reproduced in

Build ID: c9336bfb6bbf6d73d3f23c124262ade30133448d
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded

but I do in

Versión: (x86)
Id. de compilación: b79626edf0065ac373bd1df5c28bd630b4424273
Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; VCL: win; 
Configuración regional: es-ES (es_ES); Idioma de IU: es-ES
Calc: threaded

not reproduced in

Id. de compilación: de093506bcdc5fafd9023ee680b8c60e3e0645d7
Configuración regional: es_ES
Comment 10 mirko.pieropan 2019-10-06 12:49:32 UTC
Another thing I was thinking about:
I find that the displacement step is still too large when moving objects in Impress (imagine the situation where you want to align two objects next to each other).
Changing the values in the Position and Size menu drives me crazy and takes quite a bit of time. Is that something that can be easily improved?
Also, it would be nice if keeping an arrow key pressed led to the following behaviour: for the first 2 seconds the step stays constant and is small enough to allow accurate displacements; after two seconds the step increases proportionally with time at some rate until a (reasonable) maximum value is reached. When the latter is reached, the displacement step stays constant until the arrow key is released.
How about that?
Comment 11 mirko.pieropan 2019-10-06 13:06:10 UTC
It could be even less than two seconds, actually
Comment 12 Buovjaga 2020-06-07 18:06:29 UTC
I'm not seeing this on Win with 6.4.4. Could everyone re-test?
Comment 13 raal 2020-09-17 19:33:26 UTC
I can confirm with Version: (x64)
Build ID: bcf1917a0934417226d2357b514df398129a7fab
CPU threads: 4; OS: Windows 10.0 Build 17763; UI render: default; VCL: win
Tried to bibisect, but I can not reproduce it with 7.0-master, but I can reproduce the bug with 7.1-oldest