Uploaded image for project: 'Hippo CMS'
  1. Hippo CMS
  2. CMS-5596

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

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Top
    • Resolution: Fixed
    • Affects Version/s: 2.16.12, 2.20.01, 2.21.06
    • Component/s: None
    • Labels:
      None
    • Environment:
      Test demo (2.21.06-SNAPSHOT); live gogreen demo (2.20.01); also at a client (2.16.12)
    • Similar issues:

      Description

      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.

      Regards, Niels

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                jsheriff Junaidh Kadhar Sheriff
                Reporter:
                nout Niels Out
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: