Bug 89816 - Image anchored to paragraph doesn't move back after entering and deleting a new paragraph above
Summary: Image anchored to paragraph doesn't move back after entering and deleting a n...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-Images Undo-Redo
  Show dependency treegraph
 
Reported: 2015-03-04 15:25 UTC by rbruenner
Modified: 2023-12-08 20:35 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
odt file and pictures describing the problem (564.81 KB, application/x-zip-compressed)
2015-03-04 15:25 UTC, rbruenner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description rbruenner 2015-03-04 15:25:57 UTC
Created attachment 113874 [details]
odt file and pictures describing the problem

When an image is at the end of the page and text is entered in a paragraph before, the image may get wrapped to the next page. When the text is removed again, the image might not get wrapped back to the previous page.

In the attachment you can see what I mean.
Image 1 is taken after inserting the image. Fine.
Image 2 is taken after a new paragraph has been entered above. Image wraps to next page. Maybe.
Image 3 is taken after the new paragraph has been removed. The text above the image is now exactly the same as before. However, the image does not wrap back to the bottom of this page. I would expect to get the same result as shown in Image 1.
Comment 1 Buovjaga 2015-03-15 17:41:50 UTC
Reproduced using attachment 113874 [details], doing it exactly like in the screenshots.

Note that save & reload returns the image to its right place, so it looks like some repagination issue (thx to Jay Philipz for noticing). Lowering severity to minor because of this. https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg

Changed title to be more descriptive.

Somehow I can't produce a matching document from scratch, but maybe I just didn't try hard enough :)

Win 7 Pro 64-bit, LibO Version: 4.4.1.2
Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432
Locale: fi_FI

Version: 4.5.0.0.alpha0+
Build ID: 16b8fbb2e0c72ce321c9f569284f4ef37339af2c
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-03-10_09:56:13
Locale: fi_FI

Ubuntu 14.10 64-bit 
Version: 4.4.1.2
Build ID: 40m0(Build:2)
Locale: en_US

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 2 tommy27 2016-04-16 07:27:10 UTC Comment hidden (obsolete)
Comment 3 rbruenner 2016-04-18 05:47:22 UTC
Tested with LO 5.1.2 on Mac OS X 10.10.5

I can confirm that the bug is still there. This is expected since no explicit action has obviously been taken to fix it.
Comment 4 Buovjaga 2016-04-18 05:56:47 UTC
(In reply to rbruenner from comment #3)
> Tested with LO 5.1.2 on Mac OS X 10.10.5
> 
> I can confirm that the bug is still there. This is expected since no
> explicit action has obviously been taken to fix it.

Actually it is not 100% expected :) See this: https://lists.freedesktop.org/archives/libreoffice-qa/2016-April/009510.html

"3595 bugs were pinged, of those 803 turned from NEW to a RESOLVED status after being retested by LibO users."
Comment 5 rbruenner 2016-04-18 06:46:15 UTC
Thanks for your answer.
But how do you feel about it?
22 % of the bugs "silently" went away. By some regression elsewhere? By accident? Is there a chance that some of them might reappear as silently as they went away in the first place?

On the other hand, 78 % of the bugs did not go away. Please do not get me wrong. But you can do a bug database review regularly yourself without asking the users again and again. Most items contain documents for your reference and detailed steps to reproduce the issue.

So my question is whenever a new version is being prepared
why is the QA team not looking into the confirmed issues to verify whether they are still there and if not, let the developers investigate the reason (fixed deliberately, fixed as a collateral etc.)? A "went SOMEHOW away" is not a satisfying answer in software development.
When you investigate how bugs evolve with each version, you can be more certain that a particular bug has actually been fixed when it happens to no longer show up.

Please also remember that there are so many users out there who do not bother sending a bug report at all. They complain about the issues and move away. So your bug database is a valuable input for developing the next versions. It is something you can rely on.
Comment 6 Buovjaga 2016-04-18 06:57:57 UTC
From your comment, it seems you think the QA team is paid for what they do. We are users just like everybody else.
For the record, I *have* retested hundreds (thousands?) of the reports that did not get retested by their original reporters. I did it because I was interested in precisely the statistics we now see.
Comment 7 rbruenner 2016-04-18 07:26:17 UTC
(In reply to Buovjaga from comment #6)
> From your comment, it seems you think the QA team is paid for what they do.
> We are users just like everybody else.
I am fully aware that most (all) of you are volunteers.

> For the record, I *have* retested hundreds (thousands?) of the reports that
> did not get retested by their original reporters. I did it because I was
> interested in precisely the statistics we now see.
Your work is greatly appreciated. I just wanted to express my concerns.

When I see a request to re-confirm a bug reported by me, I sometimes have the impression that if I do not respond in a timely manner, the bug might get silently "downgraded" as not important enough. And from my work environment, I can say that I seem to be the only one who bothers to report bugs at all. The other ones only complain. Therefore, much more users are affected.

I am involved in software development as well. A bug is of top priority. If nobody is assigned to fix it, it will not get fixed. If it disappears, there must be a reason. If nobody investigates the issue, it might show again later. So the bug may just be hidden - and not fixed. So, I do expect a final bug resolution only when a developer actually looks into the issue.
Comment 8 QA Administrators 2017-05-22 13:23:43 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2019-12-03 14:33:41 UTC Comment hidden (obsolete)
Comment 10 Timur 2020-10-01 14:27:19 UTC
Repro 7.1+
Comment 11 QA Administrators 2022-10-02 03:38:31 UTC Comment hidden (obsolete)
Comment 12 Tex2002ans 2023-12-08 20:35:19 UTC
I can still reproduce in:

Version: 7.6.4.1 (X86_64) / LibreOffice Community
Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

- - -

Same exact thing happens if you:

1. Press ENTER before "Consetetur sadipscing elitr," paragraph right above the image.
2. Press Edit > Undo (Ctrl+Z).

The image will not return to the original position.

(Based on that, I'm adding the "Undo-Redo" metabug to this too.)