I've been noticing for the last year or two, that Writer seems to lose events during an auto-save. For my long documents, where an auto-save takes about 20 seconds to complete, if you typed something just before the auto-save triggers, the user event is lost.
I've had all sorts of events lost: character input to the main body, or to a comment; formatting changes (via Ctrl-I). The most serious was a Ctrl-S to save, which I assumed had happened because I saw the save progress bar. But in fact it was an auto-save, since I lost a little data when Writer crashed within the next auto-save period. I was particularly puzzled when I looked at the file modification time on the file, since I remembered the save.
Today, I had just pulled up the menu and clicked on the button to insert a blank page when auto-save triggered. I waited, fully expecting to see the blank page inserted as soon as the save completed. Instead, nothing happened.
I'm going to see if I can make a document to give you as a test case. It's a little tricky to reproduce, as you have to wait for an autosave and then type or do something an instant before the auto-save triggers. Otherwise the event goes through to Writer and is of course correctly consumed and handled.
At least you'll have this report, however.
It's really hard to reproduce this because you have to know in advance when the auto-save is about to kick in, and then, about 100msec before, generate your event. And who knows, it could even be a compiz or X11 thing losing the event. I tried for a few hours to deliberately generate the behaviour, but never got the timing right. But since I've been writing very actively with Writer for almost two years now (probably averaging 8hrs/day), it's happened often enough for me to be confident it does happen.
I know that's little help to you guys, though. I think you'd need a code inspection, or some test harness that let you trigger auto-saves during streams of auto-generated input (like a repeating sequence of digits) and then look for missing characters.
Xisco: do you think a UI test could be created for this to help with repro? If we are able to observe an auto-save event, wait the exact amount of milliseconds and then input something at the right moment..
(In reply to Buovjaga from comment #2)
> Xisco: do you think a UI test could be created for this to help with repro?
> If we are able to observe an auto-save event, wait the exact amount of
> milliseconds and then input something at the right moment..
I'm not sure the UItest can handle the auto-save event, but I'll ask moggi as he is the expert.
Could you please share one of those long documents you mentioned in the description?
(Please note that the attachment will be public, remove any sensitive information before attaching it.
See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
Created attachment 137973 [details]
Obfuscated sample long doc
Here is a requested long file. (For me, a manualsave takes about 10 secs. Which reminds me: auto-save seems to take a lot longer than a manual save. I don't know if that's to be expected.)
A side note. Scrolling is also pretty slow. Seems to be related to bug 113091
I tend to confirm this, only pretty hard to reproduce. It's timing of the editing and there is some CPU load needed to make everything running slow.
I have seen similar behavior on MacOS, with a Instrument Leak profile running while making edits.
Build ID: aad9c6da5154a89c6ef02214d1122d4b444eea23
CPU threads: 4; OS: Windows 6.3; UI render: default;
TinderBox: Win-x86@42, Branch:master, Time: 2017-12-15_22:56:44
Locale: nl-NL (nl_NL); Calc: CL
Steps to reproduce
1. Make LibreOffice run slow (create CPU load and/or use a large complex document)
2. Set auto-save to 1`minute
3. Edit some text just when before the autosave.
Is this a reappearance of bug 81627, I wonder? Or has the problem been ongoing without anybody complaining? That bug was set RESOLVED WORKSFORME rather tentatively.
(In reply to Terrence Enger from comment #8)
> Is this a reappearance of bug 81627, I wonder? Or has the problem been
> ongoing without anybody complaining? That bug was set RESOLVED WORKSFORME
> rather tentatively.
Is this a reappearance of bug 81627. Yes, I would say so.. Again it's hard to reproduce in normal cases (as far I can tell).
It will most likely happen with (large, complex) documents which LibreOffice can't handle perfectly causing a higher CPU load. Like bug 114012, bug 113091 or a document with lots of comments. Or with a lot of background processing (Prime95)
Just noting that it happened again twice today while composing text in a simple document (a novel) that's 98k words. (Maybe only 50 comments all together, so far, and LO is very responsive.)
First occurrence was typing "ae" just after an auto-save had started - both characters were lost.
Second occurrence was typing a " to be the start of a piece of dialogue (with smart quotes enabled, if that's relevant), an instant *before* the auto-save started. (It *looked* as if typing '"' started a save, heh.) But when the auto-save finished, no double quote appeared in the body.
I'm currently using:
Build ID: 60bfb1526849283ce2491346ed2aa51c465abfe6
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2;
Locale: en-GB (en_AU.UTF-8); Calc: group
I don't know if things have changed for version 188.8.131.52, but this is now super-reproducible.
Just have a large document with lots of comments, so that auto-saving takes 20 or 30 seconds to complete.
Wait for an auto-save to start, and then type pretty much whatever you like: from a few words, to just one or a series of CTRL-S characters, to try to save the document after the auto-save completes.
None of the events get through.
(In reply to Luke Kendall from comment #11)
> I don't know if things have changed for version 184.108.40.206, but this is now
> Just have a large document with lots of comments, so that auto-saving takes
> 20 or 30 seconds to complete.
> Wait for an auto-save to start, and then type pretty much whatever you like:
> from a few words, to just one or a series of CTRL-S characters, to try to
> save the document after the auto-save completes.
> None of the events get through.
Build ID: 76bf3939b0583212a56c317c85aea110f8ac6fee
CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default;
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2018-07-27_06:01:47
Locale: nl-NL (nl_NL.UTF-8); Calc: group threade
Adding bug 113091 (see bug 113091 comment 7) as see also for the choppy scrolling combined with high CPU usage
*** This bug has been marked as a duplicate of bug 94800 ***
*** This bug has been marked as a duplicate of bug 48416 ***
A assume this is know:
Strange part, they 300 delay is defined for autorecovery save. The same logic isn't applied for autosave, I think. Not that I pretend to be able to actually read the code ;-)..
So maybe LibreOffice should check 'if there is still key-input'. And only starting the autosave if there is some small idle gap. So not withing a sentence..
However everybody is typing at different speeds.. so still room for failure
Ideally bug 48416 gets solved.. but this could maybe/ideally be optimized/ tweaked a little without lots of effort (so wouldn't call this a dupe of bug 48416 straight forward).
Of course if this still a problem.. but that's up to Luke
Splitting this off again.. this is related to bug 48416.. If bug 48416 would get fixed, this issue gets resolved too. OTOH, this can probably be optimized without a 'grand' redesign.. This could be more a "temporary"/ quick fix.
In my 'optimistic' mood, maybe an easy hack. Code is nicely documented. Enough cases are described. So "feels" like a copy/paste fix.. to time the start of a autosave run a little better.
OTOH, number of complains are rather low.. And autosave/ auto-recovery is bit of delicate area
@Xisco/Buovjaga.. any opinion