Bug 106208 - Writer loses last user event if auto-save triggers nearly at the same time
Summary: Writer loses last user event if auto-save triggers nearly at the same time
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.2.5.1 release
Hardware: x86-64 (AMD64) All
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: dataLoss
Depends on:
Blocks: AutoSave-AutoRecovery-Backup Main-Loop
  Show dependency treegraph
 
Reported: 2017-02-27 05:40 UTC by Luke Kendall
Modified: 2020-07-03 09:56 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Obfuscated sample long doc (544.39 KB, application/vnd.oasis.opendocument.text)
2017-11-25 03:00 UTC, Luke Kendall
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kendall 2017-02-27 05:40:17 UTC
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.
Comment 1 Luke Kendall 2017-02-28 00:27:19 UTC
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.
Comment 2 Buovjaga 2017-03-15 11:36:03 UTC
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..
Comment 3 Xisco Faulí 2017-03-16 08:38:16 UTC
(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.
Comment 4 Xisco Faulí 2017-11-24 18:12:30 UTC
Hi Luke,
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.
Comment 5 Luke Kendall 2017-11-25 03:00:36 UTC
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.)
Comment 6 Telesto 2017-11-29 18:47:48 UTC
A side note. Scrolling is also pretty slow. Seems to be related to bug 113091
Comment 7 Telesto 2017-12-20 16:46:40 UTC
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.

Version: 6.1.0.0.alpha0+
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.
Comment 8 Terrence Enger 2018-01-04 20:21:07 UTC
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.
Comment 9 Telesto 2018-01-04 20:37:19 UTC
(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)
Comment 10 Luke Kendall 2018-03-28 03:59:25 UTC
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:

 Version: 6.0.1.1
Build ID: 60bfb1526849283ce2491346ed2aa51c465abfe6
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2; 
Locale: en-GB (en_AU.UTF-8); Calc: group
Comment 11 Luke Kendall 2018-08-02 13:37:24 UTC
I don't know if things have changed for version 6.0.5.2, 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.
Comment 12 Telesto 2018-08-02 13:48:19 UTC
(In reply to Luke Kendall from comment #11)
> I don't know if things have changed for version 6.0.5.2, 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.

Repro
Version: 6.2.0.0.alpha0+
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
Comment 13 Telesto 2018-08-02 14:00:48 UTC
Adding bug 113091 (see bug 113091 comment 7) as see also for the choppy scrolling combined with high CPU usage
Comment 14 Buovjaga 2018-09-24 06:58:08 UTC

*** This bug has been marked as a duplicate of bug 94800 ***
Comment 15 Buovjaga 2018-10-22 15:53:53 UTC

*** This bug has been marked as a duplicate of bug 48416 ***
Comment 16 Telesto 2020-07-01 09:37:39 UTC
A assume this is know:
https://opengrok.libreoffice.org/xref/core/framework/source/services/autorecovery.cxx?r=a2fc8831#2227

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
Comment 17 Telesto 2020-07-01 15:25:57 UTC
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