Vaadin UI breaks if DOM window.name is set

Vaadin 6 / 7 / 8
1

I found out an interesting issue with the way vaadin determines if finds a UI. This behavior is dependent on the assumption that window.name in the DOM is not already set to non-empty string. If the window.name is already preset before vaadin is loaded, this pre-cludes correct UI loading especially in multiple tabs. Here is the test scenario

  2. Open a window with a vaadin app, whose window.name (in browser DOM) is preset to “abc”
  3. interact with the vaadin UI in window 1
  4. Open another window with the same vaadin app whose window name is also preset to “abc”
  5. Interact with vaadin UI in window 2
  6. Now switch tabs and interact with vaadin UI in window 1
  7. Vaadin will now throw the communication error alert in window 1

After substantial debugging the following is the root cause
Vaadin computes the embedId from the window name and app name. If window name is an empty string then vaadin generated a new DOM window name, otherwise it uses the preset window name.

  2. Open a window with a vaadin app, whose window name (in browser DOM) is preset to “abc”
    [list=1]
  3. In com.vaadin.server.VaadinSession.addUI(UI) new UI is added with an embedId of abc.-number
  4. No previous UI exists with the same embed id at this point

    [/list]
  5. interact with the vaadin UI in window 1 – events are processed as usual
  6. Open another window with the same vaadin app whose window name is also preset to “abc”
    [list=1]
  7. In com.vaadin.server.VaadinSession.addUI(UI) new UI is added with an embedId of abc.-number (same embed ID as step1.1)
  8. Previous UI (window 1) is found in the embedIdMap
  9. Call close on previousUI (window 1)
  10. This sets closing=true when finally com.vaadin.ui.UI.close() is called

    [/list]
  11. Interact with vaadin UI in window 2 – events are processed as usual since this UI is in good state
  12. Now switch tabs and interact with vaadin UI in window 1
    [list=1]
  13. At some point during request processing com.vaadin.server.VaadinService.cleanupSession(VaadinSession) is called which in turn calls com.vaadin.server.VaadinService.removeClosedUIs(VaadinSession)
  14. Since the window 1 UI closing flag is set to true, this is removed from the session
  15. In com.vaadin.server.communication.UidlRequestHandler.synchronizedHandleRequest(VaadinSession, VaadinRequest, VaadinResponse) UI is not found in session and UI Not found error is written response.getWriter().write(getUINotFoundErrorJSON(session.getService(), request));

    [/list]
  16. Vaadin will now throw the communication error alert in window

Currently using vaadin version 7.3.6
IMO the solution should be that vaadin not use standard DOM properties and rather create vaadin specific properties which has fewer chances of corruption.

2

Interesting; nice catch. I’ll create a ticket, although while this is certainly annoying behavior, it falls under ‘enhancement’ rather than ‘bug’. I’ll take this up with the rest of the Framework team, we might change the behavior in a suitable major release.

3


https://dev.vaadin.com/ticket/18583#ticket

4

Having had a word with the team, this behavior was deemed necessary to be able to support the PreserveOnRefresh feature - Window.name doesn’t change between reloads.
We’re considering alternatives.

5

Specifically, this seems to be a regression caused by the optimization implemented in
ticket 10338
 which eagerly cleans up the previous UI if it’s
not
 @PreserveOnRefresh and the page is reloaded. There should probably be a way to disable this.