August 29, 2012

This mystery had been eluding me for at least 5-6 months since we started introducing JavaScript exception monitoring, but I finally was better able to understand why the Comcast Protection Suite has been causing so many problems for many our users. No, it isn't injecting its own jQuery, and no it isn't defining its own $, but rather it's trying to do anti keystroke logging....


We knew anecdotally that disabling the Comcast plug-in solved the issue, but I could never explain why the exception occurred. Apparently the Comcast Protection Suite installs a Browser Helper Object DLL into Internet Explorer. The DLL has just as much control over the DOM that JavaScript modules do. It apparently is also adding keyup (and perhaps keydown) event handlers to the DOM, presumably to keep somebody else from capturing your keystrokes.

Not only does it slow down overall performance on browsers, but the DLL also causes conflicts with jQuery because jQuery tries to execute the native events after executing jQuery events (i.e. running 'onclick' events after bind('click') or live('click') events). I guess there are some issues running DLL onclick events in JavaScript, since an exception gets generated in not being able to call apply() on these handlers. If you try...catch them, the problem at least gets mitigated...but this requires a change directly within jQuery 1.7.2. jQuery 1.8.0 is out, but it still has this same problem. 

Also, apparently the Comcast Protection Suite software that gets passed along for a lot of new Comcast users, which is why we believe this problem is so pervasive. I'm even more astounded by Norton, which had this response after a user complained about the slower keystroke rates once this software was installed: 

http://community.norton.com/t5/Other-Norton-Products/disappearing-keystrokes-in-webform/td-p/613012 

This particular issue appears to be isolated to this specific site and is directly related to a JavaScript function the website owners have implemented to test whether the first name or last name text filed is only alpha characters.  The method employed at the website to check for alpha characters is not the standard approach, which is to check for the input as it is added onKeyUp. The standard JS best practice is to use a regular expression that checks and validates the entire field input at form submission.  Therefore we expect this to be an isolated issue. 

 Besides asking every user to disable the Comcast toolbar plug-in, the workaround/fix is actually quite simple.  Apparently the native onclick handler checks need to verify that apply() can be run.  Normally DLL onclick handlers return 'undefined', which therefore are missing an apply() function.  We can enforce this check within the jQuery code, for which we'll be submitting a patch soon.

3212 3212             // Note that this is a bare JS function and not a jQuery handler
3213 3213             handle = ontype && cur[ ontype ];
3214                if ( handle && jQuery.acceptData( cur ) && handle.apply( cur, data ) === false ) {
  3214              // Workaround for Comcast Protection Suite bug
  3215              // Apparently the handle function is 'undefined' but not really undefined...
  3216              if ( handle && jQuery.acceptData( cur ) && handle.apply && handle.apply( cur, data ) === false ) {
3215 3217                 event.preventDefault();
3216 3218             }
3217 3219         }


The jQuery bug report is here: http://bugs.jquery.com/ticket/12423

 



blog comments powered by Disqus