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
Created attachment 193262 [details] Sample
Looks like a dup of https://bugs.documentfoundation.org/show_bug.cgi?id=147420 Please if you are not agreed reopen it. *** This bug has been marked as a duplicate of bug 147420 ***
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?
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.
Created attachment 193303 [details] Screencast (In reply to Regina Henschel from comment #4) Strange: Hiding the row of image B is already buggy in my case, without touching sort column Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b38974391e8d4bf0d450abfaa86bbccbe1022995 CPU threads: 8; OS: macOS 14.3; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
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.
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.
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.
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 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?
(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.
(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.