Bug 160329 - Image anchored to cell ends up in wrong cell after using autofilter sort, depending on hidden rows
Summary: Image anchored to cell ends up in wrong cell after using autofilter sort, dep...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.1.0.0.alpha1+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:24.8.0 target:24.2.4
Keywords: bibisected, bisected
Depends on:
Blocks: AutoFilter Cell-Management Sorting
  Show dependency treegraph
 
Reported: 2024-03-23 19:58 UTC by Telesto
Modified: 2024-05-03 22:45 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample (13.03 MB, application/vnd.oasis.opendocument.spreadsheet)
2024-03-23 19:59 UTC, Telesto
Details
Small Example (16.50 KB, application/vnd.oasis.opendocument.calc)
2024-03-25 22:09 UTC, Regina Henschel
Details
Screencast (4.94 MB, video/quicktime)
2024-03-25 22:30 UTC, Telesto
Details
Small Example all images anchored to cell (17.46 KB, application/vnd.oasis.opendocument.calc)
2024-03-25 23:40 UTC, Regina Henschel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2024-03-23 19:58:35 UTC
Description:
Image in wrong cell after using autofilter

Steps to Reproduce:
1. Open the attached file
2. Got to cell A495 (value 64). Notice C495 being empty (only purple)
3. Go to top of page, and use the Filter to sorting column A Ascending
4. Go to A66 (which contains value 64). Notice the image in C66)

Related to bug 160231

Actual Results:
Image in a different cell

Expected Results:
No change I think


Reproducible: Always


User Profile Reset: No

Additional Info:
Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 0020fc1167b3760d0631001689a44427b72b816e
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL threaded
Comment 1 Telesto 2024-03-23 19:59:18 UTC
Created attachment 193262 [details]
Sample
Comment 2 m_a_riosv 2024-03-24 10:20:23 UTC Comment hidden (obsolete)
Comment 3 Stéphane Guillou (stragu) 2024-03-25 13:36:17 UTC
History related to the bibisections in bug 152635 comment 5 and bug 147420 comment 13.
The issue is linked to the fact that row 66 is hidden.

- in 6.0, pictures don't move when sorting.

- linux-64-6.1, build [cc1980c9609c44386fdf6a1deb301fdbe4662a91], commit 3a2a430ae8e2c1647c18d8904477949f6e2e7941: images moved when sorting. Row 66 has no picture.

commit 3a2a430ae8e2c1647c18d8904477949f6e2e7941
author	Samuel Mehrbrodt 	Wed Dec 20 11:30:36 2017 +0100
committer	Eike Rathke 	Tue Jan 23 00:46:19 2018 +0100
tdf#98931 Consider cell-anchored images when sorting
Reviewed-on: https://gerrit.libreoffice.org/46838

- linux-64-7.1, build [25b3c957bfcb95a1da27a6021d1514495fd7df51], commit 1f0b3c7a40edfa81bbc7a58d123a6a2dfd83e4ca: picture in cell C66 after showing the row.
However, if row 66 is shown _before_ sorting, not reproduced.

commit 1f0b3c7a40edfa81bbc7a58d123a6a2dfd83e4ca
author	Regina Henschel 	Sat Oct 10 17:55:31 2020 +0200
committer	Regina Henschel 	Sat Oct 31 15:36:00 2020 +0100
Improve 'resize with cell' handling
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104643

- linux-64-7.2, build [71299fb394b3f27861f7a2729a5a597445dea26d], commit 8f4dda644d1ed08ef846b5d09ead365236c57952: row 66 is automatically shown on sort. C66 also has images, but they are different.

commit 8f4dda644d1ed08ef846b5d09ead365236c57952
author	Tünde Tóth 	Wed Feb 10 16:46:12 2021 +0100
committer	László Németh 	Mon Feb 15 15:11:47 2021 +0100
tdf#123202 calc: fix sorting of autofiltered rows
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110715

Same in:

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 53c5d570cab036b23f4969b858a648c8f0c24f93
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded

Let's keep separate from bug 147420.

Regina, can you please have a look?
Comment 4 Regina Henschel 2024-03-25 22:09:16 UTC
Created attachment 193301 [details]
Small Example

I can reproduce the problem with the smaller example of the attachment. It has images A B C D E so you can easily see to which row the image belongs.
Hide row of image B and then sort column A the opposite direction. The images have still the correct anchor cell after sorting, but the offset to the anchor is wrong. I have no idea about the reason.
Comment 5 Telesto 2024-03-25 22:30:02 UTC Comment hidden (obsolete)
Comment 6 Regina Henschel 2024-03-25 23:40:43 UTC
Created attachment 193306 [details]
Small Example all images anchored to cell

My fault. Image D in the example was anchored to page. The new upload should have it correct.
Comment 7 Regina Henschel 2024-04-15 13:51:44 UTC
The way (for sort rows) towards moving the objects to the new position is:
ScTable::Sort() -> ScTable::SortReorderByRaw() -> ScColumn::UpdateDrawObjects()
-> ScColumn::UpdateDrawObjectsForRow() -> ScDrawLayer::MoveObjects()
-> ScDrawLayer::RecalcPos()
The new cell address is given as parameter to ScDrawLayer::MoveObjects().

But there is a principle problem. The document itself has still the old configuration of hidden and non-hidden rows at the time RecalcPos() is used. Thus all places in RecalcPos() which examine whether a row is hidden or not use outdated values. And that results in the wrong position of the cell anchored images.
Comment 8 Commit Notification 2024-05-01 07:13:29 UTC
Regina Henschel committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f0a2969d15e3101d7f96a7fe77bca06a5d70f57a

tdf#160329 update objects after row sort is finished

It will be available in 24.8.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Commit Notification 2024-05-02 17:14:45 UTC
Regina Henschel committed a patch related to this issue.
It has been pushed to "libreoffice-24-2":

https://git.libreoffice.org/core/commit/1347274fc1cb780db4c7c9b8c0272e1730b95c04

tdf#160329 update objects after row sort is finished

It will be available in 24.2.4.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 10 Stéphane Guillou (stragu) 2024-05-03 12:40:47 UTC
Comment 0 steps look good now in:

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: e8fdc8a4ff60a392f51326e90212fc73d515e270
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded

Thanks Regina! Do you have more coming for this report or do you want to close it?
Comment 11 Stéphane Guillou (stragu) 2024-05-03 12:45:02 UTC
(In reply to Stéphane Guillou (stragu) from comment #10)
> Comment 0 steps look good now in:
> 
> Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
> Build ID: e8fdc8a4ff60a392f51326e90212fc73d515e270
> CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
> Locale: en-AU (en_AU.UTF-8); UI: en-US
> Calc: CL threaded
> 
> Thanks Regina! Do you have more coming for this report or do you want to
> close it?
...and I think that resolved bug 152635 as well.
Comment 12 Regina Henschel 2024-05-03 13:00:30 UTC
(In reply to Stéphane Guillou (stragu) from comment #10)
> Thanks Regina! Do you have more coming for this report or do you want to
> close it?

Nothing more. Any further problems should be reported in a new bug report.