Created attachment 127688 [details] Example presentation with one slide that fails (for me) (This appears to be a duplicate of Bug 92127, but it's very reproducible for me on Windows 10. I'll be interested to see if anyone else can confirm it.) The slide in the attached presentation illustrates a problem that I have encountered recently. When the slide is displayed in Normal view, I click on the photo to select it, and the image shifts, so that it is no longer aligned with the frame. The direction and distance of the shift seems to depend (more or less linearly) on where I click. A click near the upper left corner moves the image -.30" horizontal and -.40" vertical. Near the upper right corner gives .24" and -.40". Near the lower left gives -.30" and -.02", nearly a straight left shift. And near the lower right gives .24" and -.02". The shift is very obvious in this example slide, which has arrows pointing to two of the bird's features. When I click on the photo, the arrows are no longer in the right place. The attached jpg shows this. In every case, Ctrl+Z returns the photo to its original position, showing that Impress has detected the shift as an action (Move Bitmap) that can be undone. I created this presentation in this way. 1. Create a new presentation. Optionally, change the Layout to Blank Slide and change the Background Fill to solid black. 2. Insert an image. (In my case, I inserted a jpg photograph whose dimensions matched those of the presentation.) If necessary, expand the image to fill the frame. 3. Optionally, add other shapes on the slide. I added two arrows and two (invisible) boxes of text. 4. Save the presentation and close it. 5. Reopen the presentation. 6. Click somewhere in the image. It moves so that it is no longer aligned with the frame. 7. Press Ctrl+Z (or choose Edit > Undo) to return the image to its original position. 8. To try a click in a different place, be sure to undo the selection of the image first, by pressing Esc or clicking outside the black frame. Variation: addition clicks on the (unselected) image continue to move it additional amounts, and Ctrl+Z undoes each of those moves in reverse order.
Created attachment 127689 [details] Screen shot of slide, with image shifted
Not reproducible for me with 5.1.5.2 and 5.2.2.2 / Windows 7. Are there any screen-settings in your system that are not the default/usual? Or maybe some special mouse driver software? (I'm merely doing stabs in the dark here)
Screen settings or mouse driver? Nothing special that I know of. I upgraded from Win 7 to Win 10 in late July, a straight upgrade, and I haven't done any customization since then. This is the first Impress presentation I have made since that time, and I certainly would have noticed it before. So whether it's something about my old hardware or configuration, I have no idea.
I spent a long time trying to reproduce this myself, so that I could report a simple situation that failed. I finally discovered that saving and reopening the presentation was a necessary step.
Here's another couple of observations. I usually display the slides (Normal View) at the maximum size for the window, by clicking the four-headed arrow next to the Zoom Level slider. I'm looking at one now, in a maximized LO window, and the zoom is at 78%. When I click on the photo, so that it shifts its position, the zoom changes to 74%. When I unselect the photo by clicking somewhere else, the zoom changes back to 78%. So can I keep the shift from happening by starting at a smaller zoom? Nope. I set the zoom level at 65% and click on the photo. It shifts, but the zoom is unchanged. Then I unselect it, and the zoom is still 65%. What happens if the zoom is larger? I set it to 90%, so that I can't see the edges of my photo, and click. The photo shifts, but the zoom stays at 90%. I unselect it, and the zoom is still 90%. Why does the zoom change, if it's at "fit to window"? Here's a possibility. When I click the photo, the Picture toolbar appears above the slide frame, so there's less room for the slide. When I unselect, the Picture toolbar goes away. For what it's worth. This is still 100% reproducible for me.
Aha, I think I found something. I can make it work properly (no shift on selection of the image) by disabling the Picture toolbar. That toolbar (if selected) appears and disappears when a picture is selected and deselected, and on my copy it appears on a second toolbar line, below the Standard toolbar. It seems that that is what makes my picture shift. To be specific: 1. With the image not selected, choose View > Toolbars > Picture. The Picture toolbar appears above the slide frame. If necessary, move the Picture toolbar to a separate line, so that when it appears there are more lines of toolbars. 2. Select the image. No problem (no image shift), because the frame is already sized for the extra toolbar line. 3. Unselect the image. The Picture toolbar disappears, and the frame expands to recover the extra space. 4. Select the image again. The Picture toolbar appears, and the image shifts. 5. Choose View > Toolbars, and uncheck Picture. 6. Unselect the image. 7. Select the image again. The Picture toolbar does not appear, and the image does not shift. 8. Choose View > Toolbars, and check Picture. When the toolbar appears, drag it to the same line as the Standard toolbar, so that it does not take up any more vertical space. 9. Unselect and select the image. The Picture toolbar appears and disappears as before, but the image does not shift. If I'm right about the cause of this, and if it's reproducible by somebody else, then I would phrase my complaint in this way: if the slide frame needs to be resized because a new toolbar has appeared, the selected image and all other objects in the slide should stay together and aligned.
Repro, both with KDE and GTK3 backends. In 3.6, no funny business seems to be going on, so regression. Note: in 3.6, the toolbar is named "Picture" and not "Image". Arch Linux 64-bit, KDE Plasma 5 Version: 5.3.0.0.alpha0+ Build ID: 65f2d6b1cc40b4b90f8987e8ea14d24b5f38f950 CPU Threads: 8; OS Version: Linux 4.7; UI Render: default; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on October 10th 2016 Arch Linux 64-bit Version 3.6.7.2 (Build ID: e183d5b)
Reproducible with 3.3.0 / Windows 7 as well. Open presentation, make sure the image is not selected, enabled Picture/Image toolbar, position it below the other, and select the image with a "leisurely" click. When you press mouse button, the toolbar above Picture/Image disappears, toolbar and work area repositions/resizes, and when you release the mouse button, it's perceived as dragging the image, because it's in a different position in the resized work area.
** Please read this message in its entirety before responding ** 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This bug is still present. Symptoms are exactly the same as in my comment #6. Version: 5.3.7.2 (x64) Build ID: 6b8ed514a9f8b44d37a1b96673cbbdd077e24059 CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; Locale: en-US (en_US); Calc: group
This bug is still present. Symptoms are exactly the same as in my comment #6. Version: 6.0.5.2 (x64) Build ID: 54c8cbb85f300ac59db32fe8a675ff7683cd5a16 CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: en-US (en_US); Calc: group
Dear David F Smith, 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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
The bug seems to have been fixed. The procedure in my comment #6 now works without error. Thank you. Version: 7.0.5.2 (x64) Build ID: 64390860c6cd0aca4beafafcfd84613dd9dfb63a CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded