Bug 81627 - FILESAVE: buffer continued Keystrokes/characters while AutoRecovery/Autosave in progress and then apply to document
Summary: FILESAVE: buffer continued Keystrokes/characters while AutoRecovery/Autosave ...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected) release
Hardware: Other All
: low enhancement
Assignee: Not Assigned
Whiteboard: BSA
: 67487 (view as bug list)
Depends on:
Reported: 2014-07-22 01:33 UTC by Rafael Luik
Modified: 2018-01-04 20:21 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Rafael Luik 2014-07-22 01:33:37 UTC
Steps to reproduce:
1. Just work normally on a document, typing things once in a while.
2. Type anything *while* the AutoRecovery (that progress bar that appears at the bottom at time intervals defined on the settings) autosaves the document.

Current behavior:
What you type won't appear in the document if you manage to type while that AutoRecovery progress bar is autosaving the document. This is easy to reproduce in old notebooks or netbooks with other apps opened in the background or even good machines when under heavy load.
AutoRecovery simply blocks all text input while it's happening.

Expected behavior:
AutoRecovery shouldn't block text input.
Operating System: Windows XP
Version: release
Comment 1 Joel Madero 2014-07-22 02:56:06 UTC
This is not a bug, the document is on "pause" while the save is happening. Same thing happens when you are actually saving (ie. if you do ctrl + s on an older system, you can't type while it's saving).

Closing as NOTABUG
Comment 2 Rafael Luik 2014-07-22 03:09:40 UTC
1. I type something.
2. The software make me lose what I typed because of an automated behavior I haven't triggered.

Conclusion: This is not a bug, yeaaah makes sense, totally!
Comment 3 Joel Madero 2014-07-22 03:25:55 UTC
Please don't reopen the bug unless you have something constructive to say. You say that when the save is actually occuring, you cannot type in LibreOffice - this is expected behavior. Closing again.

Again please don't reopen the bug unless you have something constructive to say. If the above description is correct - then this is expected and the same thing happens when you save.
Comment 4 Rafael Luik 2014-07-22 04:16:49 UTC
A "save" is not occurring. AutoRecovery is obstructing my work. I mean my real "job" work.

If this is expected behavior then it makes LibreOffice impossible to use.

I'll also disagree with you until the end. What I'm saying is constructive.
Comment 5 Joel Madero 2014-07-22 04:18:48 UTC
Then turn off auto save. I am asking another person from QA to confirm that this is not a bug. Once a second agrees, it will be reclosed, if you continue to open it you will be blocked from FDO. See 


Again - I will request a second opinion but UNCONFIRMED for now is the right status.

FWIW then turn off auto save
Comment 6 Rafael Luik 2014-07-22 04:42:49 UTC
1. AutoRecovery is important, it's not to be easily given up.

2. This is a workaround to a bug. Changing the option will "solve" my problem while still keeping other users affected. Non tech-savvy users will still be left wondering why sometimes what they type don't show up...
Comment 7 dE 2014-07-22 05:19:16 UTC
While a file save occurs (not just autosave), the GTK UI freezes avoiding any new inputs.

This's not a bug, but a feature request. The text input area of the document, or the workable area of the document, or the UI as a whole should not be frozen when a document save occurs.

For a large document, it may take up to 30 seconds to save a document, which is very much undesirable. Most of the time is taken to compress and write the updated file to disk; if it's done in the background, most of the problem can be solved.

This's reproducible across platforms.
Comment 8 Jean-Baptiste Faure 2014-07-22 05:32:29 UTC
If I remember well cases where I was typing while autorecovery, the text appeared on the screen once the save was done. So nothing was lost.

That said, I agree with Joel comments, you can't modify your document while the program is saving informations necessary to rebuild it in case of crash.
If AutoRecovery is obstructing your work, you should choose an AutoRecovery frequency adapted to the power of your PC.

Closing again as NotABug.
Best regards. JBF
Comment 9 Terrence Enger 2014-07-22 05:53:14 UTC
Setting things back like they were.  I only wanted to add myself to cc.
Comment 10 V Stuart Foote 2014-07-22 13:37:59 UTC
reopened and setting as an enhancement request.

Adjusting summary to reflect such.
Comment 11 Terrence Enger 2014-07-22 15:05:02 UTC
I agree entirely that the current behaviour is frustrating (if you
wait for the autosave to finish) or worse (if you do not notice, and
end up losing keystrokes).  But to have keystrokes saved up and then
processed as a bunch can also be problematic.  Consider:
    (*) You are typing along, watching the document window.
    (*) The autosave starts.
    (*) You notice a letter not processed and you type the letter
    (*) And you type the letter a third time.
    (*) You twig to the fact that the problem does not arise from how
        your fingers meet the keyboard.  In fact an autosave is in
    (*) Okay, you have to delete those extra letters.  But how many?
        Are you sure?
I would probably just stop working until the autosave finishes.  And
that is just the result that the current program forces, except for
the potential confusion.

So, I ask: Can the UI be kept responsive while the autosave completes
in the background?  At what cost in programming effort?  At what cost
in machine resources?  I think we need a developer to comment on
whether a continuously responsive UI is feasible.

Other possible mitigations come to mind:
    (*) Allow the user to disable autosave on a per-document basis.
    (*) Start autosave only after the document (or LO as a whole?) has
        been idle for some length of time.
Again, I have no idea about the cost of these mitigations.

With apologies for the length.  And without even expressing a clear

Comment 12 Terrence Enger 2014-07-22 15:06:06 UTC
Setting status back to UNCO.  I think REOP applies only after a purported fix failed to fix the problem.
Comment 13 Joel Madero 2014-07-22 15:09:23 UTC
@Rafael - just a heads up. Pretty good discussion happened (public on qa list) with at least 6 people responding and it seems split as to what to call this but the general debate was between NOTABUG and Enhancement. So enhancement it is - got to love democracy in action :-D
Comment 14 Terrence Enger 2014-07-22 15:16:13 UTC
Eh?  Bugzilla does not offer UNCO.  So status NEW is my accident.

But in light of Joel's comment 13, it seems right.
Comment 15 bfoman (inactive) 2014-07-22 16:20:50 UTC
IMHO this is obvious duplicate of bug 67487, even the reporter commented there 7 minutes after filing this issue. Should be RESOLVED DUPLICATEd without this silly status war. 
People who do the triage - please search the Bugzilla database for duplicates before changing the status of any bug. Reporters should browse the Bugzilla too and are kindly asked to close own duplicated issues as Bugzilla build-in duplicate mechanism is a way to indicate hot issues.
I know that there is a pressure in QA to get under 500 UNCO bugs but please, do triage more carefully.
Comment 16 V Stuart Foote 2014-07-22 16:28:49 UTC
*** Bug 67487 has been marked as a duplicate of this bug. ***
Comment 17 Jean-Baptiste Faure 2014-07-22 18:34:25 UTC
Changed component to LibreOffice as this question does not concern Calc only.

Best regards. JBF
Comment 18 tommy27 2014-07-23 04:57:44 UTC
"errare humanum est" and may happen both on reporter and QA side.

I suspect this problem is inherited from OOo code or the "autosave/new imput typing" issue was not present in earlied versions?
Comment 19 Yousuf Philips (jay) (retired) 2014-07-24 02:09:46 UTC
With me having autosave enabled every 1 minute, this issue frustrates me quite a bit. I have the same issue with gedit as well, but when gedit is doing the autosave and i press a key during the autosave, it sounds the default alert sound, which gives me notice that something was wrong, so atleast i take notice of it.

My solutions to the issue would be that after the autosave time has run out, LibO waits for the user to stop typing (e.g. user hasnt pressed a key in 1 or 2 seconds) and then autosave. Of course if the user hasnt stopped typing in 10% of the autosave time, it should then autosave anyway. Normally people pause when typing to give time for their thoughts to continue flowing, so LibO can use this thoughts delay to autosave.
Comment 20 tommy27 2014-07-24 05:43:33 UTC
(In reply to comment #19)
> ...
> My solutions to the issue would be that after the autosave time has run out,
> LibO waits for the user to stop typing (e.g. user hasnt pressed a key in 1
> or 2 seconds) and then autosave. Of course if the user hasnt stopped typing
> in 10% of the autosave time, it should then autosave anyway.
> ...

I like this solution. +1
Comment 21 Rob 2014-10-09 09:17:10 UTC
Can I add my thoughts here please..
I use LibreOffice on Linux Mint 17 (64bit) Mate Edition, and rely on Calc and Writer to run my business.
I touch type at speeds of 90wpm+ so I may frequently be type-copying into writer from handwritten notes or entering rows of numbers into calc, without glancing at the screen.
I have lost count of the number of times that I have huge missing chunks of text or data because autosave has kicked in and I was not aware. It is unbelievable frustrating!
surely there should be a mechanism in place that caches all keyboard strokes whilst autosave is running.
... and before anyone suggests turning autosave off, my premises suffers from bad mains supply, and I could easily lose an hours work if it trips, because I never remember to press CTRL-S whilst I am on a roll (bad memory) - I have Autosave set to every 2 minutes.

I would respectfully suggest that this is a bug - and definitely not expected behaviour.
Comment 22 Alex Thurgood 2015-01-03 17:39:17 UTC
Adding self to CC if not already on
Comment 23 Luke Kendall 2015-11-05 04:39:15 UTC
I'm using LO and this enhancement has been implemented and works well.  It is a huge relief!  I too have lost whole sentences because I've been typing and not noticed that autosave kicked in while I was doing so, and on my novel, that typically meant I would lose about 20 words.

I just wanted to say Thank You for implementing this very welcome enhancement.

BTW, is it not marked Resolved because it's still undergoing testing?
Comment 24 tommy27 2015-11-05 04:44:36 UTC
let's set status to RESOLVED WORKSFORME at the moment
I ask other users to confirm this issue is gone.
if not, please explain and revert status to NEW