I'm reading this google guide and using this sample code provided by google, but there's a glitch: using the back/forth buttons makes the URL change before the confirmation dialog has returned. This means that if the user decides not to navigate away, the URL no longer represents the current Place.
Anyone have a solution or workaround? Ideally, the URL would not change until the confirmation is given, but even just switching the URL back in a hurry after a denial would be better.
There's no workaround. Your app somehow detects that the URL has changed, which triggers the place change (thus before navigation is confirmed).
And there's no way to know why the URL changed; was it a "back"? a "forth"? a "back" using the history menu to go several steps back at a time? a bookmark? manual editing of the URL? So there's no way you could do a History.next() to "cancel" the URL change in all cases (also note that it would trigger another place change). And trying to modify the URL with anything else than History.back/next/go would erase the forward history, which you probably don't want either.
FYI, I implemented that behavior 2 years ago in my own "place manager", and talked about it with Ray Ryan when he added the PlaceHistoryHandler to GWT 2.1, and we agreed that there was no better behavior than letting the URL no longer being in sync with the place. FYI, when I studied the thing 2 years ago, and then earlier this year, GMail had the same behavior (create a draft message and navigate while the draft has unsaved changes).
来源：https://stackoverflow.com/questions/4331060/gwt-2-1-place-activity-technique-glitch-url-changes-before-navigation-is-confir