Bug 133380 - Pasting image overlapping image bellow cursor
Summary: Pasting image overlapping image bellow cursor
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
Depends on:
Reported: 2020-05-25 17:00 UTC by Radsan
Modified: 2020-06-10 08:22 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Document for replicating Bug 1 (839.95 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-05-29 15:37 UTC, Duma Zina-Sabrina

Note You need to log in before you can comment on or make changes to this bug.
Description Radsan 2020-05-25 17:00:23 UTC
I opened my MS Word 2016 file with Writer to edit. I had applied a print screen of the information on my browser(as I've always done in the past and then pasted it using Word at that time), and then pasted it into that file in between other print screen images that I had pasted in the past.  When I paste the new print screen image, it deletes one of the current images even though I had given plenty of space between the other images.  It is also strange that at times it will also paste between other images further down the document instead of where I originally pasted it. It appears though when I hit Undo, then Redo, the deleted image sometimes shows up correctly.  I'm curious if that would have happened if I would have first saved the file as an ODF file instead of Word before editing.

Steps to Reproduce:
1.Closed program
2.Opened program
3.Tried pasting again

Actual Results:
Pasting image still resulted in deleting different image below.

Expected Results:
Software should have pasted image in the exact area that was intended, and it should not have deleted anything.

Reproducible: Always

User Profile Reset: No

Additional Info:
Not sure how I can copy the information from that window, it doesn't allow it.  Unfortunately, I cannot paste an image of it here as an alternative option.

Thank you for creating a terrific alternative to MS Office, I was getting tired of paying for their premium prices!  Keep up the good work, it's much appreciated!
Comment 1 Telesto 2020-05-25 18:19:50 UTC
Are the print screens deleted.. or stacked at the same place (multiple images on top of each other)
Comment 2 Dieter 2020-05-27 08:09:57 UTC
Radsan, i think, it will be very difficult to reproduce the bug, without a sample document. Is it at least possible to add a screencast?
Comment 3 Duma Zina-Sabrina 2020-05-29 15:37:53 UTC
Created attachment 161395 [details]
Document for replicating Bug 1

I was able to reproduce the issue with the following steps:

1.Create a Word document having multiple images 
1.Use the file attached.
2.Open the file in LO.
3.Copy any image from an external source or press PrtScr.
4.Place your cursor and click between any two images. E.g. between the 1st and the 2nd image.
5.Press Paste (Ctrl+V). You should see the pasted image overlapping the immediately following image.
6.Press Undo (Ctrl+Z). Now you should see the initial document.
7.Press Redo (Ctrl+Y). Now you should see all three images: the initial two and the pasted one between them, with the 2nd one not overlapping the third.

Actual Result: The pasted image overlapped the next image in the document. As print screens are of the same dimension, it might look like the one that is being overlapped disappears. 
After pressing Undo and then Redo, the pasted image no longer overlapped the following one – they all display one after another.

Expected Result: As in MS Office, the pasted image is expected to be displayed between the existing images, with the next one pushed down if necessarily.
Comment 4 Dieter 2020-06-04 07:06:24 UTC
I can confirm it with

Version: (x64)
Build-ID: 3d775be2011f3886db32dfd395a6a6d1ca2630ff
CPU-Threads: 4; BS: Windows 10.0 Build 18363; UI-Render: GL; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: threaded

but not with

Version: (x64)
Build ID: 94f789cbb33335b4a511c319542c7bdc31ff3b3c
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL

So the problem might has been solved in LO 7.0.

Could you please try to reproduce it with LO 7.0 from https://www.libreoffice.org/download/download/?type=win-x86_64&version=7.0.0 ? You can install it alongside the standard version. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
Comment 5 Timur 2020-06-04 15:10:04 UTC
No repro 6.3, repro 6.4 so regression, no repro master 7.0+ so fixed. 
I think it's safe to close.
Reverse bibisect, or two, would be nice, to know exactly where this changed.
Comment 6 Timur 2020-06-08 09:43:14 UTC
Went wrong with: 
 d250ca91c79f457102daf4da81446b7f130fb0ee is the first bad commit
commit d250ca91c79f457102daf4da81446b7f130fb0ee
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Fri Dec 6 01:56:32 2019 +0100

    source d0aa2dbdf37aefe5b8d096fc5ea50cd13f87c5b0
Previous source f96f290c1988d7bfbe439470281d946d6f5add65


commit d0aa2dbdf37aefe5b8d096fc5ea50cd13f87c5b0	[log]
author	Miklos Vajna <vmiklos@collabora.com>	Mon Nov 18 13:50:32 2019 +0100
committer	Miklos Vajna <vmiklos@collabora.com>	Thu Dec 05 14:18:29 2019 +0100
tree a3d8618fc8c1c1944b58bb2f6a934e9e553514e4
parent f96f290c1988d7bfbe439470281d946d6f5add65 [diff]

sw: insert image: set anchor to at-char by default

This changes the default set in commit 4f40bf6a79de6d60da0a5090cdfeda6242e889f0 (sw: insert image: set anchor
to as-char by default, 2019-07-04), to have a better compromise, taking
both Word defaults compatibility and usability into account.
Comment 7 Timur 2020-06-08 09:50:02 UTC Comment hidden (obsolete)
Comment 8 Xisco Faulí 2020-06-08 09:51:32 UTC Comment hidden (obsolete)
Comment 9 Timur 2020-06-08 14:52:09 UTC
(In reply to Xisco Faulí from comment #8)
> (In reply to Timur from comment #7)
> > Hi Xisco, have an idea why I can't see fixing commit? 
> > 6.4 is bad latest, 7.0 is good oldest.
> Does removing the profile folder on every step help ?

I'm not talking about bibisect, but about git checkout. 
If latest 6.4 is bad and oldest 7.0 is good, where is commit?