MyFaces Trinidad
  1. MyFaces Trinidad
  2. TRINIDAD-354

Using autoSubmit on a text field suppresses the ActionEvent on a button

    Details

    • Type: Bug Bug
    • Status: Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.0.1-incubating-core-SNAPSHOT, 2.0.0-core
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      First reported on OTN for ADF Faces:

      http://forums.oracle.com/forums/thread.jspa?threadID=390427&tstart=0

      ... but presumably applies to Trinidad too. The report:

      "Adding an InputText component on the page that has autosubmit set to true and
      a value change listener attached will suppress a button action event if the
      user directly clicks onto the button when leaving the field

      To reproduce:

      • Create ADF Faces page with backing bean
      • Add InputText components to ADF Faces page
      • Set autosubmit property in the InputText to true
      • Add CommanButton to ADF Faces page
      • Create action method for command button (double click on the button to
        create the method
      • Add System.out.println("Action event fired"); into the method
      • create a ValueChange listener for the textfield and put
        System.out.println("Value Change Listener fired"); into it
      • Run the ADF Faces page
      • Type hello into teh textfield and hit the button

      The output you see is "Value Change Listener fired". Pressing the button
      twice shows "Action event fired" as well. Obviously an event on a autosubmit
      InputText overrides the event on the component that is clicked on."

        Issue Links

          Activity

          Hide
          Simon Lessard added a comment -

          Here's a little follow-up on this issue.

          I found the following property in org.apache.myfaces.adfinternal.ui.UIConstants

          // Allow the first click to go through in certain instances? When a PPR event
          // occurs, we block all user input until it completes. However, there may be
          // instances where the client wants to receive the very first click. For
          // example, If the user has entered text in a textInput with a ClientAction
          // attached, then immediately clicked a submit button, the click would get
          // consumed by the blocking code. This attribute (on the BodyBean), allows
          // the client to force the delivery of the first click.
          public static final AttributeKey FIRST_CLICK_PASSED_ATTR = new AttributeKey("firstClickPassed");

          It seems to be a property of the <afh:body/> tag. We should test to see if setting the property to true fix the issue, and if it's the case, maybe use true as the default value instead of false.

          Show
          Simon Lessard added a comment - Here's a little follow-up on this issue. I found the following property in org.apache.myfaces.adfinternal.ui.UIConstants // Allow the first click to go through in certain instances? When a PPR event // occurs, we block all user input until it completes. However, there may be // instances where the client wants to receive the very first click. For // example, If the user has entered text in a textInput with a ClientAction // attached, then immediately clicked a submit button, the click would get // consumed by the blocking code. This attribute (on the BodyBean), allows // the client to force the delivery of the first click. public static final AttributeKey FIRST_CLICK_PASSED_ATTR = new AttributeKey("firstClickPassed"); It seems to be a property of the <afh:body/> tag. We should test to see if setting the property to true fix the issue, and if it's the case, maybe use true as the default value instead of false.
          Hide
          Pierre-Luc Archambault added a comment -

          Did a quick test to verify this and it appears that the attribute doesn't fix the bug finally. The PPR event still block the Action fired from the commandButton.

          Show
          Pierre-Luc Archambault added a comment - Did a quick test to verify this and it appears that the attribute doesn't fix the bug finally. The PPR event still block the Action fired from the commandButton.
          Hide
          Simon Lessard added a comment -

          Then this is a bug in <afh:body/>'s firstClickPassed property.

          Show
          Simon Lessard added a comment - Then this is a bug in <afh:body/>'s firstClickPassed property.
          Hide
          Adam Winer added a comment -

          Note: firstClickPassed is in an obsolete codebase and is unused; afh:body does not have a firstClickPassed property, so this is not relevant to this issue.

          Show
          Adam Winer added a comment - Note: firstClickPassed is in an obsolete codebase and is unused; afh:body does not have a firstClickPassed property, so this is not relevant to this issue.
          Hide
          Pierre-Luc Archambault added a comment -

          I made a little more search throught the code (mostly java script now) about this issue, and its seems that in the :
          Core.js
          on the branch adf-faces\adf-faces-impl\src\main\javascript\META-INF\adf\jsLibs

          there is a var named _pprFirstClickPass that is set to false. From the comment it seemed this variable was manipulated through the FirstClickPassed from the body element. (the one which Adam said it was now deprecated)

          When manually setting this var to TRUE, I did some test with the example how to reproduce the 'bug' and its turn out that the behavior for the bug is somewhat solved. While testing I'd say about 3/4 of the click I tried to do moderately fast, (ilke a normal click) were detected and both event fired, at the opposite of when the var was at FALSE. However, it seems that sometimes even with the var at TRUE, only the onChange event get executed and the onClick event is lost.

          Overall, what I'm sure of is that if this _pprFirstClickPass var is at TRUE, the behavior of clicking on a button right after a inputText value change is really better than when at FALSE. Most of the time, the bug isn't apparent, even tought, sometimes its still occured.

          Show
          Pierre-Luc Archambault added a comment - I made a little more search throught the code (mostly java script now) about this issue, and its seems that in the : Core.js on the branch adf-faces\adf-faces-impl\src\main\javascript\META-INF\adf\jsLibs there is a var named _pprFirstClickPass that is set to false. From the comment it seemed this variable was manipulated through the FirstClickPassed from the body element. (the one which Adam said it was now deprecated) When manually setting this var to TRUE, I did some test with the example how to reproduce the 'bug' and its turn out that the behavior for the bug is somewhat solved. While testing I'd say about 3/4 of the click I tried to do moderately fast, (ilke a normal click) were detected and both event fired, at the opposite of when the var was at FALSE. However, it seems that sometimes even with the var at TRUE, only the onChange event get executed and the onClick event is lost. Overall, what I'm sure of is that if this _pprFirstClickPass var is at TRUE, the behavior of clicking on a button right after a inputText value change is really better than when at FALSE. Most of the time, the bug isn't apparent, even tought, sometimes its still occured.
          Hide
          Volker Malzahn added a comment -

          I wonder why this issue is open since 2006. trh:body has documented attribute "firstClickPassed" and Core.js seems to handle this, but it still doesn't solve the issue. In my opinion it's urgent to get a solution for this soon.

          Show
          Volker Malzahn added a comment - I wonder why this issue is open since 2006. trh:body has documented attribute "firstClickPassed" and Core.js seems to handle this, but it still doesn't solve the issue. In my opinion it's urgent to get a solution for this soon.
          Hide
          Matthias Weßendorf added a comment -

          Volker,
          do you have a patch for this? If so, please upload it, so we can merge the change into the code-base;
          thx

          Show
          Matthias Weßendorf added a comment - Volker, do you have a patch for this? If so, please upload it, so we can merge the change into the code-base; thx
          Hide
          Volker Malzahn added a comment -

          Hi Matthias,

          thank you for your answer.

          No, I don't have a patch. I'm not a JavaScript expert and it isn't quite easy to debug such things. I have taken a look into some code sections in Trinidad and found...

          in BodyRenderer.renderPPRSupport():
          if (getFirstClickPassed(bean))

          { ... writer.writeText("var _pprFirstClickPass=true;", null); }

          and in Core.js some parts which care about "firstClick" (e.g. inside _pprInstallBlockingHandlers()), but additionally there are comments like "TODO: Because PPR is now queued, is this still relevant?" and "TODO: fix for PPR" in function _saveFormForLaterSubmit.

          So a solution for this issue seems to be partly implemented but not completed. I have done tests with the booking-faces demo app of Spring Web Flow after adding Trinidad to the app. In IE7, IE8 and Firefox 3.5 the issue isn't solved.

          For projects of my company which use Trinidad a solution of this issue is needed soon. I would appreciate if someone who is familiar with the Trinidad JavaScript code would solve this issue.

          Show
          Volker Malzahn added a comment - Hi Matthias, thank you for your answer. No, I don't have a patch. I'm not a JavaScript expert and it isn't quite easy to debug such things. I have taken a look into some code sections in Trinidad and found... in BodyRenderer.renderPPRSupport(): if (getFirstClickPassed(bean)) { ... writer.writeText("var _pprFirstClickPass=true;", null); } and in Core.js some parts which care about "firstClick" (e.g. inside _pprInstallBlockingHandlers()), but additionally there are comments like "TODO: Because PPR is now queued, is this still relevant?" and "TODO: fix for PPR" in function _saveFormForLaterSubmit. So a solution for this issue seems to be partly implemented but not completed. I have done tests with the booking-faces demo app of Spring Web Flow after adding Trinidad to the app. In IE7, IE8 and Firefox 3.5 the issue isn't solved. For projects of my company which use Trinidad a solution of this issue is needed soon. I would appreciate if someone who is familiar with the Trinidad JavaScript code would solve this issue.
          Hide
          Volker Malzahn added a comment -

          I have another information which might help to solve this issue:

          if you have a Spring Web Flow webapp (e.g. booking-faces) and add Trinidad to the app you get the autoSubmit double click problem when you use tr:commandButton. But if you use sf:commandButton (the "sf" name space comes with Spring Faces: "http://www.springframework.org/tags/faces") you don't get the problem: the first button click submits the form, even if your focus is in an autoSubmit field! sf:commandButton uses it's own JavaScript code to submit the form ("Spring.remoting.submitForm(...)") and this code seems to win against the blocking code inside the Trinidad autoSubmit-Code. I haven't looked deeper into Spring.remoting.submitForm but perhaps this helps to fix the issue.

          Regards,
          Volker

          Show
          Volker Malzahn added a comment - I have another information which might help to solve this issue: if you have a Spring Web Flow webapp (e.g. booking-faces) and add Trinidad to the app you get the autoSubmit double click problem when you use tr:commandButton. But if you use sf:commandButton (the "sf" name space comes with Spring Faces: "http://www.springframework.org/tags/faces") you don't get the problem: the first button click submits the form, even if your focus is in an autoSubmit field! sf:commandButton uses it's own JavaScript code to submit the form ("Spring.remoting.submitForm(...)") and this code seems to win against the blocking code inside the Trinidad autoSubmit-Code. I haven't looked deeper into Spring.remoting.submitForm but perhaps this helps to fix the issue. Regards, Volker
          Hide
          Volker Malzahn added a comment -

          I have found a work around for this issue in our webapp:
          Instead of specifying autoSubmit="true" on tr:inputText etc. I specify my own onchange handler controlASOnChange.
          Inside the JavaScript function controlASOnChange I delay the execution of the autoSubmit logic by window.setTimeout("autoSubmit('" + controlId + "', '" + formId + "')", 100);
          My autoSubmit function then calls the Trinidad autoSubmit function: TrPage._autoSubmit(formId, controlId, new Object(), 1);
          "new Object()" is taken as event. TrPage._autoSubmit is able to deal with this instead of the real onchange event.

          By delaying the autoSubmit processing by 100ms the click event (which waits for execution in the queue) wins against the onchange event in my environment (tested with IE8 and Firefox 3.6).

          This is no real solution of the issue but more a work around. I hope that Trinidad will have a general solution for it in a future release.

          Regards,
          Volker

          Show
          Volker Malzahn added a comment - I have found a work around for this issue in our webapp: Instead of specifying autoSubmit="true" on tr:inputText etc. I specify my own onchange handler controlASOnChange. Inside the JavaScript function controlASOnChange I delay the execution of the autoSubmit logic by window.setTimeout("autoSubmit('" + controlId + "', '" + formId + "')", 100); My autoSubmit function then calls the Trinidad autoSubmit function: TrPage._autoSubmit(formId, controlId, new Object(), 1); "new Object()" is taken as event. TrPage._autoSubmit is able to deal with this instead of the real onchange event. By delaying the autoSubmit processing by 100ms the click event (which waits for execution in the queue) wins against the onchange event in my environment (tested with IE8 and Firefox 3.6). This is no real solution of the issue but more a work around. I hope that Trinidad will have a general solution for it in a future release. Regards, Volker
          Hide
          Scott O'Bryan added a comment -

          Handled by duplicates

          Show
          Scott O'Bryan added a comment - Handled by duplicates
          Hide
          Volker Malzahn added a comment -

          I don't understand why this is closed: set to "duplicate" but the other 2 issues dealing with this PPR issue are marked as "duplicate" too, none of them has a solution. A test in current Trinidad 2.0.0 shows that we still have this issue and a solution would be appreciated much because my workaround isn't nice (see above).

          Regards,
          Volker

          Show
          Volker Malzahn added a comment - I don't understand why this is closed: set to "duplicate" but the other 2 issues dealing with this PPR issue are marked as "duplicate" too, none of them has a solution. A test in current Trinidad 2.0.0 shows that we still have this issue and a solution would be appreciated much because my workaround isn't nice (see above). Regards, Volker
          Hide
          Maycon Oliveira added a comment -

          Volker is right, the issue still exists, Why the JIRA is Closed?

          Show
          Maycon Oliveira added a comment - Volker is right, the issue still exists, Why the JIRA is Closed?
          Hide
          Marco Bettiol added a comment -

          Sorry to inform you this bug is not solved even with the latest trinidad (2.0.0) release.

          Show
          Marco Bettiol added a comment - Sorry to inform you this bug is not solved even with the latest trinidad (2.0.0) release.
          Hide
          Volker Malzahn added a comment -

          It's a pity that we still don't have a solution for this. Why isn't this issue reactivated (see comments above)? Can you please reactivate it? And it would be nice to have this issue planned for the next Trinidad release.

          Regards,
          Volker

          Show
          Volker Malzahn added a comment - It's a pity that we still don't have a solution for this. Why isn't this issue reactivated (see comments above)? Can you please reactivate it? And it would be nice to have this issue planned for the next Trinidad release. Regards, Volker
          Hide
          Scott O'Bryan added a comment -

          Repots that this is not fixed

          Show
          Scott O'Bryan added a comment - Repots that this is not fixed
          Hide
          Günter D. added a comment -

          My workaround for this issue:

          onmouseover="this.focus();" for the tr:commandButton

          Show
          Günter D. added a comment - My workaround for this issue: onmouseover="this.focus();" for the tr:commandButton
          Hide
          jenny dai added a comment - - edited

          It is found that we always have this problem in IE but not easy to see in Firefox.
          Our workaround in IE: If the input field has onblur, onchange and onchange is a partial submit, then delay onchange 100ms.
          var _this=curEle;
          curEle.onchange=function(){ setTimeout( function(){_this.onchange();}, 100);}

          Show
          jenny dai added a comment - - edited It is found that we always have this problem in IE but not easy to see in Firefox. Our workaround in IE: If the input field has onblur, onchange and onchange is a partial submit, then delay onchange 100ms. var _this=curEle; curEle.onchange=function(){ setTimeout( function(){_this.onchange();}, 100);}

            People

            • Assignee:
              Unassigned
              Reporter:
              Adam Winer
            • Votes:
              23 Vote for this issue
              Watchers:
              15 Start watching this issue

              Dates

              • Created:
                Updated:

                Development