The same happens in 1.5.3. Only when the standardRequestScope in web.xml is set to true,
the request scoped backing beans become finalized and reinstantiated when navigating between
different pages. This is to be expected default behaviour...

Are the navigation rules doing redirects? If forwards are used then no new requests are made, requests that will update the request parameters, thus the parameters used in the first request are reused to render next view.

That's correct. Using redirects in navigation rules cause the submitted values to be overwritten on each redirect to another page. When redirects are commented out and forwards are used instead the values will be reused.

this test case can be adjusted appropriately. when using redirects the values are null anytime a navigation rule is initiated.
when redirects are commented out, the textField's value will be stored in the bean property and then be set to null when navigating back to pageA. (standardRequestScope must be set to true then).

After taking a close look at what's going on I can say that the behavior is the correct one.

• Component level
  The submitted value acquired with HtmlInputText.getSubmittedValue() is null on page navigation from pageB to pageA because a new component tree is created (when using D2DFaceletViewHandler) thus HtmlInputText's 'submittedValue' field is initialized with the null value.

• Bean level
  When standardRequestScope=false the request is long lived, so even if the beans have request scope they are reused between Ajax requests and recreated only on full page requests such as page load, reload or redirect.
  So, in the attached test case com.icesoft.icefaces.samples.request.Request bean is instantiated only once when forwards are used and that's why we don't see it's 'stringOne' field reset.

'standardRequestScope' was specifically introduced for cases where applications require standard JSF behavior.

This issue is causing a lot of problems for many customers where adopting standard request scope is not a viable solution. We should consider clearing the old component tree ourselves when a page navigation event occurs.

Are the backing beans the same on the two different pages? The observed behaviour may have nothing to do with the state of the component tree.

The bean is the same on both pages

Since the bean is the same on both pages, this could be regarded as expected application behavior. In many cases, the ability to share data between pages is useful. In this case, the developer does not want to share data between pages, so perhaps the solution is to use distinctly named managed beans on the two different pages.

If the page is produced by JSP rather than Facelets, the submitted values may be retained in the component tree.
Since Facelets reproduces the component tree from the handlers each time, the two may behave differently.

Mircea, could you investigate a JSP case as well as the Facelets case?

Two potential fixes have been proposed:
1. clear out the submittedValues in the component tree for each request
2. regenerate the component for each request in JSP mode

2. is potentially higher risk because of the interaction with ICEfaces JSP parsing and may be better addressed when we adopt full JSP component tree generation, such as with JSF 1.2.

Fixed as a side-effect when fixing ICE-2189. Forward navigation rules now force a page reload which in turn re-creates the request map.

Stop propagating attributes between page reloads.

Re-opening as the fix for this causes backward-compatibility issues and must be reverted for the 1.7 release.

Need to replace the current extended Request scope with Std. Request scope behavior + a new scope.

The code area needing to be changed (ServletExternalContext.class) to fix this issue will reside in JSF 2.0.