[
https://issues.apache.org/jira/browse/EXTCDI-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093496#comment-13093496
]
Mark Struberg commented on EXTCDI-218:
--------------------------------------
A few ways to solve this:
1.) use the ClientSideWindowHandler: This is the only known fully functional
solution for windowId handling. The problem is that it leads to slight
flickering for the users (because an 'intermediate page' has to be rendered
which detects any fresh browser window and loads the real destination via
JavaScript)
2.) Instead of terminating @ViewAccessScoped immediately when a new viewId gets
detected we only 'defer' them and clean them up on the following request. If he
dropWindowId.js script detects a fresh browser window, it can pass the
originalWindowId=123 as parameter so we can 'rollback' the deferring. I know
that this is not an optimal solution but it would probably be the easiest way
to fix the behaviour.
3.) Implement a history for @ViewAccessScoped beans. This is something which we
thought about since a long time already. This would allow recovering on browser
back buttons.
> defer final deletion of @ViewAccessScoped beans
> -----------------------------------------------
>
> Key: EXTCDI-218
> URL: https://issues.apache.org/jira/browse/EXTCDI-218
> Project: MyFaces CODI
> Issue Type: New Feature
> Components: JEE-JSF12-Module, JEE-JSF20-Module
> Affects Versions: 1.0.1
> Reporter: Mark Struberg
> Assignee: Mark Struberg
>
> I have a tricky problem in production with @ViewAccessScoped beans in
> conjunction with the lazy windowId dropping script
> http://wiki.apache.org/myfaces/Drafts/WindowId
> The problem arises if the user is on the browsers tabA (windowId=123) which
> has a @ViewAccessScoped bean and opens a link from this window in a new tabB.
> In this case a request with the old windowId=123 (*) will be sent to the
> server and the response will be rendered to tabB. When the dropWindowId
> script detects that tabB is a fresh browser tab, it will issue a new request
> and drops the windowId to get a new one (windowId=124 now for tabB)
> The problem is that in step (*) we get a request with the _old_ windowId onto
> a new view, thus we drop the @ViewAccessScoped bean used in tabA.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
