Vanish input data after triggering an immediate command

[he-bio]

Describe the bug

With JSF 2.3.17 an immediate command let vanish all input data of a "form" which has no bindings. This happened only with: PARTIAL_STATE_SAVING == false

With JSF 2.3.15 this is not the case, all data will be displayed after triggering an immediate command.

Is this a bug or expected behavior when PARTIAL_STATE_SAVING == false?

To Reproduce

Steps to reproduce the behavior:

1. see attached test project which was created under the mojarra servlet40 tests package: mojarra-2.3.17-immediateCommand-test.zip
2. tested on Glassfish 5.0 with JSF 2.3.17 and 2.3.15

Expected behavior

After triggering an immediate command all input data of a "form" are still visible. The render response phase don't let the data vanish.

Screenshots

[miguelzapaton]

+1

2.3.17 breaks my application. The state of all form fields is lost when validation fails.

2.3.16 still works perfectly.

[BalusC]

With JSF 2.3.17 an immediate command let vanish all input data of a "form" which has no bindings

Reproduced. This is the smallest possible reproducer:

<h:form>
    <h:inputText />
    <h:commandButton immediate="true" />
</h:form>

1. Set PSS to false.
2. Fill something in the input field.
3. Click the command button.
4. Expectation: input value is redisplayed; Actual: input value disappears.

2.3.17 breaks my application. The state of all form fields is lost when validation fails.

Norepro. Probably you also had an immediate command and it's not related to validation failures. Else post a boiled down reproducer.

---

It's really bad that this has slipped through the integration tests. Historically they also ran with PSS turned off but this is since Jakarta migration not anymore happening.

That said, the immediate attribute has since JSF 2.0 lost its real value because the originally intended functionality can be achieved in a much more robust way using <f:ajax> or <h:button>. The immediate attribute should preferably NOT be used in JSF 2.0+ applications. See also https://stackoverflow.com/questions/13071512/why-was-immediate-attribute-added-to-the-editablevalueholders

Nonetheless this bug indeed really warrants analysis and fixing.

[BalusC]

Regression of performance optimizations done in #4808. It was in hindsight not compatible with Full State Saving. It was not immediately obvious how to get it to work with FSS anyway, so I've for now simply restored the original implementation and added an if/else on PSS/FSS and let the FSS condition run the original implementation.

Noted should be that there were and are plans to deprecate and remove FSS in a future Faces version simply because PSS is far superior over it.

[arjantijms]

Noted should be that there were and are plans to deprecate and remove FSS in a future Faces version simply because PSS is far superior over it.

Indeed, FSS will be deprecated in Faces 4 for removal. (small historical note, it should never have been included in the first place, and during the initial JSF design plans it was already controversial to fully save the state)

[miguelzapaton]

Many thanks for your feedback.

I'll try to dive deeper into the issue. I was thinking that it could also be related to #5065 (typo edited).

Is there a SNAPSHOT or NIGHTLY repo for the 2.3 branch?

[arjantijms]

That said, the immediate attribute has since JSF 2.0 lost its real value because the originally intended functionality can be achieved in a much more robust way using <f:ajax> or <h:button>.

We haven't discussed it yet afaik, but maybe we should consider deprecating the immediate attribute as well?

[BalusC]

We haven't discussed it yet afaik, but maybe we should consider deprecating the immediate attribute as well?

Definitely in favor of this.

[BalusC]

Upmerged into 3.x and 4.x branches.

Is there a SNAPSHOT or NIGHTLY repo for the 2.3 branch?

Frankly I'm not sure where it is. It was previously automated externally via Hudson. @arjantijms how exactly is this currently configured?

[comiCH]

Hello there

We are currently experiencing some problems with Mojarra 2.3.17 which might be related to this issue and #5065.
These problems seem to have their root cause in the changes of #4808.

We are migrating an app with JSF and PrimeFaces 8 to WildFly 26.0.1.
Doing so, we found out that several PrimeFaces components no longer function properly, e.g.

• the AutoComplete component never shows any suggestions
• filtering a DataTable does not do anything
• paging of a DataTable does work properly (selecting a row on a page > 1 jumps the table back to page 1)

We dug deep into this and found out, that the problem is related to the changes of the ComponentStateHelper.put(Serializable key, String mapKey, Object value) method made with #4808.
Using the AutoComplete malfunction as a starting point, we made the same observations as @OBreidenbach documented in #5065.
In RESTORE_VIEW a new AutoComplete instance gets created.
In APPLY_REQUEST_VALUES this AutoComplete instance gets populated with proper suggestions.
In RENDER_RESPONSE the previously created and populated AutoComplete is not found by ComponentSupport.findChildByTagId(...) and a new AutoComplete instance (with empty suggestions) is created and rendered instead.

We found out that the reason for ComponentSupport.findChildByTagId(...) to not find the previously created and populated AutoComplete component lies in the method ComponentStateHelper.put(Serializable key, String mapKey, Object value).

In this method an attempt to update the DescendantMarkIdCache is made.
But unfortunately this attempt comes too early in this method.
It will simply result in doing nothing since the MARK_ID is not yet available on the component.
The component's MARK_ID will only be available at the very end of the put-method.

So we moved the code to update the DescendantMarkIdCache to the end of the put-method
and voila, the mentioned problems were gone.

Enclosed you will find the patch of the change we've made.
We think that the patch is reasonable but clearly you can judge our attempt more thoroughly.

Fixed_too_early_update_of_DescendantMarkIdCache.patch.txt

[BalusC]

Fix has been released in Mojarra 2.3.18 / 3.0.2 / 4.0.0