UPDATE PART TWO
This issue has been distilled much further and appears to be with how Chrome handles triggering of the DOMContentLoaded event on navigation forward and backward when there are inline scripts. I’ve updated the bug report (Issue 151) with a very simple test case that demonstrates this.
Turns out it wasn’t related to forms after all. (My foot sure does taste pretty good.)
UPDATE!
Great news! The wonderful people up in Mountain View have reopened Issue 151 making this plea unnecessary. And one more thing, since I don’t feel I was clear enough about this, I want to make sure everyone knows that when the bug was closed it was a misunderstanding, not Google/Chrome willfully trying to break the web.
Thanks Google, thanks everybody else who looked at this in getting it the attention it needs.
The first thing I did when Google Chrome came out was to test its capabilities with regards to history management. As a new and theoretically highly capable browser I figured it would behave nicely and there would be no problems. Besides, it uses an up-to-date version of WebKit, which works just fine. Well, as you can probably guess by the fact that I’m writing this, it didn’t exactly work.
An Intro to the World of History Management
There are two basic problems a history manager has to solve. The first is to ensure the creation of a history state upon every page change and store relevant information to make it accessible. This is usually handled by changing the hash to create a history point and then, keying off of that hash, updating the page accordingly.
The second problem is to maintain the programmatic history states and their associated data across page requests. The low-level detail of what occurs on a page transition goes something like this: when I navigate from nathanhammond.com to google.com my window.document object changes. As a result of the document object change all JavaScript variables are lost and the new document is redrawn. That is completely expected (and specified) behavior. A load of a document object is always (and easily) replayable simply by re-requesting that document object.
The scenario is a bit different in a history managed web application. In that approach there is no change to the document object, only a change to the document content that we want to be replayable. To make it replayable the history manager needs to store some information about how to replay it and then, when that history state is invoked (by navigating through the browser history), respond accordingly. The problem with this is that we need maintain the information about how to replay it across document object changes since it does not involve a document object request.
Without the benefits of HTML5 client-side storage or Google Gears, the original solution to this problem was to store the history state in a textarea and rely upon an unspecified but entirely consistent browser behavior: the refilling of form fields even after document unload.
This functionality is easily demonstrable by following this process:
- Go to a page with a form on it and start filling it out.
- Navigate backward in your history.
- Navigate forward in your history to the page with the form you were filling out. You will find it filled with what you had entered.
Noticing a Problem
With all of that in mind, I began testing Chrome’s support of both Really Simple History and my own JSSM as they are the ones I’m most familiar with. As most browser history managers rely upon the same general functionality, this is rather good sample set.
I began by simply browsing around within my test site and making sure that all of the history worked correctly. Things were all looking fine and everything worked wonderfully. Then came the test where I navigated away from the site and returned to it only to find that values weren’t refilled in the form. This completely breaks Really Simple History and messes up the understanding of page request order in JSSM. I presume that because of Chrome’s aggressive garbage collection it does not implement this feature, but I’m unsure.
Filing a Bug
So, noting the issue, I filed Issue #151 on Chrome’s Google Code project. I called it a bug and after a few days it was assigned. Great, everything will now be correctly handled in Chrome and we can rest easily.
Mountain View, We Have a Problem
Well, after a few days more, this issue was closed as “wontfix,” terming it a feature request for autofill. Google Code didn’t notify me that it was updated and so I didn’t notice until during a presentation about Chrome at The AJAX Experience 2008. I was sitting right beside Brian Dillard at that point and we both took the opportunity to comment again on the issue to see if we could get it reopened. Since then there has been no further discussion.
I’m hoping to increase exposure for this issue to hopefully get it addressed in Chrome. If you would, please discuss this topic or link to this discussion on your own blogs to increase exposure. Also, if you’re so inclined you could comment on the issue directly.
I dont want test in more browsers, (opera, safari, ie6, ie7, ie8, firefox) now with chrome is more time to test.
@matt: google themselves tell you that testing in Safari should suffice, I’m not testing my individual pages in Chrome. My process is:
1) Write in Firefox, simply because of the developer tools.
2) Fix for ie6 and ie7.
3) Glance for huge errors in ie8 or Safari.
4) Ignore opera and chrome. If safari and firefox display it fine, then obviously something is wrong with opera or chrome if they don’t render it correctly.
As for the actual subject of the article, seems like a browser vendor didn’t implement things exactly the way you expected. But that behavior (although ingenious) has nothing to do with standards or how the web should work, your code was dependent on vendor-specific behavior. And does it even work on a secure site?
Steven, thanks for your thoughts. I find it unfortunate that this isn’t specified, but I personally believe that since this feature is universal amongst all other browsers (IE6, IE7, IE8, Opera 9.X, Safari 2, Safari 3, Safari 3 Win, Firefox, …) that it should be treated as a de facto standard.
Lastly, with their stated goal of not creating more incompatibility on the web, that it breaks any existing implementation is unacceptable as now there are sites on the web which do not function as intended.
And, to answer your question, the form-based approach does work in both secure and non-secure sites. The data is stored with regards to the document object, not the host protocol.