Problem description: Steps to reproduce: 1. create new presentation in Impress 2. insert an image 3. keep first image highlighted and then insert another image Current behavior: first image is replaced on slide with second image, and second image takes on size and shape of first even if second image is different size and shape Expected behavior: second image should be inserted onto slide without affecting existing images on the slide This is very frustrating and time wasting, as I have to keep undoing the insert image and reinsert it to keep both images on the slide. Operating System: Ubuntu Version: 4.1.4.2 release
the same happens with Writer and other components and is reproducible with any LibO releases and OOo too on Windows as well but I'm not sure it should be considered a bug.... if you wanna insert a second image you should remove the focus from the first otherwise the software will automatically insert the second image in the same position of the first replacing it. I udnerstand that it may be frustrating when it happens but I see it more as an accidental user error (you should change focus) rather than a bug. IMHO this should be labeled as NOTABUG but I wanno hear a second opinion from other QA members, so I set temporarily the status to NEW
I just tried it in LibreOffice 3 and it worked okay in 3, i.e. when inserting a second image, with first image selected on slide, the second image was placed onto middle of slide without overwriting/deleting first image.
you are right... my fault. if the second image is inserted by Ctrl+C you have image replacement. instead if you insert from "file" you have no replacement in LibO 3.3.3 while there's replacement in 4.1.4 so that's a bug and a regression.
(In reply to comment #0) > Problem description: > > Steps to reproduce: > 1. create new presentation in Impress > 2. insert an image > 3. keep first image highlighted and then insert another image > to reproduce the bug point 3 is fundamental to use the menu "insert/image/from file" and to keep the focus on first image (you should see the "green handles" around the image) in the meantime I tested with older LibO releases under Windows. no bug in 3.6.7. bug already present in 4.0.4 and still affecting 4.1.4 and 4.2.1dev probably the regression happened in 4.0.x development. please forget about my Comment 1 which was inaccurate. the current issue is about Impress... Writer has a different behaviour.
Results from bibisect-43all: d65a58c31c8da044ef66ae4517fa2fe74cec0019 is the first bad commit commit d65a58c31c8da044ef66ae4517fa2fe74cec0019 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Tue Dec 11 10:20:39 2012 +0000 source-hash-2e053cf5ea4d93a2e1845e795a9c7fe1e08c84af commit 2e053cf5ea4d93a2e1845e795a9c7fe1e08c84af Author: Takeshi Abe <tabe@fixedpoint.jp> AuthorDate: Wed Dec 5 08:33:07 2012 +0900 Commit: Takeshi Abe <tabe@fixedpoint.jp> CommitDate: Wed Dec 5 10:42:17 2012 +0900 sal_Bool to bool Change-Id: Ic1cc3312e61e602c33be7444f8d4bbad9268ae77 # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574 # good: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15 git bisect good 8f4aeaad2f65d656328a451154142bb82efa4327 # bad: [9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02] source-hash-8600bc24bbc9029e92bea6102bff2921bc10b33e git bisect bad 9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02 # good: [51b63dca7427db64929ae1885d7cf1cc7eb0ba28] source-hash-806d18ae7b8c241fe90e49d3d370306769c50a10 git bisect good 51b63dca7427db64929ae1885d7cf1cc7eb0ba28 # bad: [d65a58c31c8da044ef66ae4517fa2fe74cec0019] source-hash-2e053cf5ea4d93a2e1845e795a9c7fe1e08c84af git bisect bad d65a58c31c8da044ef66ae4517fa2fe74cec0019 # good: [79e02001f27d33b3b478324ab6fba5683413b4d9] source-hash-b6c016da23d309b4ac7d154bc33a22397974ed73 git bisect good 79e02001f27d33b3b478324ab6fba5683413b4d9 # good: [1e04c3b7ef40994ada3236fa8f90fbd1cdcea47e] source-hash-11e776023c89b3de690b37ffaed18ec996b9c207 git bisect good 1e04c3b7ef40994ada3236fa8f90fbd1cdcea47e # good: [c3482ad95176ec6762ef03e95d3287ebd5e84905] source-hash-3d4288c1c0b593421c7f6619c88584bdb7c53337 git bisect good c3482ad95176ec6762ef03e95d3287ebd5e84905 # good: [2e0fa432485d1db6abd355dad8ccb06f0b97e4fb] source-hash-ce90f99a2d66c2b998ad3f9f028e2ea623a757f5 git bisect good 2e0fa432485d1db6abd355dad8ccb06f0b97e4fb # first bad commit: [d65a58c31c8da044ef66ae4517fa2fe74cec0019] source-hash-2e053cf5ea4d93a2e1845e795a9c7fe1e08c84af
Looks pretty certain to be this commit: (not actually "bisected" but setting that keyword to mark that the commit has been identified) commit 869031d702639852cac51cdb8306ff31420b3f3f Author: Radek Doulik <rodo@novell.com> Date: Tue Dec 4 15:56:38 2012 +0100 changed behavior of insert picture - when single graphic object shape is selected, replace the graphic with inserted picture - otherwise proceed as before Change-Id: I767c3ab81abf26c34b612d6aac1f282aa0a53f6c
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fd6655080e181de4b78e31f13fe8ba35de8edfe5 tdf#73742 Don't replace existing image when inserting one It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7524dd59efc9b685548caf7967b24f7758796078&h=libreoffice-5-2 tdf#73742 Don't replace existing image when inserting one It will be available in 5.2.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Note: this changes behavior for Impress, but not for Writer or Calc.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "libreoffice-5-2-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6033d910aa7a6ac7f9ce477d59df6c4766128a59&h=libreoffice-5-2-0 tdf#73742 Don't replace existing image when inserting one It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Eike Rathke from comment #10) > Note: this changes behavior for Impress, but not for Writer or Calc. Long time ago, there was a discussion with Matthias Bauer on the behavior in Writer. It was decided that pasting in Writer (e.g. from a copied image in Draw) replaces a possible selected image. Thus keeping settings (position, size, ..) already done. :)