URI fragment handling changed in the last vaadin versions?

General
1

Hello,

we have upgraded our application to the latest vaadin version (6.8.3) and see that the URIFragmentHandling is behaving differently than before.

We have URL in this form:

http://localhost:8084/ckeditor-connector/servlet/ckeditorconnector/#FILEBROWSER/type/Images?CKEditor=Editor2&CKEditorFuncNum=96&langCode=fr

In the older vaadin versions we got #FILEBROWSER/type/Images?CKEditor=Editor2&CKEditorFuncNum=96&langCode=fr as the fragment.
With the new version (since 6.8.0?) we only get back /#FILEBROWSER/type/Images?CKEditor=Editor2 as the fragment, which then of course gives trouble in our application.

When I inspect the http request on the moment when it reaches the code (For example in a onRequestStart method) the fragment is stored in the fr parameter, and all the other stuff is also placed into it’s own request variables.

Is there a way to get the “currently” active URI as it is displayed in the browser address bar ?

André

2

We just upgraded from 6.8.2 to 6.8.3 and noticed that we’re also having trouble with our main login process which also goes to a URI fragment but it’s not firing.

On login under 6.8.3, I do end up with the URL in the browser showing as expected:

http://localhost/open-eSignFormsVaadin/vaadin/#WelcomeTipsView/Welcome

But that fragment is not fired and so no view is displayed. If I click on the view from our menu that is the default view, the same URL is shown, but the original welcome page is shown as expected. This is is because it then fires the fragment changed event.

When I roll back to 6.8.2, it works fine again, so this is definitely something introduced in 6.8.3.

When I look at my application logs, 6.8.2 shows these additional lines after login that are now missing in 6.8.3, which seems to be one extra request that does triggers my fragment code:

[font=Courier New]
2012-09-10 17:46:50,025 DEBUG (com.esignforms.open.vaadin.EsfVaadinApplication) onRequestStart() requestUrl: /open-eSignFormsVaadin/vaadin/UIDL?windowName=main; hostIp: 127.0.0.1; useragent: Mozilla/5.0 (Windows NT 6.1;
WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1; loggedInUser: Support David support@david.com

2012-09-10 17:46:50,026 DEBUG (com.esignforms.open.vaadin.main.MainWindow) fragmentChanged() - fragment: WelcomeTipsView/Welcome; viewName: WelcomeTipsView; viewParam: Welcome

2012-09-10 17:46:50,026 DEBUG (com.esignforms.open.vaadin.main.MainWindow) showView() - viewName: WelcomeTipsView; viewParam: Welcome

2012-09-10 17:46:50,034 DEBUG (com.esignforms.open.vaadin.EsfVaadinApplication) onRequestEnd()
[/font]

When I review the closed items for 6.8.3 I don’t see anything that jumps out at me as what would cause this.

UPDATED TO NOTE TICKET 8916:

Perhaps it’s
http://dev.vaadin.com/ticket/8916
 that has done this. Ticket 8916 isn’t shown in the
list of closed issues for the 6.8.3
, but I think it must be the reason since it talks about this feature directly.

3

The work arround for the moment is to implement HttpServletRequestListener in the application and then route the request to the correct window.

    public void onRequestStart(HttpServletRequest request, HttpServletResponse response) 
    {
        String initialFragment= request.getParameter("fr");  // Could be null.
        if (initialFragment != null)
        {
            _log.debug("Request fragment: "+initialFragment);
            // Detect target window
            String wName[]= request.getParameterValues("windowName");

In the first initial request (where the new url is called from outside a vaadi application the “fr” is null,
but the request has the full/correct url.

The second request then has a “fr” parameter, but has a url of UIDL.

4

Is the ‘fr’ parameter something you are putting on or does Vaadin include it automatically? In our web server activity log I see the windowName param, so if there is a ‘fr’ param it must be part of the POST data rather than on the URL as we just show:
[font=Courier New]

POST /demo/vaadin/UIDL?windowName=main
[/font]

We’ve just rolled back to 6.8.2 for now since it seems odd that we’d need to make source code logic changes to handle a point release update. Hoping there’s a fix or something more official to speak about this.

Our MainWindow adds a UriFragmentUtility to the layout and implements the listener fragmentChanged() method. If I set a breakpoint in fragmentChanged(), it’s not called on login under 6.8.3, but is called as expected under 6.8.2 (and all prior releases). Somehow, the update fixed it so that we never get that first fragment changed event even though on login (from a JSP page, outside of Vaadin) we redirect to Vaadin with a fragment specified. The resulting Vaadin page shows the fragment in the browser location bar, so it’s making it through to Vaadin just fine.

And when I review the ticket, I’ve never seen the bug it suggests it is fixing, though someone must have seen it.

5

I did a quick test, and you are right that the ‘fr’ param has the fragment string. It’s interesting to note that the fragment is set as expected in ‘fr’, but it’s never fired in the fragment change listener.

6

It’s from here:

https://vaadin.com/forum/-/message_boards/view_message/943605?_19_delta=20&_19_keywords=&_19_advancedSearch=false&_19_andOperator=true&cur=1

I think someone (you?) should open a bug for this.

André

7

Sure, I’ve opened
ticket 9558
. We’ll see how that turns out since I’d hope the behavior would not change in a point release update like this. But as you point out, there’s a workaround if indeed it will not be resolved quickly.