To fully describe what is going on, assume something like the following security constraint declaration taken from the client's test case:
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/jsp/login.jsp</form-login-page>
<form-error-page>/jsp/login.jsp</form-error-page>
</form-login-config>
</login-config>
<security-constraint>
<display-name>UsersConstraint</display-name>
<web-resource-collection>
<web-resource-name>Resources</web-resource-name>
<url-pattern>*.html</url-pattern>
<url-pattern>*.jsp</url-pattern>
<url-pattern>*.jspx</url-pattern>
<url-pattern>*.iface</url-pattern>
<url-pattern>/block/*</url-pattern>
<url-pattern>/xmlhttp/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<description>
Authorisation constraint for User roles
</description>
<role-name>Users</role-name>
</auth-constraint>
</security-constraint>
<security-role>
<description>
General role for the application users
</description>
<role-name>Users</role-name>
</security-role>
1) If you try to access a secured resource in the application using form-based security, you are first routed to the specified login page to enter your security credentials. .
2) Assuming valid credentials are supplied, the container redirects you to the originally specified resource (the URL of the secured resource that was originally requested is "remembered" by the container).
3) The credentials are stored in the session so as long as the session is active, you can access the resources that you have access to.
4) When the session expires, so do the security credentials stored in the session so the container intercepts the next request to the secured resource (just like in step 1) and remembers it, but redirects you to the login page to request credentials again.
5) Assuming valid credentials are supplied, the container redirects you to the secured resource that was initially requested (and remembered by the container).
Between 4 and 5 is where the problem occurs because, with ICEfaces, the request that is remembered by the container is an Ajax request - in this case, dispose-views as the page unloads. It's further complicated by the fact that, with security enabled, the container doesn't pass on the requests when it intercepts them (Tomcat, WebSphere, whatever).
If you adjust the security constraints so that /block requests are not secured, then dispose-views will not be intercepted and remembered (which could be a security issue I suppose). However, the next response that comes back is the <session-expired/> message which kills the bridge. If you have set the context parameter for that result, it will redirect to that page but that may not be what you want.
Adding reference to SalesForce case.
I've modified the test case so that it runs on Tomcat and I can replicate the behaviour there to help make it a bit easier to debug.