It is absolutely essential to wait until after the BHM has been
initialized to determine in which state a module is (using the
getCurrentState() method). This is because of the way the BHM works on
IE and because we thrived to offer a consistent interface to the
programmer on all browsers. The details are a bit complicated to explain
so I'll let you poke around in the code. Let me know if you have any
On Fri, 2007-06-01 at 19:48 +0000, lenzbd wrote:
> I have a question about possible differences (on load) between the
> bookmarked state of a module on load and the "current state" of a
> module after BHM initialization.
> From the docs re: the BHM's "onLoad" event:
> "One common task you'll find yourself executing in your Browser
> History Manager onLoad event handler is retrieving the current state
> of your module and updating its UI accordingly."
> I'm curious why you need to wait until after the BHM has initialized
> to determine this as opposed to just using getBookmarkedState to
> determine if the UI needs to be updated. I don't see any scenarios
> (in FF, IE, Safari) where this is necessary. The benefit of just
> using the bookmarked state and comparing it to the initial state of
> your page is that you can make immediate UI changes to the page
> without first waiting for the page to finish loading.
> For example, in my case, I'm using AJAX to update one section of the
> page. Upon browsing to another page and then using the back button to
> return to it, if I wait until after load to update the UI, then the
> initial state of the page will appear until the page has completed
> loading after which point I can update the page. This leads to a
> fairly jarring effect of causing the page contents to be displayed
> briefly, then disappear, and then the correct UI appears.
> immediately rather than wait for the onload event to be triggered.
> Am I missing something? Is there any reason (cross-browser
> compatibility issues, etc.) not to take this approach?