ICEfaces
  1. ICEfaces
  2. ICE-3945

resetting input text value issue

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 1.7.2 SP1
          • Fix Version/s: 1.8RC1, 1.8
          • Component/s: ICE-Components
          • Labels:
            None
          • Environment:
            ANY

            Description

            Problem Description: The issue is that the backing bean value of the input text component is not refreshed from the Reset button which has immediate=true set. We need to reset the form to pull the default values from the backing bean. Note, immediate=true needs to be set because we do not want any validation fired on the form when clicking reset.
             
            Test Passes: Type one or more characters in the input text field, and press Reset. The input text field is reset to the value from the backing bean.
             
            Test Fails: Clear out the input text field (delete all characters) and press Reset. The input text field does *not* pull the value from the backing bean and renders as blank.
             
            This test was executed with 1.7.1 SP1 and 1.8.0 DR#2

              Issue Links

              depends on

              Bug - A problem which impairs or prevents the functions of the product. ICE-3190 selectBooleanCheckbox updates do not reflect rendered html page

              • Major - Major loss of function.
              • Closed

                Activity

                Ascending order - Click to sort in descending order
                Hide
                Permalink
                Scott Ratliff added a comment -

                Also we noticed that this occurs with Checkboxes - selectBooleanCheckbox.

                Show
                Scott Ratliff added a comment - Also we noticed that this occurs with Checkboxes - selectBooleanCheckbox.
                Hide
                Permalink
                Mark Collette added a comment -

                This might be related to ICE-3190, where BridgeFacesContext.applyBrowserDOMChanges() modifies the previous DOM to reflect the submitted values, so that bean changes to the rendered output, reverting them to a previous value, can still result in a correct DOM diff.

                Show
                Mark Collette added a comment - This might be related to ICE-3190 , where BridgeFacesContext.applyBrowserDOMChanges() modifies the previous DOM to reflect the submitted values, so that bean changes to the rendered output, reverting them to a previous value, can still result in a correct DOM diff.
                Hide
                Permalink
                Adnan Durrani added a comment -

                Sam can you please add a testcase which demonstrate the problem. I have created a demo, but its doing normal behaviour.

                The commandButtton type="reset" doesn't invoke any kind of submit, just wondering how they are getting values from the backing bean.

                Show
                Adnan Durrani added a comment - Sam can you please add a testcase which demonstrate the problem. I have created a demo, but its doing normal behaviour. The commandButtton type="reset" doesn't invoke any kind of submit, just wondering how they are getting values from the backing bean.
                Hide
                Permalink
                Sam Xiao added a comment -

                Test case shows the problem in Tomcat 6.0

                Show
                Sam Xiao added a comment - Test case shows the problem in Tomcat 6.0
                Hide
                Permalink
                Mark Collette added a comment -

                BridgeFacesContext.applyBrowserDOMChanges() was only covering the case where the old DOM value was empty, the submitted value was non-empty, and the new DOM value is empty. There's the reverse scenario, where the new and old DOM values are non-empty, but the same, and the submitted value was empty. This is now covered, as well as for the equivalent checkbox case too.

                Subversion 18255
                icefaces\core\src\com\icesoft\faces\context\BridgeFacesContext.java

                Show
                Mark Collette added a comment - BridgeFacesContext.applyBrowserDOMChanges() was only covering the case where the old DOM value was empty, the submitted value was non-empty, and the new DOM value is empty. There's the reverse scenario, where the new and old DOM values are non-empty, but the same, and the submitted value was empty. This is now covered, as well as for the equivalent checkbox case too. Subversion 18255 icefaces\core\src\com\icesoft\faces\context\BridgeFacesContext.java
                Hide
                Permalink
                Mark Collette added a comment -

                Removed debug.

                Subversion 18257
                icefaces\core\src\com\icesoft\faces\context\BridgeFacesContext.java

                Show
                Mark Collette added a comment - Removed debug. Subversion 18257 icefaces\core\src\com\icesoft\faces\context\BridgeFacesContext.java

                  People

                  • Assignee:
                    Unassigned
                    Reporter:
                    Sam Xiao
                  • Votes:
                    4 Vote for this issue
                    Watchers:
                    3 Start watching this issue

                    Dates

                    • Created:
                      Updated:
                      Resolved: