Browser back button handling improvements

A really cool thing about Orbeon Forms is that it automatically handles your browser's back and forward buttons.

What are we talking about here? Browser back and forward buttons should just work, right? Well, not quite, at least not with web applications that dynamically modify the HTML page.

What happens when you navigate back and forth in your browser history (typically with back and forward buttons) is that the browser attempts to reload the page (if possible from a local cache, following the usual HTTP caching mechanisms). It also restores form field values. But one thing it doesn't do all the time is restore the DOM as it was when you left the page. Opera, Firefox and Safari attempt to handle this in some cases, but not all. IE doesn't even try. This means you can't trust browsers to do the right thing.

Changes to the DOM happen very often with Orbeon Forms: when you make a field invalid, hide or show parts of the page, insert new rows of data, show a dialog, etc.

So Orbeon Forms tries to be smart: when you navigate the browser history to an Orbeon Forms page, if the browser doesn't restore the DOM itself, Orbeon Forms discretely talks to the Ajax server to ask it to send back a list of changes which, when applied to the page, would restore its appearance as you last saw it.

A nice thing is that we can do this at little cost because, as part of the regular XForms processing, we already:

• produce and store a serialized, encoded version of the state of the page, and

• use a difference engine to compute changes to apply to the page in your web browser

The news is that we made some enhancements to this feature:

• We fixed a long-standing bug, whereby going back to a page which loaded instance data using <xforms:instance src="input:data"/> or <xforms:instance src="input:instance"/> would throw an exception, because the XForms engine was unable to reload these instances.

• At the same time, we now make sure that all instances loaded during XForms initialization, whether with <xforms:instance src="..."/> or with a submission upon xforms-ready, are restored as they were initially (rather than by loading them again or executing submissions again).

• Finally, the recent addition of a disk-based cache makes the feature much more robust: as long as your session is alive, the initial state of the page will be found.

As a side note, this should finally allow us to implement <xforms:reset> correctly.