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.
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.
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. 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.
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: 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
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.
(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
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: 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
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
Dear Luke Kendall, 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! Warm Regards, QA Team MassPing-UntouchedBug
I have read the above text, and understood only some of it ... smiles ... but was pretty sure that the problem is not solved, and to make sure, I opened a large document and set autorecovery to 1 min and waited for it to make a save, but it didn't ... and now autorecovery doesn't work, no matter what timing I set it to? Couldn't Libre be made so that it saves what you write while it autosaves, and then puts it into the text afterwards ... like, for example, WordPerfect did, and Words does? Also, if I have several documents open, but minimized so that there are several orange dots next to Writer in the dock, before (under 18.04) I could just let the cursor hover over the icon for Writer and then it displayed the documents that were open, and I could select the text I wanted to work with. Now I have to press Writer, whereupon it opens the earliest opened of the text files, and if I then press Writer again, only then it shows the open texts so I can choose which one I want to work with ... how do I make Writer behave like before?
(In reply to Jax999 from comment #19) > I have read the above text, and understood only some of it ... smiles ... > but was pretty sure that the problem is not solved, and to make sure, I > opened a large document and set autorecovery to 1 min and waited for it to > make a save, but it didn't ... and now autorecovery doesn't work, no matter > what timing I set it to? There were recent fixes to the autorecovery option setting, for example bug 149178. You could test with version 7.4, which should be officially released next week https://wiki.documentfoundation.org/ReleasePlan/7.4
AFAICS, UserAutoSave, AutoSave and perhaps even AutoRecovery all use the same code. I don't see how this would not simply be a duplicate of bug 48416. *** This bug has been marked as a duplicate of bug 48416 ***