Bug 95446 - After image is deleted, view is not scrolled and caret is misplaced
Summary: After image is deleted, view is not scrolled and caret is misplaced
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.7.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-Images
  Show dependency tree / graph
 
Reported: 2015-10-30 12:46 UTC by rbruenner
Modified: 2023-11-03 01:10 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:

Attachments
Sample document and screenshots to illustrate the bug (888.52 KB, application/x-7z-compressed)
2015-10-30 12:46 UTC, rbruenner 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description rbruenner 2015-10-30 12:46:53 UTC 
Created attachment 120106 [details]
Sample document and screenshots to illustrate the bug

When a big picture is on top of a page (leaving some whitespace on the page before), the caret is at the same position on page but not on the paragraph the image was deleted from.

In the attachment, there is a document and some images to describe the issue.
First, the normal and expected behaviour:
1. Scroll to Fig. 1.
2. Select the image. (-> see Select image.png)
3. Delete the image. (-> see After delete (OK).png)
The picture is removed, the caret is in the paragraph where the image was before, and the user may insert a different picture or add some text at the very same position. This is OK.

It is no longer that OK when the image is so big that it is moved on top of a new page:
4. Undo all steps from before.
5. Scroll to Fig. 2. It is big, on top of a page, and the page before has considerable whitespace at its end.
6. Select the image. (-> see Select big picture on top.png)
7. Delete the image. (-> see After delete (huh - where is my caret).png)
Now, things get weird. After the image has been removed, the paragraph where it was located is only one printing line high. Therefore, it does not go onto a new page. The ex-image row, together with its description line below moves to the page before. The text scrolls accordingly. So far, so good. HOWEVER, the view is kept at the top of the page where the image was before. What makes things EVEN WORSE is the fact that the caret stays there as well. It is no longer in the paragraph where the image was before. When you now start typing or insert a different image without paying notice, it gets in the middle of some completely unrelated paragraph.

This behaviour annoys and frustrates users a lot.

The caret should stay in the same paragraph as the image was in before (like in the first example). Additionally, this paragraph should be scrolled into view when it got outside the view window for what reason ever.
Comment 1 A (Andy) 2015-11-07 10:38:01 UTC 
Thanks for your very precise bug report.

Reproducible with LO 5.0.3.2, Win 8.1
Comment 2 QA Administrators 2016-11-08 11:54:17 UTC Comment hidden (obsolete)
Comment 3 rbruenner 2016-11-23 11:44:13 UTC 
I can confirm that the behaviour is still the same under Windows 10 using LO 5.1.6.2
Comment 4 Thomas Lendo 2017-06-23 23:56:13 UTC 
Reproduced with Version: 6.0.0.0.alpha0+
Build ID: 6ef59d7ace7e4db52caea601a384ed016365bcaf
CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-06-20_01:21:33
Locale: de-DE (de_DE.UTF-8); Calc: group
Comment 5 QA Administrators 2018-06-24 02:41:48 UTC Comment hidden (obsolete)
Comment 6 Thomas Lendo 2018-12-06 22:17:37 UTC 
Still reproducible with Version: 6.3.0.0.alpha0+
Build ID: 684641b3f85850f9ae1bd36ef24e4ca89fac95f4
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: de-DE (de_DE.UTF-8); UI-Language: en-US, Calc: threaded
Comment 7 QA Administrators 2019-12-07 03:42:31 UTC Comment hidden (obsolete)
Comment 8 QA Administrators 2021-12-07 04:57:10 UTC Comment hidden (obsolete)
Comment 9 Steven Casey 2023-11-03 01:10:21 UTC 
Still reproducible in

Version: 7.6.2.1 (X86_64) / LibreOffice Community
Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
CPU threads: 32; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded