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
5. double click the file to open it in Writer
The cursor is at the top of the file
The cursor should have been at the end of the file before the word "baaaay"
User Profile Reset: Yes
(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.
Created attachment 157634 [details]
It is an ODT file containing circa 12,000 characters, no graphics. The text has been anonymized
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.
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)
(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
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 184.108.40.206
I double checked on a Windows 10 system with LO 220.127.116.11, 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?
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: 18.104.22.168.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
and also with
Version: 22.214.171.124 (x64)
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win;
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Setting this as OS all, as it was confirmed on Windows
Prioritizing based on the QA flow chart
Dear Hugh Cautley,
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!
Still present in
Version: 126.96.36.199.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
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
*** This bug has been marked as a duplicate of bug 116099 ***