Bug 130418 - WEB LAYOUT: On FILEOPEN an ODT file in Writer the cursor position is not consistently restored to the last FILESAVE position, if document is in web view
Summary: WEB LAYOUT: On FILEOPEN an ODT file in Writer the cursor position is not cons...
Status: RESOLVED DUPLICATE of bug 116099
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.4.0.3 release
Hardware: All All
: low trivial
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Writer-Web-Layout
  Show dependency treegraph
 
Reported: 2020-02-04 10:39 UTC by Hugh Cautley
Modified: 2022-02-15 07:37 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
It is an ODT file containing circa 12,000 characters, no graphics. The text has been anonymized (38.34 KB, application/vnd.oasis.opendocument.text)
2020-02-04 10:43 UTC, Hugh Cautley
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hugh Cautley 2020-02-04 10:39:52 UTC
Description:
A test fileof approximately  12000 characters has been prepared. If the cursor is placed near the start of the file for example at the character "8" 6 lines down, then a blank space is entered and the file saved and closed, on reopening it will be at the last saved position - character "8".
If the cursor is placed near the end of the file, before the last word "baaaay", entering a blank and then saving and exiting. On reopening the file the cursor will be placed at the top of the file, some 12,000 characters before the correct position.
 

Steps to Reproduce:
1.Open the enclosed test file
2.place the cursor at the end of the file before the last word "baaaay"
2.enter a blank space
3.save the file
4.exit Writer
5. double click the file to open it in Writer

Actual Results:
The cursor is at the top of the file

Expected Results:
The cursor should have been at the end of the file before the word "baaaay"


Reproducible: Always


User Profile Reset: Yes



Additional Info:
(1) When editing this test file to make it shorter, the problem would disappear when most of the text in the mid of the file was deleted.
(2) When preparing a different short test file with (anchored to page) graphics the cursor position stopped defaulting to the top.
(3) On removing the graphics the last saved cursor function was then working as expected.
Comment 1 Hugh Cautley 2020-02-04 10:43:50 UTC
Created attachment 157634 [details]
It is an ODT file containing circa 12,000 characters, no graphics. The text has been anonymized
Comment 2 Hugh Cautley 2020-02-04 11:01:36 UTC
One other aspect, viewing a document in "Normal" view produces the correct behaviour (cursor placed at last saved position) more often than viewing a document in "Webview".

I have another file where this is highly reproducible, Normal view it works, Webview it doesn't. 

However the amount of content and type e.g. graphics and graphics and text also seem to play a role.
Comment 3 Dieter 2020-02-04 18:57:59 UTC
Hugh, there might be something wrong with your file, because I can't enter e blank page with Strg + enter or Insert > Page break (it only produces a new paragraph)
Comment 4 Hugh Cautley 2020-02-04 19:47:11 UTC
(In reply to Dieter from comment #3)
> Hugh, there might be something wrong with your file, because I can't enter e
> blank page with Strg + enter or Insert > Page break (it only produces a new
> paragraph)

Hi Dieter, Very strange, I went back just now to the file placed the cursor after the character "8" on page 2, and entered COMMAND + ENTER. It placed a new page after 8, the text starting "aaaat" is now on page 3 and 8 is still on page 2.
Also using the menu commands INSERT + PAGE BREAK works fine.
To produce a new paragraph also works fine, I just need to enter SHIFT +ENTER
That was on an macOS(10.15.3)(Catalina) with LO 6.4.0.3

I double checked on a Windows 10 system with LO 6.3.2.2, and everything behaved the same way as the Macbook. Here I entered the Ctrl+ENTER.....

One thought I sent you a rather big file. I had first tried to make it smaller and remove confidential information. I did this page by page, checking each time and noticed that at a certain point the problem seemed to disappear.

The best I could do was to note that if the cursor was near the end of the file the problem would reappear, if placed near the beginning of the file the problem would disappear. Beginning and end of the file meant within a few characters of the absolute end and beginning of the 12000 character file.

Have you any suggestions how to check the integrity of the file, for all other aspects it seems to work fine? or is there anything else I can do to help?
Comment 5 Dieter 2020-02-05 04:51:18 UTC
Sorry Hugh, my fault, I read "blank page" instead of "blank space" in your steps and haven' t seen, that it is in WebView

I could reproduce the problem with

Version: 7.0.0.0.alpha0+ (x64)
Build ID: eeb2d19e77d6dc47c68e8ba0920a02cf64a1247b
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-GB
Calc: threaded

and also with

Version: 6.3.4.2 (x64)
Build-ID: 60da17e045e08f1793c57c00ba83cdfce946d0aa
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: threaded
Comment 6 eisa01 2020-02-15 23:08:43 UTC
Setting this as OS all, as it was confirmed on Windows

Prioritizing based on the QA flow chart
Comment 7 QA Administrators 2022-02-15 04:11:49 UTC Comment hidden (obsolete)
Comment 8 Dieter 2022-02-15 07:27:26 UTC
Still present in 

Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 95b80365218f9406a5d952c1250d53222d319000
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: CL

Steps:
1.Open attachment 157634 [details]
2.place the cursor at the end of the file and type at least one character
3.save the file and close document
4.Reopen file
Comment 9 Dieter 2022-02-15 07:37:20 UTC

*** This bug has been marked as a duplicate of bug 116099 ***