How to Detect Back Button Event

[Joseph Lust]

I've been using a HistoryStack implementation attached to History.addValueChangeListener() in my app. This works well, but it's not truly a "stack" of Places.

If it were a true history stack, when a user hit back, then I'd pop off that Place and it would no longer be on the stack. However, History.addValueChangeListener() does not tell us whether the user went back, only the string of the Place that is now loaded. We could simply match this to the N-1 entry on the stack and remove the N (top) entry if they matched, but this makes assumptions.

As designed, we cannot differentiate between the following two user flows:

1. Place A -> (click link) Place B -> (link clicked) Place A

2. Place A-> (click link) Place B -> (back button) Place A

So the user could have made a cycle in our Place graph, or they could have just hit back. In the first case the stack would be [A,B,A] in the second case it should be [A].

I've also looked at the Window.onpopstate event, but the object returned only shows the new state, not the transition that got us there. Since it's triggered by Back AND Forward actions, you don't know which it was. It seems wrongly named as Forward is not popping off the history state stack, unless you consider the forward stack as being reduced, but then every action is a pop and a concomitant push.

So, how do other GWT'er determine when a user clicks the back button? Thanks.

Sincerely,

Joseph

[Thomas Broyer]

Embrace the Web!

…and stop trying to detect what's not detectable.

That being said, using pushState/onpopstate, I suppose you could add a timestamp to your state so you know when the state was initially pushed; but then you'd better store the real information you need in that state. There's a reason there's a state distinct form the URL, it's meant to store, well, state that's not to be "serialized" in the URL; but beware, you cannot update that state without erasing the forward history!

In the case of the Chrome Web Store for instance, they might use the state to store what needs to be displayed "in the background" when you're viewing an app/extension, given that they're shown as modals; but notice that closing the modal dialog doesn't navigates back in the history, it only pushes a new item (that's the same as the one before you clicked the app, i.e. the one that could be stored in the "state" to tell where to go when you close the popup).

[Joseph Lust]

Thanks Thomas.

I do embrace the web! The irony is simply that the browser has such a state stack that we're free to see in the History list (forward/back), but it stuck me as odd that the client code cannot reliably divine it. Obviously page are meant to be stateless beyond their serialized URL per the web's design.

You've confirmed my suspicions.

Sincerely,

Joseph