Bug 102730 - EDITING: Image in slide shifts when selected (see comment 6)
Summary: EDITING: Image in slide shifts when selected (see comment 6)
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Impress-Images
  Show dependency treegraph
 
Reported: 2016-09-28 00:51 UTC by David F Smith
Modified: 2021-03-31 13:58 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Example presentation with one slide that fails (for me) (190.05 KB, application/vnd.oasis.opendocument.presentation)
2016-09-28 00:51 UTC, David F Smith
Details
Screen shot of slide, with image shifted (167.73 KB, image/jpeg)
2016-09-28 00:51 UTC, David F Smith
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David F Smith 2016-09-28 00:51:05 UTC
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.
Comment 1 David F Smith 2016-09-28 00:51:50 UTC
Created attachment 127689 [details]
Screen shot of slide, with image shifted
Comment 2 Aron Budea 2016-10-02 03:32:17 UTC
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)
Comment 3 David F Smith 2016-10-02 03:48:20 UTC
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.
Comment 4 David F Smith 2016-10-02 03:50:30 UTC
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.
Comment 5 David F Smith 2016-10-03 01:12:22 UTC
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.
Comment 6 David F Smith 2016-10-03 01:36:04 UTC
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.
Comment 7 Buovjaga 2016-10-13 19:13:30 UTC
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)
Comment 8 Aron Budea 2017-01-04 07:07:37 UTC
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.
Comment 9 QA Administrators 2018-01-05 03:41:41 UTC Comment hidden (obsolete)
Comment 10 David F Smith 2018-01-06 01:32:55 UTC
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
Comment 11 QA Administrators 2019-01-07 03:41:47 UTC Comment hidden (obsolete)
Comment 12 David F Smith 2019-01-07 17:00:50 UTC
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
Comment 13 QA Administrators 2021-03-31 03:40:49 UTC Comment hidden (obsolete)
Comment 14 David F Smith 2021-03-31 13:58:20 UTC
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