View Full Version : onload not firing for some users

05-26-2005, 12:27 PM

I have a page with an onload handler set, but it doesn't seem to be firing in a small minority of user's.

<body style="margin: 0; padding: 0;" bgcolor="#FFFFFF" onload="body_onload();">
<script language="javascript" type="text/javascript">
function body_onload() {
var f = document.forms.search;
if (!f) f = document.getElementById("search");

... code that uses f ...

The code that uses the reference f updates a hidden form field with a value. When the user submits the form on this page (not shown), that value is returned to the server. I know the code in body_onload() is not being run because we are getting submits of this form, but no value in the hidden form field the code updates.

I also have a handler attached to window.onerror, with that handler putting the javascript error into a hidden form field and posting that back too. In many cases the onerror handler doesn't seem to be firing either.

From our logging, there seems to be no correlation with browser vendor/version or ISP (it affects all major modern browsers).

It works for me in every modern browser I can get my hands on (IE 5.x & 6, NN6, Firefox 1.x, Opera 7.x & 8.0).

I have spent many hours searching Google, this forum and other forums, to no avail.

Has anybody here had the onload and/or onerror events not fire in some cross-section of browsers (not a particular vendor's browser or version) for some unknown reason?

Thanks in advance

05-26-2005, 12:31 PM
Are you sure there is no window.onload defined after body onload? The last onload definition will override the previous one.

Or probably some users have disabled javascript in their browser.

05-26-2005, 12:32 PM
try putting the script in the head tags. That seems to work sometimes. If that doesn't work, then we need to see the rest of your code preferably with the full script in it.

05-26-2005, 12:37 PM
document.forms[0].search (if it is the first/unique form of the page)
or even better

...and the condition if looks usless to me, as all the browsers, old or new, recognize the reference


05-26-2005, 12:48 PM
perhaps, IE6 SP2 is causing the problem for them. what do you have installed?

05-27-2005, 01:17 AM
Thanks for replying.

glenngv: Thanks for your suggestion - I discovered that the window.onerror event is being overriden by other code. However, the window.onload event is not be overriden.

_Aerospace_Eng_: I'll give that a go.

Kor: I did consider this, but I am pretty confident 'var f = document.forms.search;' works, because I am using it also at the top of the script block, and I know from logging that the code that uses it seems to work fine. However, I will try your suggestion with my next set of changes.

jbot: No, but I noticed that almost all the IE6 user agents have service pack 2 installed ('SV1' in the user agent string). What do you know about the effects of this service pack on IE?

The question I am interested in is, have you ever encountered a situation were the onload or onerror events were not being fired, but only in a small cross-section of browsers (considering all major browsers were affected, but only a minority of users)?

Thanks for your time.

Harry Armadillo
05-27-2005, 01:37 AM
Like Glenn said, users who have turned off javascript.

Or users like me who filter and modify javascript before it reaches the browser. In fact, having been subjected to too many pop-up and other nonsense, onload is one of the events I capture/block.

05-28-2005, 07:53 AM
Thanks for replying Harry Armadillo.

I know that it isn't people without javascript or javascript turned off. In the form, we have a hidden form field which is updated in another part of the javascript, and we are logging this form field when the user submits the form.

You are quite possibly right in that many of the users may have popup blockers that strip out code from the onload event. Unfortunately, there is no real way for us to tell for sure.

However, my boss has decided that this problem is taking too much time. He wants to bypass the problem by cutting the use of the onload event, and doing more of it server-side.

Hopefully this will be a lasting solution.

Thanks for your time.