Description: 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:
Created attachment 154369 [details] test presentation Try displacing the text box.
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.
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 https://www.libreoffice.org/download/libreoffice-fresh/ ? 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.
Hi, yes, I do see the bug in the current version of LO (Version: 6.3.1.2), 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.
[Automated Action] NeedInfo-To-Unconfirmed
Created attachment 154742 [details] Another example of presentation in order to reproduce the issue
Created attachment 154743 [details] screenshot showing the reported behaviour
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: Version: 6.3.1.2 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
Not reproduced in Version: 6.4.0.0.alpha0+ 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: 6.3.1.2 (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 Versión: 4.4.0.3 Id. de compilación: de093506bcdc5fafd9023ee680b8c60e3e0645d7 Configuración regional: es_ES
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?
It could be even less than two seconds, actually
I'm not seeing this on Win with 6.4.4. Could everyone re-test?
I can confirm with Version: 7.1.0.0.alpha0+ (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
Dear mirko.pieropan, 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