It should be possible to create new windows on fly to new URL:s

[Joonas Lehtinen]

Toolkit must support following case:

Each time the applications url is accessed a new window is drawn. New windows (if not the first one aka main window) are forwarded to an unique uri so that reloads are possible.

Test case in trunk in tests.tickets package.

Old description: ~Try out the #1970 test with the following modification: ~

  public Window getWindow(String name) {

        // If we already have the requested window, use it
        Window w = super.getWindow(name);
        if (w == null) {

            // If no window found, create it
            w = createExtraWindow(name);
            w.open(new ExternalResource(w.getURL()));
        }
        return w;
    }

~This results to infinite loop instead of changing the url. ~

[Joonas Lehtinen]

turns out that this was a client-side bug. Will commit fix as soon as I get back to office.

[Joonas Lehtinen]

Fixed in [5520]

[Marko Gronroos]

Included in 5.2.10 release.

[Matti Tahvonen]

The code in description don't work anymore since [6480].

To me it looks like it even shouldn't. What happens when user navigates for url APPURL/foo/bar/ is:

1. Browser requests APPURL/foo/bar/
2. Server gets application from session
3. Server tries to find window and calls getWindow("foo");
4. getWindow cannot find previous window with that name and returns new window that has a pending request to forward to url APPURL/foo/bar/
5. windows uriHandler is called with value "bar/"
6. application initialization page is drawn
7. first UIDL request is done for created Window (window name is in init page), containing instructions to forward to url APPURL/foo/bar/ (where it actually is already)
8. Client side engine forwards to uri APPURL/foo/bar/ , practically making a refresh
9. On window unload event, client side notifies server that window is closed
10. event handler in server reacts to window close event and removes window from application (see source)
11. browser request url APPURL/foo/bar/ in practically same state as in step 1. making an eternal loop

Feature described in summary can be built with following code (same as in description, but without any Window.open() calls)

  public Window getWindow(String name) {

        // If we already have the requested window, use it
        Window w = super.getWindow(name);
        if (w == null) {

            // If no window found, create it
            w = createExtraWindow(name);
        }
        return w;
    }

Damn! Finally noticed that there seems to be Ticket2117 too which is totally different than Ticket1970 although stated so in description. It has no window close listener. So this comment is only for case in description which probably has never worked.

[Matti Tahvonen]

I think I didn't fully get the idea of the ticket by the limited description in the previous comment at all.

Modified the description not to make the same mistake again. Please always take care of decent description if (most often) summary don't fully describe the issue. Bad tickets will waste our time a lot in the future when trying to find regressions after changes.