https://bugs.documentfoundation.org/show_bug.cgi?id=152098

Stéphane Guillou (stragu) <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Status|NEEDINFO                    |RESOLVED

--- Comment #16 from Stéphane Guillou (stragu) 
<[email protected]> ---
(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 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 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to