Created attachment 80018 [details]
Test case

Test case.

1) Open attached document
2) Note that the cloud image is anchored to cell B2, and placed in such a way that the top of the cloud is about half-way in row 2.
3) Now, select row 1 and insert a row before row 1. This works: the cloud correctly moves down, since it remains still relative to its anchor point (now cell B3). Now the top of the cloud is about half-way in row 3.
4) Put your cursor in cell A2 at the end of the world "Foo", press CTRL-ENTER to insert a line break and type "Bar". Note that this is not handled properly. The height of cell A2 is increased in order to accomodate the two lines of text. This means that cell B3, to which the cloud image is anchored moves down. However, the cloud image does not move down, so that its relative position with respect to the anchor point is changed. The top of the cloud should have remained about half-way in row 3, but now it is at the bottom of row 2.

In the future please read the instructions in their entirety:

"Marking as NEEDINFO - once you attach document and explain steps mark as UNCONFIRMED and we will verify the problem."

In general QA doesn't look at NEEDINFO bugs at all as we assume the reporter needs to add details, the bug must be in UNCONFIRMED status to get triaged

I can confirm same behavior as comment 2 on LO 4.0.4.1 (Win7 32bit)

Bug still present in 5.3.0.3.

I created Bug 106336 for the same behavior especially for columns before I found this bug. I didn't notice that the image positioning problem (if anchored to cell) not only exists with columns but also with rows.

But this bug is cluttered with meaningless comments, the other bug has a too special summary (up to now). A LibO bugzilla expert should decide what to do.

Issue is still present as of 5.3.1 RC 1

I do not see the problem in Version: 5.4.3.2 (x64)
Build ID: 92a7159f7e4af62137622921e809f8546db437e5
CPU threads: 8; OS: Windows 6.19; UI render: GL; 
Locale: de-DE (de_DE); Calc: CL

The special case described in commend 2 really seems to be fixed.

But copying a column or row with a defined height and inserting it before the column or row with an image, this image isn't correctly repositioned. See also bug 106336.

Version: 6.1.0.0.alpha0+
Build-ID: 38f5e768b0f858f8f990a8f297396821c75d45dc
CPU-Threads: 4; BS: Linux 4.10; UI-Render: Standard; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-12-29_01:09:09
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group threaded

Improved, but still a bit buggy in LibO 6.2.0 RC 1.

Test case to have an issue needs to be slightly changed to still show the buggy behaviour

Test case (again with attachment 80018 [details])

1) Open attached document

2) Note that the cloud image is anchored to cell B2, and placed in such a way that the top of the cloud is about half-way in row 2.

3) Now, select row 1 and insert a row before row 1. This works: the cloud correctly moves down, since it remains still relative to its anchor point (now cell B3). Now the top of the cloud is about half-way in row 3.

4) Put your cursor in cell A2 at the end of the world "Foo", press CTRL-ENTER to insert a line break and type "Bar". This is broken in LibO < 6.2 and working (sort of) in LibO 6.2. In LibO 6.2 the cloud correctly moves down, since it remains (almost) still relative to its anchor point (now cell B3). Now the top of the cloud is about half-way in row 3. Actually, the behavior is still buggy, because there must be some miscalculation and the image moves /slightly/ up relative to its anchor point.

5) Put your cursor in cell A2 at the end of the world "Bar" and press CTRL-ENTER 10 times. This adds 10 empty lines to cell A2 and makes evident the miscalculation reported at the previous point 4). Now the top of the cloud is not anymore half-way in row 3.



 Note that this is not handled properly. The height of cell A2 is increased in order to accomodate the two lines of text. This means that cell B3, to which the cloud image is anchored moves down. However, the cloud image does not move down, so that its relative position with respect to the anchor point is changed. The top of the cloud should have remained about half-way in row 3, but now it is at the bottom of row 2.

Sorry for the editing mistake in the previous comment, please ignore the last 6 lines.

I don't see a bug here so I close as WFM because of change. 
If I'm wrong, UX can correct.

Unfortunately on my system the problem is still there, even if it manifests slightly differently:

1) Open test doc
2) Note top of cloud picture halfway through the second row. Also note that the mid top handle of the cloud is on the cloud.
3) Put the cursor in A1 at the end of the word "foo". Press CTRL+ENTER 20 times to add 20 empty rows in the cell. Now the first row is much taller, but the top of the cloud is still halfway through the second row of the spreadsheet
4) Press CTRL-Z to undo the last change. Now the first row is back to a 1-line height. However, the cloud is now vertically mispositioned (top of the cloud is close to the bottom of the second row). Also note that the mid top handle of the cloud is slightly above the top of the cloud.

... at least on my system with LibO 7.0.2.1

Not a dramatic issue, but a burden if you have a spreadsheet with logos that must be accurately text aligned and someone does a lot of editing and undoes that end up messing the alignments...

Funny thing is that now the image handles remain correctly positioned, but the image gets mispositioned wrt its own handles.

Putting back to NEW as steps in comment 13 still are reproducible. The more more line breaks the more mispositioned is the image.

(In reply to Thomas Lendo from comment #18)
> Putting back to NEW as steps in comment 13 still are reproducible. The more
> more line breaks the more mispositioned is the image.
Tested with Version: 7.1.0.0.alpha0+
Build ID: 83aa172697c11a9550c27a28f8e62b523ec7086d
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-09-10_21:26:34

What's the purpose of this bug, just to stay open for years? 
I tested and didn't see a problem. If you claim there is one, make clear experienced and expected, like screenshot marking expected position, or comparison screenshot with other software behaving as you expect.

Looks like Thomas Lendo is also reproducing the issue, but evidently there isn't any. Let's reduce the bug count, then.

Created attachment 165863 [details]
Screenshot of mispositioned image after several line breaks

Version: 7.1.0.0.alpha0+
Build ID: a8c218a52a639b0e7f689dea878a0421702628e0
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-09-25_22:25:07

Timur and Sergio, I don't want an edit war, but what's the purpose of a bug when it's closed because it's old but somebody can still reproduce the issue?

I can reproduce the issue.

Sure, it's not so eye-catchting as in the past, thanks to the devs! But it's there and you can see it when you insert many line breaks (ctrl+return) in a cell above an image like in the test file of this bug report.

The more line beaks the more is the issue visible.

I set this issue status back to NEW.

If someone is saying this is not a valid bug and the behavior is as is should be, then please close the bug as WORKSFORME.

Adding Samuel Mehrbrodt to CC list as he worked on image anchoring in the past e.g. at bug 114552.

Sorry Thomas, thought it was clear that I was still seeing the bug and that to me it should have stayed open, no matter how old, even if there are no resources available to fix in the near time, at least to document the potential issue to other users who might encounter it and get surprised. However, this is no fun and I'd rather give in.

To Thomas again, I've seen your screenshot and I have a question. Once in the condition illustrated in the screenshot, if you select the cloud picture, are its handles also slightly misaligned with the cloud image itself?

Created attachment 165874 [details]
Handles correctly aligned to cells, but image now disaligned wrt its own handles

(In reply to sergio.callegari from comment #25)
> To Thomas again, I've seen your screenshot and I have a question. Once in
> the condition illustrated in the screenshot, if you select the cloud
> picture, are its handles also slightly misaligned with the cloud image
> itself?
Hi Sergio, you are right and that is what I've overlooked: The handles of the image are on the right position but the image itself is misaligned/mispositioned.

Please don't forget add the keyword needsUXEval when CC'ing libreoffice-ux-advise.

Don't get the point. The image is anchored to B2 and stays at B2 when A1 grows. If B2 is filled or anchor is set to page, it remains at its position. Maybe this was solved by Samuel's recent patch? => WFM

I can reproduce what is described in comment 26 and comment 27:
After several linebreaks in the first cell the image becomes mispositioned, but the handles are still correct. So probably some invalidation issue.

(In reply to Samuel Mehrbrodt (allotropia) from comment #30)
> I can reproduce... probably some invalidation issue.

No need for input from UX if the principal engineer agrees with the bug.

Dear sergio.callegari,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug