JavaScript Event & Event Method Bugs and Workarounds

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.  

  • Curious89

    Can you please resolve this problem? Thanks.
    The problem description is quite a lot same as this: http://bytes.com/topic/javascript/answers/89311…

    There are 3 buttons on a web page. On clicking each button a same popup window (say window1) opens up. Now there is another button on this popup window (window1), which further opens up to another popup window (say window2). On selecting some value from the 'window2', that value is passed onto the 'window1'. There is a 'Find' link on a 'window1', which calls a javascript function 'clicked()':

    <head>
    <%
    Dim command
    command = Request.Form(“hid”);
    Response.Write(“Value” & command); — The value is not printed (Reason found after
    analysis that may be because the form is not submitted
    successfully)
    %>

    function clicked()
    {
    document.form.hid.value='FIND';
    alert(“before”); — This message box appears
    document.form.submit(); — after a lot of analysis the conclusion is that
    this submit statement stops working (as on the status
    bar 'Opening https:…..File1.asp?form=…' is not
    displayed when 'after' message box appears
    alert(“after”); — This message box appears
    }

    <body…….>
    <% if command = “FIND” then
    Response.Write (“Inside Find”); — This message is not printed.
    // some functonality

    %>
    <form ….>

    <input type=”hidden” name=”hid” value=”">

    </form>
    </body>

    This full code works fine on my machine. But this code does not work properly when run on the client-side!, although the same server and the same deployed application is being accessed. There is no particular sequence/scenario but for eg.
    When say button1 clicked->window1 opens->window2 is opened->value selected->returned to window1->Clicked on Find-> clicked on Ok->returned on the main page.
    Then repeated the same scenario for say 3rd button.
    (Till now 'Find' link works fine).
    Now repeated the same scenario for 2nd button and here 'after' message is obtained but 'inside Find' is not printed!!
    Please help!!

  • http://www.air-jordan-1.com air jordan 1

    Thanks a landlord it! I acquired yet some insight. Life is so colorful, we should be able to live in, such as Korea and honor the planet. Human life is like rivers, slowly flowing, flowing rivers, flowing through the snow, flows through the prairie and ultimately into the sea, return to the embrace of nature, start a new reincarnation. Allow us to feel the meaning of life will come only to those you have those memories http://www.cheap-nikeshox.com/nike-shox-TL1.html