Archive for the ‘Development’ category

JavaScript Event & Event Method Bugs and Workarounds

May 14th, 2008

Today I spent a good deal of my time dealing with Javascript event handling and delegation using the Prototype javascript library with relation to some forms in our current project. In addition to simply firing and catching events using actual events, this applications also make use of the click() and focus() methods to fire these events in certain circumstances without user interaction. The issues I'm discussing here are specific to radio buttons and checkboxes across the three major browsers--but primarily focused on Firefox and Safari. The provided example does not use Prototype--it is plain vanilla Javascript. However, the proposed workaround does rely on the Prototype library (sorry, it was just faster that way--and it's also the implementation I used to solve the problem on my own).

What (I believe) the spec calls for:

When a radio button or checkbox is clicked with the mouse, the mouse click event will fire with it's target object set to the radio button that was clicked. The radio button will also gain focus.

Both Internet Explorer and Firefox exhibit this behavior exactly (on true user clicks--we'll get to the event simulation methods shortly). Safari, however, only fires the click event. The checkbox or radio button that was clicked does not receive focus as it should.

So let's just always observe clicks and leave focus to the birds

I told you we'd get back to the event simulation methods in a minute. Both Firefox and Internet Explorer exhibit some strange behavior when using these methods vs. actual events. In Firefox, the click() method generates an event with the target set to the calling element--not the actual target of the click. This is inconsistent with both Firefox's focus() method and Internet Exlorer and Safari's handling of both the click() and focus() methods. This example (Firefox, Safari, and Opera compatible) demonstrates the issue.

So where does the problem start?

In the case when you need to force a particular radio button to be selected by default and you have additional Javascript logic that must run based on that selection. Let's say you have 4 radio buttons as in the previous example and you wish the 3rd radio button to be selected by default (we'll assume there's some Javascript logic that must happen based on the user's selection that must also occur with the default selection). Because the user will not be interacting with the default selection, we must rely on event methods to fire our events. So we have some challenges:

  • If we use click() and have our radio buttons listen for a click, Firefox will believe the target of the event is document. The radio button will be selected, but any additional logic based on knowing what was clicked (using event.target) will fail.
  • If we use focus() and have our radio buttons listen for focus, Safari will see the radio button receive focus correctly when the page loads as we will be using focus(). However, any actual user interaction will fail as the focus() event will not fire.

A workaround

I intend to open a bug in the Firefox bug tracker for this issue (if one is not already open; I didn't find one with a quick glance through Bugzilla). Until then, I've written a little workaround that requires the Prototype library to function.

First, ensure that your radio buttons are set up to respond to focus events (since we know that Firefox will only react properly to those events when called programmatically.

$('my-form').getInputs("radio").invoke('observe', 'focus', eventHandler);

Now, observe for clicks to forward on:

$('my-form').getInputs("radio").invoke('observe', 'click', fakeClick);

Your fakeClick method should look like this:

fakeClick: function(e){
   var el = e.element();
   if(el.identify) { /* Filter out click() for FireFox */
      if(this.focused.identify() != el.identify()) {
         e.element.focus(); /* Throws the proper focus() for Safari */
      }
   }
}

The other aspect of this is that within your actual event handler, you need to be sure to set the this.focused to the element that currently has focus.

I've created an example Prototype-enabled JS class to show how the functionality works.

Conclusion

So there you have it, some basic information about a bug in Firefox and a bug in Safari that together make for some interesting times when handling events; and a workaround which I hope you will find useful in getting around these two bugs. Please note that the code is more of an example on how to implement it; though it can be copied verbatim if you wish.

Download ClickFix.js (2kb)

Update 5/14/2009: By pure coincidence, I've added to this post exactly 1 year to the day after I first wrote it. Please see a new post on a Workaround for form submit events not firing with the submit method.  

Back from Web 2.0 Expo

April 29th, 2008

For the first time in a long time, I feel like it's actually for me to start blogging again--it's not that I have some conceited notion that the world actually wants to hear what I have to say.  It's more that after moving to AutoTrader.com in November, I feel like I've really found some direction.  All of my previous attempts at starting a blog focused (at least, in my mind) on my own design abilities.  Having found myself at ATC, I've come to accept a pretty sensible truth:  I am not an artist.  

Certainly I have some Visual Design skills; but they are not my strong suit.  My focus has always been on User Experience an Interaction Design and the best way for me to achieve those goals is to focus on User Centric development practices as an extension of User Centric Design.  It's with this mentality that I've chosen simply to install Wordpress, grab a theme I thought was nice, and get to the more important aspect of writing a Blog--actually writing it!

I'm back in Atlanta this week after attending the O'Reilly Web 2.0 Expo in San Francisco April 22-25.  The Expo was, for lack of a better description, a mixed bag.  Duane Nickull and James Ward of Adobe opened the conference for us on Tuesday with an Adobe Flex Boot Camp session which set a rather high bar in terms of conference sessions. Needless to say, after seeing the potential of Flex first hand, I quickly downloaded the Flex Builder 60-day trial and have been running through tutorials since I got back.   As my colleague Neil Green put it to me, "this shit sells itself"--and he was 100% correct.  When we look at Flash version penetration numbers, what we see is that over 98% of systems have Flash Player 8 or better.  What does this mean?  In the simplest terms:

  • More people have Flash than have Javascript enabled
  • More people have Flash than use any single version of any web browser
  • More people have Flash than use any version of any web browser

In my opinion, those are some pretty staggering numbers.  Factor in that the Flash Player will render these SWF files identically on the 3 major platforms--under any browser--and you have a very compelling argument in favor of Flex-based development for the front end.  Especially given that my primary role at ATC over the past 7 months has been as an Ajax developer and my continuing battles with multiple browsers' disparate support for CSS...you get the picture.  Technology like Flex looks pretty good in the face of all of that.

What have you heard about Flex?  What do you see as the advantages and the drawbacks?  Are you looking at implementing it in your organization?    Basically--I've been sold on the idea of Flex; but I'd love to hear the downsides that I'm certain I'm overlooking (and let's try to avoid the "more obvious than obvious" things like "it's proprietary" and "it requires a plugin").  Thanks--that'd be great!