Question

What the problem is :
What happens when clicking on the browser back button –> opens up a page whose viewscoped-managedbean is already destroyed –> submit a request from a commandButton from that page with grid-record-selections ?

What i expect :
The associated viewscope-managebean is re-created, receives the grid-record-selections, and deal with them as if the browser back button is never involved.

What i experience :
The associated viewscope-managebean is NOT re-created, doesnt receive the grid-record-selections. Have to reenter the URL, or F5 after clicking on the browser-back button for it to work properly again.

So here’s the success scenario, all beans are viewscoped beans :

1. GET page1.xhtml –> page1Bean created, querying data, etc in @PostConstruct
2. check/select several records from a datatable, click on process button
3. page1Bean’s process method stores the selected records in the flash object, and redirect to the page2.xhtml
4. page1Bean destroyed, page2Bean created, and in preRenderView listener method, fetches the selected records from the flash object, and deal with them
5. click the “go to main page” commandButton to redirect to page1.xhtml, and page2Bean destroyed, page1Bean created again
6. loop from no 2 – 5 is still doable

Now, this is the errornous scenario involving the browser back button (different stuffs happening starting from #6) :

1. GET page1.xhtml –> page1Bean created, querying data, etc in @PostConstruct
2. check/select several records from a datatable, click on process button
3. page1Bean’s process method stores the selected records in the flash object, and redirect to the page2.xhtml
4. page1Bean destroyed, page2Bean created, and in preRenderView listener method, fetches the selected records from the flash object, and deal with them
5. click the browser back button page2Bean is not destroyed, page1Bean is not created
6. check/select several records from a datatable, click on process button
7. the page1Bean method executes (strange, because the page1Bean should’ve been destroyed), but cannot see the record-selections made, and redirect to page2.xhtml
8. page1Bean is not destroyed (no logging output), page2Bean is not created (since it’s not been destroyed), executes the preRenderView listener as usual, but this time, no selected records in the flash object

Is it possible to have the normal experience (as if without the browser back button) with viewscope-beans with the browser back button ?

Here’s my dependency :

<dependency>
    <groupId>org.glassfish</groupId>
    <artifactId>javax.faces</artifactId>
    <version>2.1.3</version>
    <scope>compile</scope>
</dependency>

Please share your ideas !

Answer 1

The browser seems to have served the page from its cache instead of sending a fullworthy HTTP GET request to the server, while you have JSF state saving method set to server (which is the default).

There are 2 ways to solve this problem:

1. Tell the browser to not cache the dynamic JSF pages. You can do this with help of a filter.

   @Override
   public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
       HttpServletRequest req = (HttpServletRequest) request;
       HttpServletResponse res = (HttpServletResponse) response;
   
       if (!req.getRequestURI().startsWith(req.getContextPath() + ResourceHandler.RESOURCE_IDENTIFIER)) { // Skip JSF resources (CSS/JS/Images/etc)
           res.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
           res.setHeader("Pragma", "no-cache"); // HTTP 1.0.
           res.setDateHeader("Expires", 0); // Proxies.
       }
   
       chain.doFilter(request, response);
   }
   

   Map the filter on the FacesServlet or its same URL-pattern.

2. Set the JSF state saving method to client, so that the entire view state is stored in a hidden field of the form instead of in the session in the server side.

   <context-param>
       <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
       <param-value>client</param-value>
   </context-param>
   

The filter way is preferable.