Description: 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!
Are the print screens deleted.. or stacked at the same place (multiple images on top of each other)
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?
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 OR 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.
I can confirm it with Version: 6.4.4.2 (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: 7.0.0.0.beta1 (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
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.
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 https://gerrit.libreoffice.org/plugins/gitiles/core/+/d0aa2dbdf37aefe5b8d096fc5ea50cd13f87c5b0%5E!/ 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.
Hi Xisco, have an idea why I can't see fixing commit? 6.4 is bad latest, 7.0 is good oldest.
(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 ?
(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?