views:

793

answers:

5

The scenario is this. A web page contains:

  • some DIVs whose visibility can be toggled with a javascript (fired from an hyperlink)
  • a Submit button, whose response takes about 5 seconds

The hyperlink code is

<a href="javascript:void null;" onclick="MyFunction()">foo</a>

The User:

  1. Presses Submit.
  2. While he is waiting for the response, he clicks on the hyperlink, and fires the javascript that toggles the DIVs visibility (no other request is performed).
  3. In Internet Exporer 6, the browser stops waiting for the first Request.

The problem does not happen in other browsers, even if the user plays with the DIVs, the first request is correctly handled, and we navigate to the next page.

Does anyone know what might be causing this? Is it a known IE6 issue?

+3  A: 

Yup, this is the IE6 issue with GET requests triggered from a Javascript action on a hyperlink (where the href is set to 'javascript:...').

e.g. if your JavaScript calls someForm.submit() and the method is GET, there will be NO response (the request is definately sent though)

http://webbugtrack.blogspot.com/2007/09/bug-223-magical-http-get-requests-in.html

You either need to modify the link, to be like:

<a href="#bogushash" onclick="MyFunction()">foo</a>
         ^^^^^^^^^^

or always set the link with return false;

<a href="javascript:void null;" onclick="MyFunction();return false;">foo</a>
                                                      ^^^^^^^^^^^^^
scunliffe
Thanks for the comments. I know that returning false in the onclick prevents the HREF, but I didn't think that a javascript null in the HREF could cause a new Request and abort the real one. Also the page worked absolutely fine until someone modified MyFunction().
Filini
Perhaps you have to inspect the changes to MyFunction() to get an indication of the cause then?
KooiInc
The *key* is that your function is submitting the form, or changing the location.href, correct? This is what causes the bug. both workarounds work.
scunliffe
No. nothing was changing the location or HREF in MyFunction(), just the value of some input fields. Anyway, I changed the href to #foo and return false in my onclick, to avoid the problem.
Filini
+1  A: 

I don't really think its wise to call the javascript:void null; from the link. This may be causing your problem. Instead have the href contain a valid link but prevent the defaults action from completing the request

<a href="#" onclick="return MyFunction(event)">foo</a>

where

function MyFunction(e)
{
  if (!e) e = window.event;

  // your code

  if (e.preventDefault) e.preventDefault();
  return false;
}
bendewey
A: 

Since this is a problem. I would suggest using a pseudo "loading" spinner that overlays the clickable content when submit is triggered.

Diodeus
A: 

Please stop supporting IE6, only people without internet connections and pirated copies of windows (can't update) still use it.

Ok maybe that was a bit of a hyperbole, but seriously if we keep supporting IE6 people won't go and get a newer browser to use the internet!

If enough of the internet doesn't work on IE6 people will upgrade.

joshperry
-1, People by computers like they buy ovens. They do not care what type of browser it is. In the professional world you have to accept this and deal with it. Hopefully in the future they will update but until then most people do not care about their browser, only that a page works.
Syntax
Exactly, they only care if the page works... If the page doesn't work and it says "Internet Explorer 6 not supported, get IE7/8 or Firefox here here or here" then they would do what they do with their ovens, hit the dang button so it stops complaining.
joshperry
I am selling this program to a Bank institution. This Bank has a policy to use IE6. "IE6 is not supported" works in a fantasy land.
Filini
+1  A: 

javascript:void null should be javascript:void(0), better still is href="#". If MyFunction returns false the return false in scunliffe's answer shouldn't be necessary, using onclick="return MyFunction()"

KooiInc
I personally prefer the "#fakelink" syntax as "#" is interpreted as "top" which causes the browser to jump to the top of the screen before unloading the page which can be quite jarring on long pages. #fakelink of course goes nowhere as there is no location with that name.
scunliffe
You're right, I didn't think of that.
KooiInc
I tried the return false, but it doesn't work.
Filini