ICEfaces
  1. ICEfaces
  2. ICE-10762

commandLink action method being called twice on one click

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: EE-3.3.0.GA_P03
    • Fix Version/s: EE-3.3.0.GA_P04
    • Component/s: Bridge, Framework
    • Labels:
      None
    • Environment:
      Mojarra 2.1.29-01, 2.1.29-02, 2.1.29-03
    • Assignee Priority:
      P1
    • Support Case References:
    • Workaround Exists:
      Yes
    • Workaround Description:
      The Mojarra 2.1.29 (before 2.1.29-01) doesn't seem to show this behavior as well as the supported 2.1.28 release.

      Description

      A commandLink is being rendered in an iterative container (ui:repeat, ace:dataTable, etc). On click of this link the action method receives the var object and updates the page based off of this click.

      Using ICEfaces 3 with Mojarra 2.1.29-01, upon each click the action method is called twice (except for the first click). It is called once for the current clicking link and again for the last one (when clicking down the list). When clicking up the list, this causes the data on the page to be shown incorrectly, the last link method is always called.

      I have created a plain JSF test case using the same code and jar file but this doesn't show the same behavior.

        Issue Links

          Activity

          Hide
          Arran Mccullough added a comment -

          Attached test case that reproduces this issue.

          Steps:

          • Load welcomeICEfaces.jsf
          • Click the first 'Show Dialog' link. There will be a single 'Opening popup for: 0' shown in the server logs and the Index is displayed at the bottom of the list.
          • Click the second 'Show Dialog' link. There will be two logs in the server showing:
            Opening popup for: 0
            Opening popup for: 1
          • The index shown is correct as the last method call was for the currently clicked link.
          • Click the first 'Show Dialog' link. There are two method calls again, but in the same order:
            Opening popup for: 0
            Opening popup for: 1
          • The index shown is incorrect as the last method call was for the previous link index (1) and not the clicked one (0).
          Show
          Arran Mccullough added a comment - Attached test case that reproduces this issue. Steps: Load welcomeICEfaces.jsf Click the first 'Show Dialog' link. There will be a single 'Opening popup for: 0' shown in the server logs and the Index is displayed at the bottom of the list. Click the second 'Show Dialog' link. There will be two logs in the server showing: Opening popup for: 0 Opening popup for: 1 The index shown is correct as the last method call was for the currently clicked link. Click the first 'Show Dialog' link. There are two method calls again, but in the same order: Opening popup for: 0 Opening popup for: 1 The index shown is incorrect as the last method call was for the previous link index (1) and not the clicked one (0).
          Hide
          Arturo Zambrano added a comment -

          This seems to be an issue with our core framework and that specific version of Mojarra. First of all, the test page doesn't have any ICEfaces components (ace, mobi, or icecore); it's all standard JSF. I tried removing the ACE jar from the /lib folder of the test app, as well as removing the ACE namespace in the test page and deleting the insert xhtml documents (which aren't used but contained some ACE components), and I was still able to reproduce the issue as described above.

          So, I created a JSF-only app (attached), and I copied the classes from the original test app, as well as the welcomeICEfaces.xhtml page and the same mojarra jar. In this case, having no traces of ICEfaces and using Mojarra 2.1.29-01, I was not able to reproduce the issue.

          Then, I went back to the original test app and replaced the Mojarra jar for javax.faces-2.2.10.jar. In this case I got a server exception about not being able to add the same component twice (javascript_runner), and the app didn't get to run. So, then I tried using the Mojarra version 2.1.28, which is the one included in the 3.3 P03 release, and in this case the issue couldn't be reproduced. The test page worked as expected (i.e. only one log in the server console and the index shown changing accordingly in all cases). I double-checked all this.

          So, the easiest thing is for the customer to use a different Mojarra version, like 2.1.28, which is the one that comes with the 3.3 EE P03 release. Is there a reason why they need to use the version 2.1.29-01?

          Show
          Arturo Zambrano added a comment - This seems to be an issue with our core framework and that specific version of Mojarra. First of all, the test page doesn't have any ICEfaces components (ace, mobi, or icecore); it's all standard JSF. I tried removing the ACE jar from the /lib folder of the test app, as well as removing the ACE namespace in the test page and deleting the insert xhtml documents (which aren't used but contained some ACE components), and I was still able to reproduce the issue as described above. So, I created a JSF-only app (attached), and I copied the classes from the original test app, as well as the welcomeICEfaces.xhtml page and the same mojarra jar. In this case, having no traces of ICEfaces and using Mojarra 2.1.29-01, I was not able to reproduce the issue. Then, I went back to the original test app and replaced the Mojarra jar for javax.faces-2.2.10.jar. In this case I got a server exception about not being able to add the same component twice (javascript_runner), and the app didn't get to run. So, then I tried using the Mojarra version 2.1.28, which is the one included in the 3.3 P03 release, and in this case the issue couldn't be reproduced. The test page worked as expected (i.e. only one log in the server console and the index shown changing accordingly in all cases). I double-checked all this. So, the easiest thing is for the customer to use a different Mojarra version, like 2.1.28, which is the one that comes with the 3.3 EE P03 release. Is there a reason why they need to use the version 2.1.29-01?
          Hide
          Ken Fyten added a comment -

          Closing as won't fix as this is a pure JSF Mojarra issue in 2.1.29.

          Show
          Ken Fyten added a comment - Closing as won't fix as this is a pure JSF Mojarra issue in 2.1.29.
          Hide
          Ken Fyten added a comment -

          Re-openeing this as testing with the latest 2.1.29-04 Mojarra release still shows the issue, thus, no short-term fix from Mojarra appears to be one the horizon.

          In addition, the customer cannot use the 2.1.28 release due to issues they see related to this Mojarra issue: https://java.net/jira/browse/JAVASERVERFACES-3545

          Show
          Ken Fyten added a comment - Re-openeing this as testing with the latest 2.1.29-04 Mojarra release still shows the issue, thus, no short-term fix from Mojarra appears to be one the horizon. In addition, the customer cannot use the 2.1.28 release due to issues they see related to this Mojarra issue: https://java.net/jira/browse/JAVASERVERFACES-3545
          Hide
          Mircea Toma added a comment -

          Submit the form when mojarra.jsfcljs will invoke Form.onsubmit thus avoiding to submit an old captured event and element. Mojarra will add its own hidden input elements before and remove them after the submit.

          Show
          Mircea Toma added a comment - Submit the form when mojarra.jsfcljs will invoke Form.onsubmit thus avoiding to submit an old captured event and element. Mojarra will add its own hidden input elements before and remove them after the submit.
          Hide
          Liana Munroe added a comment - - edited

          Verified ICEfaces ee-3.3.0 maintenance branch r45986 and attached test case, Tomcat 7, mojarra 2.1.28, 2.1.29-01 and 2.1.29-04. FF 34, Chrome 45, IE 11, 10, 9, 8, 7.

          Show
          Liana Munroe added a comment - - edited Verified ICEfaces ee-3.3.0 maintenance branch r45986 and attached test case, Tomcat 7, mojarra 2.1.28, 2.1.29-01 and 2.1.29-04. FF 34, Chrome 45, IE 11, 10, 9, 8, 7.

            People

            • Assignee:
              Mircea Toma
              Reporter:
              Arran Mccullough
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: