Problems with PlaceChangeRequestEvent.setWarning

[R.K.P. Pisters]

Hi all,

I'm having trouble using the PlaceChangeRequestEvent.setWarning
method. I'm trying to implement functionality that is supposed to warn
a user about unsaved changes upon a requested place change. This is
the code I'm using:

eventBus.addHandler(PlaceChangeRequestEvent.TYPE, new
PlaceChangeRequestEvent.Handler() {

@Override
public void onPlaceChangeRequest(PlaceChangeRequestEvent event) {
if (hasUnsavedChanges()) {
event.setWarning(getUnsavedChangesWarning());
}
}
});

The warning dialog box pops up fine, and upon clicking "cancel" (in
order to prevent the place change), the application indeed doesn't
navigate to the new place. However, the url in the browser's address
bar does display the new history token, as if the place *was* changed.
In fact, I already see the new token in the url before I've even
clicked either of the buttons in the dialog box. This leaves the
application in an inconsistent state: the url does not match the place
I'm seeing. Subsequent requests of the same place change have no
effect anymore.

Is this functionality broken, or am I doing something wrong? I'm using
GWT 2.4 and have tested this in Chrome15, FF7 and IE9. The problem is
not restricted to hosted mode.

Any help would be greatly appreciated.

Thanks,
Ralf

[Thomas Broyer]

There's no way to prevent navigation to a "hash" in a browser (there's no equivalent to onbeforeunload for onhashchange; there isn't for pushState/onpopstate either) so if you navigated using History.newItem() or your browser's history, there's no way you can prevent the URL to change.

You should code your app using PlaceController.goTo() for navigation (which means replacing all your Hyperlinks, if any, with Anchors+ClickHandlers), which will then call History.newItem() (and thus update the URL) only if the navigation is not cancelled by the user.

[R.K.P. Pisters]

Thanks for you answer, Thomas. It was indeed a Hyperlink that was
causing my problem. I changed it to an Anchor and it's working fine
now. I could imagine the PlaceChangeRequestEvent javadoc mentioning
these specifics to prevent users from going down the wrong path.
Anyway, it works, thanks again.

[R.K.P. Pisters]

Just in case somebody else runs into this problem as well, let me, for
completeness' sake, add that you do need to prevent the anchor's
default action by calling event.preventDefault() in your
Anchor.onClick(ClickEvent event) method. Otherwise IE will reload the
entire app.

[Jens]

Hehe yeah there is an issue for it on the issue tracker. I have used GWT's super source feature to replace GWT's Anchor with a fixed version that does call event.preventDefault() by default for javascript:; links (similar to what HyperLink does). That way you don't have to call it yourself in each onClick() method.

http://code.google.com/p/google-web-toolkit/issues/detail?id=5280

-- J.

[Thomas Broyer]

Why the hell would you want to use an <a href="javascript:;"> ?! If it's not a link, use a Label or InlineLabel instead (or a Button), and if it's a link, then give it a proper href=""! (PlaceHistoryMapper comes in useful)

[Jens]

Why the hell would I want to use a Button and restyle it to an anchor if GWT already provides an Anchor class with the correct style and which has three constructors which state they can be used for scripted anchors (= using the default javascript:; href with the expectation of adding click handlers to them)? If GWT provides an Anchor class with these constructors people are using it if they want a anchor styled text with click handler support, so I don't see why to tell them to use a different widget which they have to restyle. Its just a different opinion and I would just add a small fix to the Anchor class.

Also using a Label or InlineLabel isn't a real choice as both are not FocusWidgets so you cant tab through them for keyboard navigation. But thats just an additional small reason because I think currently you cant activate a focused Anchor via the keyboard and you have to implement it yourself. But maybe that would be a nice feature for the Anchor class, e.g. hitting enter opens the focused Anchor.

-- J.