Description: When two images are located at the same place in a slide, selecting and removing (or cutting) the top image deletes the current slide. This should not happen. Only the selected image should be deleted, not the whole slide. Steps to Reproduce: 1) Open the attached test.odp 2) In slide 1, select the image (world), then press Ctrl-C => image is copied to the clipboard 3) Go to slide 2 and press Ctrl-V => slide 1 image (world) is pasted over slide 2 image (person) 4) Still on slide 2, select top image (world) without moving it and press Ctrl-X => image (world) should be cut to clipboard. Actual Results: The whole slide is cut to clipboard. Same issue happens if pressing Del instead of Ctrl-X, after having selected the top image. Expected Results: The correct behaviour would be to cut (or delete) only the selected image, not the entire slide. Note that if one moves the top image by one pixel before pressing Ctrl-X, then the issue does not appear. Also, I found that the issue happens with either png or svg images. Reproducible: Always User Profile Reset: Yes Additional Info: System: Ubuntu 24.04.1 LTS LibreOffice: Version: 24.8.4.2 (X86_64) / LibreOffice Community Build ID: 480(Build:2) CPU threads: 8; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Ubuntu package version: 4:24.8.4~rc2-0ubuntu0.24.04.1~lo1 Calc: threaded
Created attachment 198502 [details] Impress test document
I can't reproduce Version: 24.8.4.2 (X86_64) / LibreOffice Community Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
No repro Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 540d6349ac675e98c73166392cabbfcca8a6fc5b CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: he-IL (cs_CZ.UTF-8); UI: en-US Calc: threaded
Strange you can't reproduce. I reproduced the issue again on different versions and systems (in VMs, fresh profile for LibreOffice) : Windows 10 22H2 Version: 24.2.6.2 (X86_64) / LibreOffice Community Build ID: ef66aa7e36a1bb8e65bfbc63aba53045a14d0871 CPU threads: 2; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: threaded Ubuntu 22.04.5 LTS Version: 7.3.7.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 2; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Ubuntu package version: 1:7.3.7-0ubuntu0.22.04.7 Calc: threaded I give again precise instructions to reproduce: 1. Open test.odp 2. Select image in slide 1 with a mouse click on it, then press Ctrl-C 3. Click on slide 2 on the sidebar, then press Ctrl-V 4. Press Ctrl-X or Delete After step 4, we see in the sidebar that Slide 2 was removed.
Reproducible Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e146f49704ef535c9ddd74338783e7c38390bf59 CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (es_ES); UI: en-US Calc: CL threaded But only if after step 3, Ctrl+X is done without deselecting the pasted object.
>> Reproducible >> But only if after step 3, Ctrl+X is done without deselecting the pasted object. Yes, the pas ted object must be selected. Same with Delete key instead of Ctrl-X. These kind of manipulations are used internally by the TexMaths extension, when editing equations.
Reproducible Version: 24.8.3.2 (AARCH64) / LibreOffice Community Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92 CPU threads: 8; OS: macOS 15.1.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en_NL.UTF-8); UI: en-US Calc: CL threaded Also after step 3, Ctrl+X is done without deselecting the pasted object.
Created attachment 200096 [details] Direct-delete of a pasted image, deletes slide-of-destination (red on movie) Reproduced in LO dev 28.03.2025: Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a22f83249699b41317f2d6923878c369e0344598 CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: pl-PL (pl_PL); UI: en-US Calc: CL threaded Also, it does not matter what would be position or size of image. In those cases bug is also reproducible.
I tested it and I think the position and size became a red herring. It seems like it all depends on how the "Go to slide 2" part of step 3 is done and who has the active focus. In the Roland's original steps, the focus is kept on the Slides pane at the left. SCENARIO 1, THE OP's: If you go to slide 2 by 1) clicking the second slide on the left Slides bar and 2) immediately pasting the World icon, the status is as follows: - left pane has slide 2 selected - center pane has World selected - active focus is on the left pane Cutting or Deleting applies to the selected object with the active focus: the second slide on the left pane. SCENARIO 2, SLIGHTLY DIFFERENT: If, instead, you "go to slide 2" by 1) clicking on the second slide on the left Slides bar, 2) clicking anywhere on the blank side of the slide itself at the center pane without moving or deselecting anything and 3) pasting the World icon, the status is as follows: - left pane has slide 2 selected - center pane has World selected - active focus is on the center pane *** (notice this difference) Cutting or Deleting applies to the selected object with the active focus: the World icon on the center pane. The active focus switches to the center pane when the slide on the center pane is clicked. Roland Baudin said in the initial description: > Note that if one moves the top image by one pixel before pressing Ctrl-X, then the issue does not appear. Yes, because "moving by one pixel" is typically done by mouse and this will require a click on the center pane, and this will switch the focus to the center pane. Thus, Cut or Del will now apply to the World icon. ADDITIONAL COMMENTS FROM ME: I tried pressing the "up" key after pasting the World icon. In scenario 1, the selection moves from the second to the first slide on the Slides pane at the left. In scenario 2, pressing the "up" key will move the World icon upwards a little. I am running LibO under GTK4. The active focus highlight on the Slides pane is noticeable if just by a little border. It's not *that* obvious. I noticed the provided recording by Roland does not show what happens if he clicks on the slide and switch the focus to the center pane, to see how LibO highlights the slides on his system when the left pane does not have the active focus. At first, it didn't reproduce, and then after watching the video it did! And I didn't know why, hah! So I may have selected the center pane out of habit or something happened and I clicked on the center pane, and that may be why it didn't reproduce for some others. So, the real questions are: 1) Should the focus should switch to the center pane upon pasting? 2) Should the highlight be made more noticeable under a default configuration? I don't think it will make any difference, as we will "shortcut" it and think that it is slide 2 which is highlighted, not that the slides pane still has the focus. 3) Was the behavior different in previous versions? Maybe the UX team can help. I can't tell for sure if this is a bug or not. I'm inclined for "not a bug". The current behavior allows to paste the same image into multiple slides quickly by: 1. In slide 1, Copy the icon. 2. Click slide 2 on the left. 3. Paste 4. Down key 5. Paste 6. Down key 7. Paste 8. Down key... ... and so on. If the focus were to be switched to the center pane on pasting, this would be made much more difficult.
(In reply to Octavio Alvarez from comment #9) > ...So I may have selected the center pane out of habit > or something happened and I clicked on the center pane, and that may be why > it didn't reproduce for some others. Yes, on the movie (attachment 200096 [details]) between 0:11 and 0:17 second, there was no click on the center pane. I moved the mouse to the center out of habit.
Paste seems to put focus on this object by marking the edges. But obviously the focus is still on the item in the slide pane where cut or delete has unexpected results. SdrExchangeView::Paste() calls MarkObj() which probably needs to invalidate the actual selection. Noel, Tomaz: please take a look.