IE Follows Link Even After onclick="return false;"

Question

I'm writing a Rails 2.3.8 app, and using the standard link_to helper. I have a reasonable number of links that user methods other than GET, so I pass a :method => :whatever option to link_to, and it generates a link with an onclick handler like so (indentation added for readability):

<a
  onclick="
    var f = document.createElement('form');
    f.style.display = 'none';
    this.parentNode.appendChild(f);
    f.method = 'POST';
    f.action = this.href;
    var s = document.createElement('input');
    s.setAttribute('type', 'hidden');
    s.setAttribute('name', 'authenticity_token');
    s.setAttribute('value', '31M3q8SJkRz7f0R80l42Z2W7O2N7ZrzufhWQYql/Zd8=');
    f.appendChild(s);
    f.submit();
    return false;"
  href="/transactions/1015/transcribe"
>
Enter Data
</a>

Now, for whatever reason, IE (both 7 & 8 - the two I've tested) has decided that the return false; at the end there isn't enough to stop it from following the link, and I end up getting two requests to my server: The POST request from the onclick handler, which I want, and the GET request from the link itself, which I don't. In fact, that route doesn't exist for anything other than a POST request, so when the browser follows the GET request, the user gets dumped on a 'Bad URL' error screen. Not good.

Has anyone seen this before, and can tell me what's causing it? Or, better yet, does anyone know a good workaround?

PS: I'd prefer NOT to

1. Monkey-patch link-to, or
2. Write my own version of link_to

but if that's what it takes, that's what it takes. And I'm using jQuery 1.5.something, if that helps.

Solution 1

To prevent form submission in JQuery, we often use

event.preventDefault();

So in your example, you could use this (as discussed in comments) :

$('a[onclick]').click(function(e) {e.preventDefault();});

Hope that helps!

Solution 2

In general, when IE decides to "ignore" a return false; from an onclick handler, it is because one of the lines before the return false; threw an exception. This will cause a silent failure of the onclick handler, and the browser will then attempt to access the href link. This applies to all browsers, not just IE, but it's often the case that IE will throw exceptions in cases where other browsers will not, hence why it seems that only IE is ignoring the return false;.

One quick patch for this is to set href="#", which will keep the browser on the page even if the onclick handler fails. The proper way to debug it, however, is to wrap your onclick code in something like try { ... } catch (ex) { alert(ex); } to see what the exception is, and then fix the onclick code so that it no longer throws the exception.

Solution 3

I have had this problem with IE before, and found that a solution that works (which I believe is what jQuery's event.preventDefault() does under the covers), is to do BOTH return false; for normal browsers, but also event.returnValue = false; (before the actual return, obviously) for IE. IE will respect that.

Unfortunately though, I don't know how to slip that into the link_to helper without hacking it. That's actually what I came here looking for. :)

Solution 4

I believe that the problem that you are submiting your new form:

f.submit();

and you are submiting it right to your link href

f.action = this.href;

so you are folowing to this address. Your link returns false, but submited form leads you to this location.

So your link_to is ok. Problem is inside of your strange javascript.

View more solutions

Comments

[Xavier Holt]

It's the correct address, and it is supposed to "follow" after the form is submitted (the POST request). The problem is that after the form is submitted, IE keeps the click event alive, and the browser ends up following a second (erroneous) GET request, which the return false; should have prevented.

[fl00r]

Oh, I got it. Very strange. But need to be tested

[Xavier Holt]

I do! The example code is the output of <%= link_to 'Enter Data', transcribe_transaction_path(txn), :method => :post %>. That's what makes this so irritating (besides having to work with IE): I can't change the JS without monkey-patching Rails, and I'd really rather not do that.

[Xavier Holt]

Upvote for some excellent suggestions. Unfortunately, the fact that Rails generates the JS makes them difficult: I can't change the HREF, as that's what Rails's JS uses for the form's action. I'll try wrapping the handler in a try/catch block with my own JS and post back with results...

[Xavier Holt]

2.3.8 (Although I'm starting to think the bug is somewhere else entirely - something tangential like a tag mismatch, maybe...)

[Xavier Holt]

Hmm. After much experimentation, I finally got the thing wrapped, but it didn't catch any exceptions. Even when I replaced the handler with just plain "return false;" IE still ignored it. I'll keep looking...

[Xavier Holt]

And as a note for non-jQueriers: Returning false from that event handler also seemed to do the trick (I stuck with jQuery's version, though, as it's more likely to be cross-browser).

[ruffin]

I'm getting IE executing a link that has nothing but onclick="return false" in the event handler, so it's not [only] on exceptions in the onclick handler. In this case, the id of the anchor was "undefined" (html dynamically generated -- id="undefined" when I went over and viewed in Firebug) and that was unintuitively borking things. The html was produced and written to the screen (evidenced by it rendering & IE following the link's URL), but that previous exception seems to have hung around.

[John V.]

Happened for me on FF as well, if the function before return false; fails (even silently) then it follows the link anyway.