Really Simple History: Progress on title updates

Brian Dillard, Monday, December 17, 2007 @ 11:19 am

A week after wondering whether title updates were worth the trouble in Really Simple History, I'm reconsidering my opinion. It turns out a couple of users had already tackled this problem and come up with some solutions to the worst issues. (That will teach me to post about RSH without keeping up to date on my own Google Group and issue tracker.) At this point I have Firefox, IE and Safari working. Opera is proving to be a bigger challenge.

My original problem was that when a user clicks the back button to
land on a previous history point, RSH can't update the document title
until the history change is already complete. That means the browser's
history entry for the new hash gets set to the document title that
matches the previous hash. The trick - as pointed out in the comments here
- is to simply reload the current hash after the title change is
complete each time a history callback gets triggered. That causes the
browser history stack to replace the incorrect title with the correct
one. This seems to do the trick in Safari and Firefox. The code looks
like this:

//Code here sets var winTitle to the correct title

/*Now change the DOM*/

document.title = winTitle;

/*Change it in the iframe, too, for IE*/

if (this.isIE) {
    this.iframe.contentWindow.document.title = winTitle;
}

/*If non-IE, reload the hash so the new title "sticks" in the browser history object*/
if (!this.isIE) {
    var hash = decodeURIComponent(document.location.hash);
    if (hash != "") {
        var encodedHash = encodeURIComponent(this.removeHash(hash));
        document.location.hash = encodedHash;
    }
}

As
for IE, its history mechanism is a little different. History events are
keyed off of programmatic manipulation of an iframe. As a user of our
Google Group pointed out here,
all you have to do is keep the iframe's title in sync with the main
window's title. It takes a single line of JavaScript in the blank.html
file and a matching one in the code quoted above. That's right, IE
actually requires less work here than Firefox!

The real problem child is Opera, which doesn't behave as expected
when the current hash gets reloaded. The URL hash fragment is literally
being replaced by the exact same value, but Opera doesn't see it that
way; it acts as if the hash values are different and creates a second
history entry for the exact same URL. The result is that it takes two
clicks of the back or forward button to change application state. I'm
still looking for a workaround on this issue; if worse comes to worse,
title-change requests will simply get ignored in Opera.

At any rate, one edge case is cropping up even in the browsers that
do work. This is the same edge case that stumps a lot of RSH newbies -
including myself, when I first used Brad Neuberg's original version a
couple of years ago. That's the issue of how to handle a hashless
application URL. With any RSH application, the minute you start
creating history points, each one is associated with a unique hash
value in the URL (the part after the "#"). But many users will enter
the application at the root document URL, which has no hash. RSH
doesn't currently offer a graceful way to create a default application
state; it recognizes no history point associated with the absence of a
hash. This forces application developers to handle this case in their
own code, and often they choose to programmatically create a default
hash when the page initially loads. This can result in one of two
problems, depending on how the default hash gets set:

1. When users click the back button to get back to the hashless
   application state, the application immediately moves them forward to
   the first hash. The problem of circular URL redirection has been around
   as long as meta refreshes, but it's still annoying.
2. When users click the back button to get back to the hashless state,
   the application does nothing. It simply retains whatever state it had
   with the previous hash value. Again, this runs counter to user
   expectations.

Regardless of which scenario occurs, title changes complicate the
issue. If the application author is manually creating a default history
point outside the normal mechanism, then it's hard for RSH to properly
coordinate title changes for that history point. You could end up with
some mismatches between browser title and actual application state. As
you can see from the code above, RSH can't reload just the hash value
if there is no hash value. Setting a blank hash to a string causes the
equivalent of reload, which opens up a whole separate can of worms.
That's why the code carefully handles a hash value of "".

Ideas, anyone?

Technorati Tags

• ajax
• javascript
• bookmarking
• Really Simple History

agile ajax

Comments

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

None so far.

Leave a comment