Description: On some spreadsheets the comment field is displayed with an offset that is row-dependant: the higher the row number, the greater the offset. Steps to Reproduce: 1. load the attached demo.ods (no macros there) 2. hover over an existing comment (comments are placed at D11, D66, D111, D165 and D211), 3. observe mismatch of arrowhead Actual Results: arrow points increasingly lower with higher row numbers Expected Results: arrow should point to correct cell Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.3.7.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 2; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Ubuntu package version: 1:7.3.7-0ubuntu0.22.04.1 Calc: threaded
Created attachment 184798 [details] Spreadsheet showing the problem This is a database of sorts for my personal ads. There is no personal data in there, and no macros. The comments are used for differentiating between price and discounts, most are lost in an earlier iteration to create the demo.
Seems something with rows height in the file. Select all [Ctrl+Shift+space] Right-click on any row number, select optimal height. The issue is gone.
Strange, I never changed the row height from the default value to begin with. This trick does not solve it for me (the issue persists): adding 0.11mm to the optimum height even reverses the offset so the arrow points to a cell above the one containing the comment. It just should not happen, no matter what row height is selected. Detail: if the comment is set to show permanently, the display is correct, it's just the popup that is wrong.
[Automated Action] NeedInfo-To-Unconfirmed
If I select all, and right-click on rows - optimal height - (default unmarked) - Add 0,11 cm. The arrows are well positioned for me. Also with 0,22 0,50 0,00 Version: 7.4.4.2 (x64) / LibreOffice Community Build ID: 85569322deea74ec9134968a29af2df5663baa21 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL I see there are formatted cells out of the range with data, some with the option 'wrap text assigned'. Could you test with a new blank file sample.
Strange: I don't recall setting that property on any cell... If I start a new spreadsheet, all is well. That is, until I save, close and reload: the comments are gone, all of them. Even stranger: I re-enter some comments, save, close and reopen again: some of the comments are gone. Third time seems to be a charm: all the newly entered the comments remained; though I'm not getting my hopes up too high... Two differences jump out to me: 1) I'm running Linux, you're running Windows 2) I'm running version 7.3.7.2, you're running 7.4.4.2; I have not seen an LO update offered by the synaptic package manager. I will refrain from using comments (that data is also stored elsewhere), it just seemed like a nice quick reference...
I can see the issue for attachment 184798 [details] with versions: Version: 7.2.7.2 / LibreOffice Community Build ID: 8d71d29d553c0f7dcbfa38fbfda25ee34cce99a2 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Version: 7.3.7.2 / LibreOffice Community Build ID: e114eadc50a9ff8d8c8a0567d6da8f454beeb84f CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Version: 7.4.4.2 / LibreOffice Community Build ID: 85569322deea74ec9134968a29af2df5663baa21 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 579d144290c1617fdb38d09b30900a6bbe390b8d CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Also on Windows: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ec2f1d73936c9d8cee83c0887170e9ecb8f044ba CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded But I can't reproduce in: Version: 7.1.8.1 / LibreOffice Community Build ID: e1f30c802c3269a1d052614453f260e49458c82c CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded I can't reproduce the issue with a new file, even if created with e.g. version 7.3. The distance changes depending on the zoom level. The issue sounds similar to bug 113901, which was fixed in version 6.1. Quite a few misplaced comments bugs in meta bug 101216, but I couldn't find an equivalent.
Bibisected with linux-64-7.2 repo to first bad commit 703af39b9e3de07867ca81b3333b9b9abdc6bbf5 which points to core commit: commit dca0374fb1edbd9bdeeaadda3f1866ce66b3a778 author Tor Lillqvist <tml@collabora.com> Fri Jan 29 16:03:29 2021 +0200 committer Tor Lillqvist <tml@collabora.com> Mon Feb 01 13:26:42 2021 +0100 tree 7e3ae407800a074547605703207c43257a494c84 parent f32b0e54c4993ebfba3e55ccc75a034736645fe2 Don't bother shrinking row height when changing just one row interactively I.e. when manually entering a new value. Change-Id: I3c77f7fb4e575f02e1dd7cdc18f2919f5eb3426e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110243 Tor, can you please have a look?