Wrong order of save field VS save session (due to a bad connection) causes loss of content

See CMS-5596. Description of that issue is copy+pasted below.

Problem is reproducable in the latest archetype and Gogreen using Firefox 14.01 and Tamper Data 11.0.1.

Looking at the commit of CMS-5596, it seems that not much has changed to the code/components of the actual commit. So either some new code is conflicting or it was never properly fixed.

---------

At the client quite often after updating a field in the document editor and pressing save the session was not saved; after clicking save again it did get saved.
Using save&close it wouldn't be saved properly.

Reproduction path using Firefox plugin Tamper Data to hold off the POST requests which happen after editing a field:
1. Open Firefox (close all other firefox tabs/windows, otherwise Tamper Data is really annoying)
2. Open the CMS
3. Edit some document
4. Open a Xinha field and wait till everything is loaded
5. Turn on Tamper Data (Tools - Tamper Data; press Start Tamper)

During the next steps (4/5/6) do NOT press anything on the Tamper Data popups, instead; just go back to the CMS and continu.

6. Fill some text in the Xinha field
7. Fill some text in another field
8. Press save
9. Wait for a few seconds
10. Go to Tamper Data and click for each popup 'submit'
11. Go to the CMS and see that not all filled in values are updated

The post requests after editing some field write to the JCR-session.
At the moment you press Save there is a (GET?) request making sure the JCR-session gets 'applied' to the documents so the content gets updated.

If a POST-request arrives at the server after the JCR-session got saved it will be written to the JCR-session but will not be shown in the CMS and is not in the content.

Using Tamper Data might seem unrealistic but packets on the internet do get their own route which can be slower than the next packet so I think it's the same problem occuring at the client.