UriFragmentUtility and history

I have a problem. Trying to get back, forward and history working in my application. I’ve got it mostly working but there’s one problem.

In safari (Version 5.0.5 (6533.21.1)), Chrome (12.0.742.100) and IE (8.0.6001.18702) the history isn’t quite right. This is demonstrable on the Vaadin sampler. If you load the sampler and select “Push button”, then “Link button”, then “Checkbox” from the LHS list, then you click and hold the back button to see the last few pages you’ll notice if you select one of them it’ll take you to the one before. For example if you select “Link button” it’ll take you to “Push button”. I suspect this might be because the main window’s title is being updated before the URI fragment is updated.

Under Firefox (4.0.1) this is not the case.

Any ideas?

This sounds like a bug, please file a bug report.

That said - it
might
be hard to resolve the bug without refactoring how URI fragments are handled. This will be done in Vaadin 7, so it could be that we can not fix the bug before Vaadin 7.

Okay - thanks. Will do.

In the interim, I’m going to need to get this fixed to show my boss a full working application. I’m happy to do some coding and submit a patch/addon if that speeds things along… Any tips? :wink:

For anyone else that encountered this issue, I have developed a workaround I thought I would share.

In brief - the issue I observe is that when creating a new fragment, due to the timing of how events are replayed in the client, the title used for the history ends up being the NEW title instead of the PREVIOUS title. That is, if you are simultaneously changing the title of your Window and setting a new fragment (which would be the normal way to use it), the History created by Chrome (and maybe Safari - did not test) uses the NEW title instead of the previous.

I had tried changing the order in which I changed the Window’s caption vs. setting the fragment to no avail. Works fine in Firefox and IE but no luck in Chrome.

So the workaround is to override Window.setCaption as follows:


@Override
public void setCaption(String caption)
{
    if (getCaption() == null)
    {
        setCaption(caption);
    }
    else
    {
        int delay = 500;
        String js = "setTimeout(\"window.document.title = '" + caption + "';\", " + delay + ");";
        executeJavaScript(js);
    }
}

Caveats:

  1. Make sure that your code doesn’t call getCaption() to get the “real” (currently set) caption (title) of the Window. If you have logic that needs this, you probably want to create a pair of new methods for managing that (e.g. getTitle and setTitle).

  2. You probably want to add some String escaping to the incoming caption so that, if it contains single and double quotes, they’re escaped properly.

Enjoy!

Quick follow-up:


Chrome

Had to use the JavaScript trick above to get things to work.


Firefox

The JavaScript trick does not seem necessary for Firefox to work properly.


Internet Explorer

I could not get IE to work properly, either with or without the JavaScript trick.

So my code now ONLY applies the JavaScript trick if the browser is Chrome.

But it got me thinking, if I couldn’t get the history/title to sync up properly, the Vaadin Sampler would not work properly, either. Indeed, it does not.

If you open up the Vaadin Sampler in IE and start clicking around, take not of the URI fragment and browser title that gets added/set. After a few clicks, now press and hold the browser’s back button and you will see that the first “previous” page title is the same as the “current” page title.

Actually selecting that page will work properly, but the title of the pages displayed to the user are all off by one (see attached screenshot).

So my question to the folks at Vaadin is this: Being able to support the browser’s back button is such an important part of the user’s experience (particularly for internet-deployed consumer-facing apps), I am surprised that such an obvious bug continues to linger. (I know it is all rooted in IE being…, well, IE… but surely there is some GWT-level workaround that could be employed to take IE’s peculiarity into account.)

Could somebody from Vaadin first confirm that (a) this is, indeed, a known issue and (b) if there are any plans to address it.

Thanks in advance.
12349.png