Description: A large document (six copies of Vanity Fair, 2,500 A4 pages, 1.8 million words, just plain default text - no images, tables, footnotes etc) takes about 120 seconds to open in 7.3.7.2. It opened in about 8 seconds in 7.0.6.2. When it does finally open the cursor is at the first character in the file and not at the last cursor position. Steps to Reproduce: 1. Download attached Vanity Fair - six copies.odt. 2. Open with 7.3.7.2 and make an edit towards the end. This places your information as editor and should allow to document to open at the cursor position. 3. Note the cursor position. 4. Save file. 5. Open file. Actual Results: 1. It takes about 120 seconds before the blue circle stops spinning and I can type, scroll etc. 2. The file opens with the cursor at the beginning. Expected Results: 1. The file should open in about 8 seconds and allow me to type, scroll etc as it did in 7.0.6.2. 2. The file should open with the cursor at the position at which YOU last saved it as it did in 7.0.6.2. Reproducible: Always User Profile Reset: Yes Additional Info: 1. See also Bug 152097 - Writer document does not open at last cursor position where much smaller document opens with cursor at random positions. 2. This appears to be a regression - all worked OK with 7.0.6.2. 3. I had User Data in Tools > Options ..., which is necessary for LO to open the file at the last cursor position. 4. Resetting the profile (delete...\user, then add back User Data) had no effect.
Created attachment 183654 [details] Large file with 2,500 A4 pages of text Large file with 2,500 pages of A4 default text. My User data was Forename: John Surname: Ha Initials: JH
"the cursor is at the first character in the file and not at the last cursor position" is the direct consequence of the slowdown, and is bug 141586.
On the other hand, it opens fast (under 4 s on my system) using Version: 7.4.3.1 (x64) / LibreOffice Community Build ID: 3793858a34d8fef5b92f8fee233f97766f05e281 CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL => WORKSFORME?
I can't reproduce. Open and responsive in about 10 seconds with: Version: 7.0.6.2 Build ID: 144abb84a525d8e30c9dbbefa69cbbf2d8d4ae3b CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: de-DE (en_AU.UTF-8); UI: en-US Calc: threaded Open and responsive in about 7 seconds with: Version: 7.3.6.2 / LibreOffice Community Build ID: c28ca90fd6e1a19e189fc16c05f8f8924961e12e CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: de-DE (en_AU.UTF-8); UI: en-US Calc: threaded Could be Windows-specific, but in any case, version 7.3 is not supposed to get further bugfix releases, so could you please try it with 7.4 ? (Snappy as well for me.)
I (OP) cannot reproduce today. I was doing testing by saving with the cursor in various positions in the file and it was reproduceable so I am wondering if it is cursor position dependent and/or related to the cursor location problem bug 141586. When testing this morning on the first occasion it opened OK and I could scroll, but it then locked up. I had minimised its window and I could not re-open the window. CPU was at 26%. On the second, third and fourth tests it opened within a few seconds and did not lock up. My PC is minimal with few startup programs which could interfere.
[Automated Action] NeedInfo-To-Unconfirmed
I can't reproduce the slowness opening the document, but I can see some performance issues (high CPU use) with such a large document in all versions tested (7.0 to recent 7.5 master build). I found it hard to test, as one has to be sure not to trigger bug 147802 (fixed in 7.4.4 and master) when testing, as it can really hang Writer and delay actions like scrolling, selecting, saving and closing. Could you please test in a current master build, to make sure that the header/footer issue is not part of the problems you see: https://dev-builds.libreoffice.org/daily/master/current.html
(In reply to Stéphane Guillou (stragu) from comment #7) > I found it hard to test, as one has to be sure not to trigger bug 147802 Note bug 152019 comment 1, describing how to disable that feature in any version, thus allowing to eliminate this aspect from testing.
I don't experience any slowness. Re-opening at cursor position doesn't work out well, though. Sometimes it works I end up somewhere different (not on the first page though)
My (OP) PC is 2 x 3GHz, 7 GB, SSD. Using the latest build as linked 1. File always opens quickly 2. If the cursor was in the middle of the file (page 1,521), after opening there is a pause of about 6 - 8 seconds before the file jumps to the saved cursor position on page 1,521. 3. If the cursor was towards the end of the file (page 2,497), after opening the page count remains at Page 1 of ..., and the screen view is at an unknown place. After 6 - 8 seconds the cursor jumps to page 2,476 - ie not the correct place. 4. If the cursor was at page 2,300 there is a pause after opening of about 17 seconds before the document jumps to the page 2,300 cursor position. This suggests to me the file in 3. was attempting to open at the cursor position but ran out of time. 5. After Save, there is a 15 to 20 second pause before the green bar starts crossing the screen. The file then saves quickly. The file is flat, unformatted text without headers, footers, footnotes, images, tables etc - just continuous default text.
Continuing ... I disabled the "open at cursor position" option. 1. The file opened quickly at a position well towards the end of the file as suggested by the scroll bar on the window but the page count said Page 1 of ... (I didn't check the ...). After 8 - 10 seconds I moved the mouse and the page count changed to Page 2,265 and the cursor was in that page. 2. I repeated the test and did nothing. After 40 seconds the page count still said Page 1 of .... I brought the mouse into the window and the page count changed to Page 2,265 of 2,498 and the cursor appeared in page 2,265.
I can confirm the issues with LibreOffice Writer being slow in opening large .odt files and then not remembering the last cursor position if the cursor was last somewhere in the latter part of the document. Can reproduce with the Vanity Fair document from OP. Some of the issues with reproducibility might just have to do with hardware and the sizes of the files. I work with files that can be larger than the example here, and take longer to open. E.g., one ~1,500 page file I frequently work with (more complex formatting than the example here) takes 15 seconds to open on a recent ThinkPad T14 laptop with a new i5 processor, whereas it takes a full minute on an older ThinkPad T420s laptop (11 years old). The cursor issues happen in both though. I'm on version 7.4.4.2, but this has been happening for a while now. Tested on Kubuntu 22.10 (Plasma 5.25.5), X11; happens in regular Ubuntu versions as well. This is definitely not a Windows-only problem.
John Ha, unfortunately nobody could confirm you bug so far. So I'd like to ask, if it is still valid, because. a new major release of LibreOffice is available since this bug was reported. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? => NEEDINFO
(In reply to Dieter from comment #14) > John Ha, unfortunately nobody could confirm you bug so far. So I'd like to > ask, if it is still valid, because. a new major release of LibreOffice is > available since this bug was reported. Could you please try to reproduce it > with the latest version of LibreOffice from > https://www.libreoffice.org/download/libreoffice-fresh/ ? > => NEEDINFO This is marked for Windows, but I experience the same issue in Linux: large files (1,000+ pages) still take a long time to load in Writer and the cursor is placed randomly in the middle of the document (not the end, i.e., where it was last when the document was last saved). My version info using Kubuntu 24.04: Version: 24.2.3.2 (X86_64) / LibreOffice Community Build ID: 420(Build:2) CPU threads: 12; OS: Linux 6.8; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-US (en_US.UTF-8); UI: en-US Ubuntu package version: 4:24.2.3-0ubuntu0.24.04.2 Calc: threaded
(In reply to Jackson Sul from comment #15) > This is marked for Windows, but I experience the same issue in Linux: large > files (1,000+ pages) still take a long time to load in Writer and the cursor > is placed randomly in the middle of the document (not the end, i.e., where > it was last when the document was last saved). As said in comment 2, if loading of your file takes a long time, this might be bug 141586. Let's focus on attachment 183654 [details] for out tests. As the file now opens quickly enough (as reported in comment 10), let's focus on the cursor position. Because Linux seemed unaffected by the slow load JohnHa experienced, I was able to find when the cursor issue started. Testing with a recent trunk build: - on Ubuntu 22.04, - in single page view, 100% zoom - with a name in Tools > Options > LibreOffice > User Data - after adding some text at the end of the document and saving then reloading - after loading, type some text to see where cursor actually is (the view port might be on the last page, but the cursor elsewhere) I find that: - opening the file is snappy (with some further layouting taking a few seconds but LO taking input without a freeze) - cursor is on page 2488 instead of the last one (2504) Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: b860aea9d6f8ac46f6d2575ead25337495ec9a88 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded Same with 7.3.0.3 (although in page 2477). With 7.2.0.4, and the rest as described above, the cursor position is correctly restored at the end of the document. Looking at bug 140147 comment 46, I checked at commit 6433dc223f6d21570e7132c4a580d186a5d5a334 (which is build [df462691a013a8e99d9a11c0620dd03016fedfab] in linux-64-7.3 repo), and indeed that's where it started. (Note that one has to edit and save to reproduce the issue, which makes it a filesave issue rather than fileopen.) *** This bug has been marked as a duplicate of bug 140147 ***