Amongst the reactions to Google’s release of Chrome was the developer’s howl of pain at the thought of another major browser on which to do compatibility testing. Google’s generally asserts that Safari compatibility results should be the same as Chrome’s, but Nathan Hammond stumbled across a divergence that he finds troubling and which Google shows no inclination to fix. Says Nathan:

There exists a bug in Google Chrome that breaks most history managers. Most all current historymanagers rely upon form-based storage to repopulate their history stack after navigating away from and returning to the present document object, but Chrome doesn’t refill form fields when that happens. The result of that is that Google Chrome is currently incompatible with websites using the current generation of history management plugins, and, if their issue tracker has anything to say about it, will remain that way. The bug was closed as “wontfix” due to a misunderstanding. However, it still needs to be addressed to meet the goal of Chrome as I heard at The Ajax Experience 2008: a goal of not fracturing the web and creating yet another browser we developers have to test in and code around.

I can’t reproduce this bug. I type a comment here in the comment box. Press my homepage button. Then click the browser back button and my half typed comment is still here. Then I click back and then click forward and my comment is still here.

@Jordan1
From further testing it appears that user-entered input may work. I provided that scenario in my blog post primarily to demonstrate the functionality I’m looking for. That it at leaast supports the functionality to that degree gives me hope that it will be a simple fix. However, in my simple test case for JSSM you can note a difference between the results for Firefox and Chrome. (Testing procedure: navigate a few jages within the site, navigate away, return to site.)

@zbuffered
My understanding of the reason YUI works is because it stores the whole of the history state in the hash (as does ASP.NET Ajax). As each of the history states is correctly associated to a history point in Chrome the problems only lie with trying to store additional information that you do not wish to place in the location bar. That is a functionality that (to my knowledge) exists only in RSH right now, and closely imitates the HTML 5 History Spec’spushState(). In fact, it is a functionality we’ll be relying upon to implement a HTML 5 History shim to enable old browsers to use the same interface as future browsers that do support it.

In general, that it breaks any existing implementation is unacceptable as now there are sites on the web which do not function as intended. However, there is light at the end of the tunnel, maybe. The whole reason I wanted this to appear here was to get it the attention it needs.

@lnostdal
The concern I have most specifically is that in this one particular instance the bug has not been been acknowledged and closed as “wontfix.” That is why I’m differentiating between this bug and and the other myriad bugs in Chrome which will all (hopefully) be addressed in time.

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.