ICEfaces
  1. ICEfaces
  2. ICE-8964

NPE exception in bridge.js with IF. EE 3.2 RC1 release

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: EE-3.2.0.BETA
    • Fix Version/s: EE-3.2.0.GA
    • Component/s: Bridge
    • Labels:
      None
    • Environment:
      Chrome, Firfox, IE
    • Assignee Priority:
      P1
    • Salesforce Case Reference:

      Description

      The following issue has been reported by one of our customers when they had attempted to upgrade their application to IF EE 3.2 RC1:

      Timestamp: 2/1/2013 3:11:14 AM
      Error: TypeError: dl is null
      Source File: http://wsc-voo-117.wscis.wsc.com:8080/taxgard/javax.faces.resource/bridge.js.iface?ln=ice.core&v=3_2_0_130125
      Line: 1

      Their application is working fine with IF 3.2 Community Edition release.

      After some debugging we'd found that the error is happening in the bridge.js statemenet:

      return dl.type=="blur";
      dl value is null.

      Further analysis has shown that EE bridge.uncompressed.js has javascript method “isBlurEvent()”, but Community Edition does not have one.

      Under some conditions method isBlurEvent() can throw Exception that will be fatal for entire Application.

      Here is a code of original function:
      --------------------------------------------
      function isBlurEvent() {
      var c = arguments.callee.caller;
      while (c) {
      if (c == namespace.fullSubmit) {
      var eventArgument = c.arguments[2]; //unsafe, should be invoked by name
      return eventArgument.type == 'blur'; //unsafe, should be checked for null
      }
      c = c.arguments.callee.caller;
      }
      return false;
      }
      --------------------------------------------

      The customer has proposed the following version of the above code in order to fix the issue:

      --------------------------------------------------------
      function isBlurEvent() {
      var c = arguments.callee.caller;
      while (c) {
      if (c == namespace.fullSubmit) {
      var eventArgument = c.arguments.event;
      if(eventArgument!=null || eventArgument!=undefined)
      return eventArgument.type == 'blur';
      else
      return false;
      }
      c = c.arguments.callee.caller;
      }
      return false;
      }

      ---------------------------------------------------------

      This JIRA is aiming to investigate proposed fix and apply it to our EE release if applicable,

        Activity

        Hide
        Ted Goddard added a comment -

        Variant of the patch that should be safer:

        function isBlurEvent() {
        var c = arguments.callee.caller;
        while (c) {
        if (c == namespace.fullSubmit) {
        var eventArgument = c.arguments[2];
        if(eventArgument!=null || eventArgument!=undefined)

        { return eventArgument.type == 'blur'; }

        else

        { return false; }


        c = c.arguments.callee.caller;
        }
        return false;
        }

        The lack of a definite exit to the while loop is a concern in either case, but this may not be a concern since if the call stack is malformed, there are other more serious problems.

        Show
        Ted Goddard added a comment - Variant of the patch that should be safer: function isBlurEvent() { var c = arguments.callee.caller; while (c) { if (c == namespace.fullSubmit) { var eventArgument = c.arguments [2] ; if(eventArgument!=null || eventArgument!=undefined) { return eventArgument.type == 'blur'; } else { return false; } c = c.arguments.callee.caller; } return false; } The lack of a definite exit to the while loop is a concern in either case, but this may not be a concern since if the call stack is malformed, there are other more serious problems.
        Hide
        Ted Goddard added a comment - - edited

        By simply adding the null check and improving the if/else coding style, the patch looks low risk and a good fix. It is not clear that arguments[2] and arguments.event are equivalent.

        Show
        Ted Goddard added a comment - - edited By simply adding the null check and improving the if/else coding style, the patch looks low risk and a good fix. It is not clear that arguments [2] and arguments.event are equivalent.
        Hide
        Maxim Zaritsky added a comment -

        Folks,
        What would be an ETA for this fix?

        Show
        Maxim Zaritsky added a comment - Folks, What would be an ETA for this fix?
        Hide
        Evgheni Sadovoi added a comment -

        Hi Max,
        I'd updated related SF case with an answer to your question. Please take a look. Thanks!

        Show
        Evgheni Sadovoi added a comment - Hi Max, I'd updated related SF case with an answer to your question. Please take a look. Thanks!
        Hide
        Maxim Zaritsky added a comment -

        Evgheni,
        Got it. Thanks

        Show
        Maxim Zaritsky added a comment - Evgheni, Got it. Thanks
        Hide
        Ted Goddard added a comment -

        Additional simplification to patch:

        +++ core/src/main/javascript/blockui.js (working copy)
        @@ -73,7 +73,11 @@
        while (c) {
        if (c == namespace.fullSubmit) {
        var eventArgument = c.arguments[2];

        • return eventArgument.type == 'blur';
          + if (eventArgument) { + return eventArgument.type == 'blur'; + }

          else

          { + return false; + }

          }
          c = c.arguments.callee.caller;
          }

        Show
        Ted Goddard added a comment - Additional simplification to patch: +++ core/src/main/javascript/blockui.js (working copy) @@ -73,7 +73,11 @@ while (c) { if (c == namespace.fullSubmit) { var eventArgument = c.arguments [2] ; return eventArgument.type == 'blur'; + if (eventArgument) { + return eventArgument.type == 'blur'; + } else { + return false; + } } c = c.arguments.callee.caller; }
        Hide
        Mircea Toma added a comment -

        Yes, the patch looks good to me. Looking up the parameter by name would not have been viable because the code can be minified (the parameter names would be changed).

        Show
        Mircea Toma added a comment - Yes, the patch looks good to me. Looking up the parameter by name would not have been viable because the code can be minified (the parameter names would be changed).

          People

          • Assignee:
            Mircea Toma
            Reporter:
            Evgheni Sadovoi
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: