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

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!

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.

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.

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 

https://wiki.documentfoundation.org/QA/Bugzilla/Policies_and_Procedures

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

FWIW then turn off auto save

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...

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.

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

Setting things back like they were.  I only wanted to add myself to cc.

reopened and setting as an enhancement request.

Adjusting summary to reflect such.

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
        again.
    (*) 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
        progress!
    (*) 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
opinion!

Terry.

Setting status back to UNCO.  I think REOP applies only after a purported fix failed to fix the problem.

@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

Eh?  Bugzilla does not offer UNCO.  So status NEW is my accident.

But in light of Joel's comment 13, it seems right.

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.

*** Bug 67487 has been marked as a duplicate of this bug. ***

Changed component to LibreOffice as this question does not concern Calc only.

Best regards. JBF

@bfoman
"errare humanum est" and may happen both on reporter and QA side.

@everybody
I suspect this problem is inherited from OOo code or the "autosave/new imput typing" issue was not present in earlied versions?

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.

(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

Can I add my thoughts here please..
I use LibreOffice 4.2.4.2 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.

Adding self to CC if not already on

I'm using LO 5.0.2.2 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?

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