The GWT history manager and the Safari/Opera question

Brian Dillard, Monday, December 10, 2007 @ 9:54 am

I took GWT's history manager for a spin last week courtesy of the Kitchen Sink Example Project. Overall I was impressed; it worked flawlessly in a range of up-to-date browsers and operating systems. Then I decided to give it a try in the two browsers that caused me the most pain with Really Simple History: Safari 2.x and Opera 9.2x. The history implementation in each browser is deeply buggy; I resorted to lots of user-agent-specific hackery to work around it. GWT apparently doesn't try.

In Safari 2.03 and 2.04, both of which RSH supports, GWT offers no back-button support. Hit a number of different history points in the kitchen sink app, then hit "back" and you'll end up on whatever site you were on before you got there. Things in Opera 9.2x fail less gracefully. History points get created, but the back button doesn't trigger GWT's history listener. So if you visit five different history points within a GWT application, you'll still have to hit your back button five times to get back to whatever site you were on before. Yet your application state doesn't change as the result of any of those back-button clicks.

Having profited from the hard work of other history-manager authors and spent countless hours on my own implementation, I know exactly why both of these problems are occurring. When you change the hash value of a URL in Safari 2.x, the only part of its history object that gets updated is history.length. If you don't key all of your history events and callbacks off the value of history.length, your history manager simply won't work. As for Opera 9.2x, hitting the back button completely blows away all JavaScript timers. You have to get creative in order to re-initialize your history-change polling. Luckily, Safari 2.x and Opera 9.2x are on their way out. GWT's history manager works as expected in Safari 3/Mac and Opera 9.5. (Safari 3/Windows is just as broken for GWT as it is for RSH; it's just too buggy to hack around.)

The question of browser support in Ajax libraries is an interesting one. To what extent should a library author feel obligated to fight the good fight against buggy browsers - especially niche ones? RSH 0.6 would be a good 20% smaller - and have taken about 60% less of my time to develop - if I had opted to support only the latest and greatest betas of Opera and Safari/Mac. I even have a half-implemented feature to return an isSupported boolean upon initialization of my library. I haven't gone further with that particular enhancement because once you go down the road of monitoring minor version numbers and changing your library to react to them, you've doomed yourself to constant maintenance. You've got to draw a line in the sand somewhere; GWT and RSH simply draw the line at different places.

Technorati Tags

• ajax
• javascript
• bookmarking
• GWT
• Really Simple History

agile ajax

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment