In the JSF RestoreViewPhase implementation there are a couple of paths of execution. If the UIViewRoot is stored in the FacesContext implementation, that object is used and restoreView/createView are never called. If the request is deemed to be a postback, this UIViewRoot is used for the rest of the lifecycle.
If the request is not deemed to be a postback, the responseComplete flag is set in the facesContext. This will prevent any further processing being done on the lifecycle, including rendering. This is the nature of the problem. We have knowledge of what type of request is incoming and this allows us to clear the viewRoot instance from the FacesContext. Our use of the perisistent FacesContext is the root of the difficulty. We preserve some of its state if a non-faces request is used in a redirect, but we don't if the non-faces request is part of a page reload.
I've made some changes to the View and to the BridgeFacesContext, and am in the process of checking for regressions.
In the JSF RestoreViewPhase implementation there are a couple of paths of execution. If the UIViewRoot is stored in the FacesContext implementation, that object is used and restoreView/createView are never called. If the request is deemed to be a postback, this UIViewRoot is used for the rest of the lifecycle.
If the request is not deemed to be a postback, the responseComplete flag is set in the facesContext. This will prevent any further processing being done on the lifecycle, including rendering. This is the nature of the problem. We have knowledge of what type of request is incoming and this allows us to clear the viewRoot instance from the FacesContext. Our use of the perisistent FacesContext is the root of the difficulty. We preserve some of its state if a non-faces request is used in a redirect, but we don't if the non-faces request is part of a page reload.
I've made some changes to the View and to the BridgeFacesContext, and am in the process of checking for regressions.