Description: I have a text box for a caption positioned on top of a picture. I want to keep the caption but replace the picture. When right-clicking the picture and using the Replace... command on the context menu, the picture gets replaced, but winds up on top of any other elements that were previously on top of the picture. Steps to Reproduce: 1.Open Draw. 2.Place a picture. 3.Create a text box and position it on top of the picture so it overlaps. 4.Right-click the picture. 5.From the context menu, select Replace... 6.Replace the picture with another picture Actual Results: The new picture comes in on top of the other elements Expected Results: The new picture should be placed in the same alignment order as the original picture that it replaced. Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: It's tedious having to move the alignment order of the picture every time I replace it, and I replace pics often.
I was able to reproduce on: Version: 6.0.5.1 (x64) Build ID: 0588a1cb9a40c4a6a029e1d442a2b9767d612751 CPU threads: 4; OS: Windows 6.3; UI render: GL; Locale: en-US (en_US); Calc: CL and Version: 6.2.0.0.alpha0+ Build ID: b1740fba0d1e6e3d69c3781734509317f42a0e4f CPU threads: 4; OS: Windows 6.3; UI render: GL; TinderBox: Win-x86@42, Branch:master, Time: 2018-06-15_08:49:04 Locale: en-US (en_US); Calc: CL
Tested on Windows 8.1.
Regression introduced by: author Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> 2016-07-05 12:05:28 +0000 committer Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> 2016-07-05 19:58:48 +0000 commit fd6655080e181de4b78e31f13fe8ba35de8edfe5 (patch) tree b132314cd39e107b818f057cda33c07e6e9f2e47 parent 28a03248b1d1649e157b788e43dfe8326f165379 (diff) tdf#73742 Don't replace existing image when inserting one If we want to replace an image, we have an entry in the context menu for that. Bisected with: bibisect-linux-64-5.3 Adding Cc: to Samuel Mehrbrodt
(In reply to Xisco Faulí from comment #3) > Regression introduced by: > > author Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> 2016-07-05 12:05:28 +0000 > committer Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> 2016-07-05 19:58:48 > +0000 > commit fd6655080e181de4b78e31f13fe8ba35de8edfe5 (patch) > tree b132314cd39e107b818f057cda33c07e6e9f2e47 > parent 28a03248b1d1649e157b788e43dfe8326f165379 (diff) > tdf#73742 Don't replace existing image when inserting one > If we want to replace an image, we have an entry in the context menu for > that. > > Bisected with: bibisect-linux-64-5.3 > > Adding Cc: to Samuel Mehrbrodt I'm not entirely sure, but I suspect you're missing the point. It's not the act of replacing the image that's the problem. It's where the replacement image lands in terms of the top-down order of items on the document. Currently, once the image is replaced, it always occupies the top-most position in the hierarchy rather than honoring the placement of the position of the picture which it replaced. That is the bug.
Dear mwtjunkmail, 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
Bug does not happen in Version: 6.3.0.0.beta2 (x64)