Support of back button in content edition

Development
#1

Hi everyone,

I’m opening here a proposal so that we clarify the behaviour of using the browser Back button with page edition. This discussion started with @mflorea as part of https://jira.xwiki.org/browse/XWIKI-17658.

To sum up a bit the history:

  • we used to have before XWiki 11.2RC1 a behaviour such as when using the back button the edition form was keeping unchanged, displaying the browser cached content. It means that if you were editing a document and move to another page by mistake, you could use the back button and your changes were not lost
  • in XWiki 11.2RC1 we introduced the management of conflict edition (https://jira.xwiki.org/browse/XWIKI-6665): this mechanism works with a version of the page. Starting there we encountered the following problem when using the back button: the changes were not lost, but when using back button after a first save you were hitting a conflict (because the version was not reload when using back)
  • we fixed this “bug” in XWiki 11.3.1 / 11.4RC1 (https://jira.xwiki.org/browse/XWIKI-16343) by forcing a reload of the browser when the user uses the back button and the version changed in the meantime

Now @mflorea opened recently https://jira.xwiki.org/browse/XWIKI-17658 and I don’t see many solution to fix this so I’d like to check if we agree on one of them.

Right now I see 2 solutions:
Solution 1: We use the current solution, it means that whenever you use back button and the version changed the browser will be reloaded with latest version of the document, and the content you might have cached in browser will be lost. For me, this is an acceptable solution since:

  1. we have mechanism to protect against leaving the editor during the edition with a confirmation window to prevent about possible loss of data
  2. we are going towards more and more in-place editing so using the back button in the future for edition should be pretty rare

Solution 2: We revert all the changes I did for https://jira.xwiki.org/browse/XWIKI-16343, so basically we always retrieve the cached content from the browser, but we also always rely on the conflict detection mechanism. I performed a trial locally and right now something as simple as adding a line to the cached content (already saved) will trigger a conflict window (because of saving by using an old version). Maybe there’s some work to do to improve a bit the automatic merge there (personally I’m not even sure why it detects a conflict there, but I didn’t investigated much). But anyway, there will still be a high risk to introduce a conflict like that and so to hit the conflict window.

Please tell me what do you think on that subject, I tried to sum up there but you might find more details in the discussion we had with Marius on the comments of https://jira.xwiki.org/browse/XWIKI-17658.

#2

For me this is not acceptable, because:

  • you can still click on Cancel by mistake, or click Preview and then use the browser Back button to get back. Neither of these requires the leave confirmation.
  • this could take years. In-place editing works ATM only for plain wiki pages if the preferred editor is WYSIWYG. So there are still many ways in which you can loose unsaved content if the Back button doesn’t work as it should.

For me there’s only one solution: preserve unsaved content when using the Back button and don’t show a merge conflict on save if there’s no real conflict. I don’t see why one would exclude the other.

Moreover, it’s not clear to me why browser caching is an issue for merge conflict. There should be no difference between:

  • clicking Cancel and then Back
  • versus continue editing

because the Back button is supposed to restore the field values as they were before the Cancel button was clicked so you end up having the same state as if you didn’t Cancel but continued editing.

The issue is not about the Back button but rather about the soft page reload. The browser preserves unsaved content on soft page reload (as if you do Cancel and Back) and this is good. The problem is that the merge conflict relies on this soft reload (window.location.reload()) to refresh the document version. The hack you did was to change the behavior of soft page reload to drop the cache. You need to find a better / cleaner alternative. For instance instead of calling window.location.reload() you could maybe change the location by adding a timestamp in the query string as you do in https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-web/src/main/webapp/resources/js/xwiki/meta.js#L89 .

#3

Here you really need to provide a definition of a real conflict. For me a conflict happens whenever you’re trying to save a content with a version of a document while an higher version of the document already exist.

Clicking Cancel and then Back is not a problem. The problem is:

  • Starting an edition session from version 1.1 (what’s in the html)
  • Saving once -> bumped to version 1.2 but not stored in html
  • Canceling and then coming back -> the soft reload here led to use version 1.1 from html.

So maybe I can try indeed to change meta.js to force updating the html too when using setVersion.

#4

Actually it’s not working since here I’m changing the HTML using Javascript so the browser already cached it.

#5

For the record, I finally fixed by adding the version field in the DOM of the page (and not adding it dynamically in JS) which allows to cache it. It has been fixed as part of https://jira.xwiki.org/browse/XWIKI-17658. Thanks @mflorea for the help on that topic.