Button detaches unexpectedly, perhaps from PUSH issue?

Vaadin 6 / 7 / 8
1

We have a deployment where a given report fails because it includes a PopupButton in which we store some ‘auth codes’ used to retrieve data when items are clicked. The auth codes are generated and stored in the session when the button is created (so a servlet can process the request to retrieve data only if authorized by the report), and then when the button is detached, we remove the auth codes from the session.

Running Vaadin 7.7.9 on Tomcat 8.0.35. We believe the deployment user is running IE11. We have automatic pushmode with no transport specification, and it works for most. But this user is inside their corporate network, so we suspect it could be a communications issue. We tried updating PUSH to just use long-polling in case websockets were an issue, but that didn’t solve anything. We finally put in debug code to produce a stack trace when the button is detached and that’s below.

Why would a button detach from a view on its own? When we run our tests, we see it attached on the view creation, and detach only when the view is closed. We can’t make it detach in any other way. And it doesn’t seem that the entire session is lost because the user is still considered to be logged in and can do other interactions with the UI after the button is unexpected detached.

Here’s where the detach is taking place now:

TranSnapshotsDownloadPopupButton stacktrace
        at com.esignforms.open.vaadin.widget.TranSnapshotsDownloadPopupButton.detach(TranSnapshotsDownloadPopupButton.java:317)
        at com.vaadin.ui.AbstractComponent.setParent(AbstractComponent.java:579)
        at com.vaadin.ui.Table.unregisterComponent(Table.java:2549)
        at com.vaadin.ui.Table.unregisterPropertiesAndComponents(Table.java:2515)
        at com.vaadin.ui.Table.getVisibleCellsNoCache(Table.java:2271)
        at com.vaadin.ui.Table.refreshRenderedCells(Table.java:1747)
        at com.vaadin.ui.Table.enableContentRefreshing(Table.java:3277)
        at com.vaadin.ui.Table.changeVariables(Table.java:3119)
        at com.vaadin.server.communication.ServerRpcHandler.changeVariables(ServerRpcHandler.java:616)
        at com.vaadin.server.communication.ServerRpcHandler.handleInvocation(ServerRpcHandler.java:463)
        at com.vaadin.server.communication.ServerRpcHandler.handleInvocations(ServerRpcHandler.java:406)
        at com.vaadin.server.communication.ServerRpcHandler.handleRpc(ServerRpcHandler.java:273)
        at com.vaadin.server.communication.PushHandler$2.run(PushHandler.java:148)
        at com.vaadin.server.communication.PushHandler.callWithUi(PushHandler.java:240)
        at com.vaadin.server.communication.PushHandler.onMessage(PushHandler.java:494)
        at com.vaadin.server.communication.PushAtmosphereHandler.onMessage(PushAtmosphereHandler.java:87)
        at com.vaadin.server.communication.PushAtmosphereHandler.onRequest(PushAtmosphereHandler.java:77)
        at org.atmosphere.cpr.AsynchronousProcessor.action(AsynchronousProcessor.java:199)
        at org.atmosphere.cpr.AsynchronousProcessor.suspended(AsynchronousProcessor.java:107)
        at org.atmosphere.container.Servlet30CometSupport.service(Servlet30CometSupport.java:66)
        at org.atmosphere.cpr.AtmosphereFramework.doCometSupport(AtmosphereFramework.java:2075)
        at org.atmosphere.websocket.DefaultWebSocketProcessor.dispatch(DefaultWebSocketProcessor.java:571)
        at org.atmosphere.websocket.DefaultWebSocketProcessor$3.run(DefaultWebSocketProcessor.java:333)
        at org.atmosphere.util.VoidExecutorService.execute(VoidExecutorService.java:101)
        at org.atmosphere.websocket.DefaultWebSocketProcessor.dispatch(DefaultWebSocketProcessor.java:328)
        at org.atmosphere.websocket.DefaultWebSocketProcessor.invokeWebSocketProtocol(DefaultWebSocketProcessor.java:425)
        at org.atmosphere.container.JSR356Endpoint$1.onMessage(JSR356Endpoint.java:214)
        at org.atmosphere.container.JSR356Endpoint$1.onMessage(JSR356Endpoint.java:211)
        at org.apache.tomcat.websocket.WsFrameBase.sendMessageText(WsFrameBase.java:399)
        at org.apache.tomcat.websocket.WsFrameBase.processDataText(WsFrameBase.java:500)
        at org.apache.tomcat.websocket.WsFrameBase.processData(WsFrameBase.java:295)
        at org.apache.tomcat.websocket.WsFrameBase.processInputBuffer(WsFrameBase.java:131)
        at org.apache.tomcat.websocket.server.WsFrameServer.onDataAvailable(WsFrameServer.java:71)
        at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsReadListener.onDataAvailable(WsHttpUpgradeHandler.java:185)
        at org.apache.coyote.http11.upgrade.AbstractServletInputStream.onDataAvailable(AbstractServletInputStream.java:198)
        at org.apache.coyote.http11.upgrade.AbstractProcessor.upgradeDispatch(AbstractProcessor.java:96)
        at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:647)
        at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1520)
        at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1476)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
        at java.lang.Thread.run(Thread.java:745)
2

In our tests, we can see that when the popup button is removed on purpose (closing the view), the stack trace includes our code that shows the views going away. In the above, it all appears to trigger without touching any of our code, hence our belief that push may be the issue, but unsure what push would be doing that would cause the popup button to detach on its own with the Table.

3

We disabled PUSH entirely and the problem persists. Is there anybody out there who might have a clue as to why an IE11 browser (the user claims they’ve tried other browsers and PCs to help discount it’s a particular setup issue) would have this issue? For some reason, the client’s browser it sending something to the Vaadin core that causes the table to redo itself and detach our buttons (yet the buttons are still present in the view)…perhaps reattaching to make that happen, but we’ve lost the session info.

Is it normal for widgets to attach/detach under circumstances other than we’ve destroyed the widget or view containing the widget? Perhaps we need to note that we’ve previously been attached, so store what we need in case we’re mysteriously detached and then re-attached?

4

Well, we seem to have resolved this by noting that widgets can be detached and attached apparently “at whim” (entirely under the control of the Vaadin UI without our making an Vaadin API calls). By restructing our code to no longer assume a detach was the widget going away for good, we have resolved this problem ourselves