Bug 126920 - LibreOffice Calc is oversensitive to pasting overlapping images
Summary: LibreOffice Calc is oversensitive to pasting overlapping images
Status: RESOLVED DUPLICATE of bug 107529
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.1.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2019-08-14 11:45 UTC by Chris Shaw
Modified: 2024-05-03 03:36 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
ODS showing the problem and repro steps (53.50 KB, application/vnd.oasis.opendocument.spreadsheet)
2021-05-26 09:27 UTC, Chris Shaw
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Shaw 2019-08-14 11:45:01 UTC
Description:
If an image is "Fit to cell size", an image pasted into cell below seems to be considered overlapping and both images do not appear

Steps to Reproduce:
1. Insert a square-ish image into A1
2. Set "Fit to Cell Size" so it fits the full height of the cell
3. Move to A2
4. Try to paste an image into A2

Actual Results:
The image in A1 vanishes, replaced by the text "Image 1..." written vertically in red

Expected Results:
The image in A1 should remain, and the new image appear in A2


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Seems to be specifically related to Pasting. I can "Insert->Image" into A2 without problem

The same thing happens if the image is wider than the cell, so takes the full width, and you attempt to paste into B1

The problem can be fixed if you Paste into A3, anchor to cell, then remove A2, so the end result is achievable
Comment 1 Durgapriyanka 2019-08-14 21:47:24 UTC
Thank you for reporting the bug. I can reproduce the bug in

Version: 6.3.0.0.alpha0+
Build ID: b6b28931435e44aca92b8c0e1659f701e3ed1a87
CPU threads: 2; OS: Windows 6.1; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-01-30_06:57:04
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded

But, not in
LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 2 IM 2019-08-20 22:46:02 UTC
Thank you for reporting the bug. I can confirm that the bug is present in:

Version: 6.4.0.0.alpha0+ (x86)
Build ID: 5c30c20101f72d973ff28c228f755e635cad14d5
CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; 
Locale: pl-PL (pl_PL); UI-Language: en-US
Calc: threaded

Version: 6.3.0.4 (x64)
Build ID: 057fc023c990d676a43019934386b85b21a9ee99
CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; 
Locale: pl-PL (pl_PL); UI-Language: en-US
Calc: threaded
Comment 3 Chris Shaw 2019-11-07 17:24:45 UTC Comment hidden (obsolete)
Comment 4 Chris Shaw 2019-11-07 18:18:37 UTC Comment hidden (obsolete)
Comment 5 Chris Shaw 2021-05-14 12:28:42 UTC Comment hidden (obsolete)
Comment 6 Timur 2021-05-26 08:55:47 UTC Comment hidden (obsolete)
Comment 7 Chris Shaw 2021-05-26 09:27:36 UTC
Created attachment 172349 [details]
ODS showing the problem and repro steps
Comment 8 Chris Shaw 2021-05-26 09:30:30 UTC
(In reply to Timur from comment #6)
> I don't reproduce with 7.1. 
> There must be some details, please attach sample with steps 1-2 and inserted
> image on other cell which can be copied to A2 to reproduce.

I've narrowed down the repro steps and attached a sheet showing the problem

If you do a normal Paste of an image copies from LO, the type defaults to SVXB, which works OK (although the anchor is in the wrong place)

If you do a Paste Special as PNG or BMP, the problem occurs. This is the default way of pasting from an external program, which is how it came up in the first place
Comment 9 Timur 2021-05-26 13:44:46 UTC
LO 4.2 had a paste as Bitmap and it was fine, paste where intended.

Somewhere in LO 4.3 there was 1st change, paste to B2 as Bitmap or PNG would paste to B1. I couldn't bibisect in Linux.

In 6.1 repo there was 2nd change, paste to B2 started behaving as reported ("Image 1..." in B1). Here is the commit (only found in bug 117576).

commit 8481c07a624f6b49ff535cb2d4adbc8243b279a3
Date:   Tue Apr 10 08:58:56 2018 +0200
    source e4eb416c3ef81d098ed61caabd2077cbbb2418bc
    previous ea3d755ac949c1b6dada5c341e018f8c23f5d395

author	Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>	2018-04-01 14:47:13 +0900
committer	Tomaž Vajngerl <quikee@gmail.com>	2018-04-10 08:34:13 +0200
commit e4eb416c3ef81d098ed61caabd2077cbbb2418bc (patch)
tree 5aa13b196431f02a1b4fc0d1049f7ba2eb0ba74c
parent ea3d755ac949c1b6dada5c341e018f8c23f5d395 (diff)
remove swapping and link from GraphicObject and Graphic
Comment 10 Timur 2021-05-26 13:51:43 UTC Comment hidden (obsolete)
Comment 11 QA Administrators 2023-07-18 03:15:19 UTC Comment hidden (obsolete)
Comment 12 Stéphane Guillou (stragu) 2024-05-03 03:36:32 UTC
(In reply to Timur from comment #9)
> In 6.1 repo there was 2nd change, paste to B2 started behaving as reported
> ("Image 1..." in B1). Here is the commit (only found in bug 117576).
> 
> commit 8481c07a624f6b49ff535cb2d4adbc8243b279a3
> author	Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>	2018-04-01 14:47:13
> +0900
> commit e4eb416c3ef81d098ed61caabd2077cbbb2418bc (patch)
> remove swapping and link from GraphicObject and Graphic
I see the issue starting at 5.0. After a second paste, one needs to zoom in/out to refresh the view and see the empty frame.
I checked with the commit you bibisected to: empty frame directly at second paste at e4eb416c, but same thing after a zoom in/out refresh at e4eb416c~1, so Quikee only made something pre-existing more visible.

Marking as duplicate of bug 107529.

*** This bug has been marked as a duplicate of bug 107529 ***