|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
In order to avoid any misunderstandings with me referring to immediate tabs:
I am aware that user input is lost in case of switching tabs in a <rich:tabPanel immediate="true">.
This issue report is NOT about lost user input in case of switching tabs in an immediate tabPanel;
it is about re-rendering a <rich:select> at the end of any request whose JSF processing skips PROCESS_VALIDATIONS and UPDATE_MODEL_VALUES (due to any immediate flag being set on the triggered command).
In the attached demo 'richFacesSelectImmediate.xhtml' you may as well remove the enclosing <rich:tabPanel> and <rich:tab> elements around <rich:select> and just use the two command buttons to inspect the difference between immediate and non-immediate.
I was tempted to refer to <rich:tabPanel> just because it was how we became aware of the problem:
a user tried to re-select the already active tab inside a <rich:tabPanel immediate="true"> and the labels of <rich:select> inside the active tab disappear.