Welcome to WebmasterWorld Guest from

Forum Moderators: incrediBILL

IE6 stack overflow; other browsers OK

5:21 am on Sep 1, 2009 (gmt 0)

5+ Year Member

I came across this thread from ages ago that fits my problem to a "t" -- and by the bye, pops up in spot #1 on page #1 on Google ;-)


anyway, I do get these stack overflow errors in IE when running a javascript script, but it happens only with IE6. I track the number of times various page-loading procedures are called, and indeed, I can see why IE6's stack is overflowing; but why ONLY IE? For example, one procedure that gets called 19 times during page load in Firefox gets called 751 times during page load in IE. And that's only one of several procedures with that discrepancy in IE versus the other browsers I test on. If the code flow was at fault, this should be happening regardless of browser, no?

at this point I'm baffled, so any pointers to what's the best direction to go from here are appreciated. Thanks...

8:17 am on Sep 1, 2009 (gmt 0)

WebmasterWorld Senior Member rocknbil is a WebmasterWorld Top Contributor of All Time 10+ Year Member

one procedure that gets called 19 times during page load in Firefox gets called 751 times during page load in IE.

This alone tells you (of course) it's going into a loop. Why?

Your programming probably expects values from certain conditions. That is, if I have a <p> and it's id'ed test I would expect if I have var con = document.getElementById('test').innerHTML, it would store the content of that paragraph in the variable con.

But what if the browser doesn't recognize the .innerHTML attribute, or even document.getElementById? Then you get nothing, or an error.

I'm suggesting that there is some reference in your code **without proper error trapping** that is expecting a value or object, and in IE6 it's not finding it. It's not erroring, it's executing the request recursively until you get a memory error. For example, IE6 does not support min-width or max-width, if you try to access that property in IE it will error.

Try digging around in your script that way, look for references to the document's elements.

2:24 pm on Sep 1, 2009 (gmt 0)

5+ Year Member

Yes, no kidding. So far I've been able to zero in on cookie handling. I've made some changes to a cookie holding user preferences and before loading the altered cookie I look for and delete (expire) the old cookie. I also validate anything written to a cookie by reading it back and rewriting if necessary. It appears that what's happening is that IE is either not expiring the old cookie successfully, and/or the app is proceeding with page load and reading the old cookie, thereby causing validation failures and subsequent rewrites. After manually deleting the old cookie, IE had no problems. So......... FF maintains its own proprietary cookies; that may be a factor. At this point the code assumes a successful old cookie delete. I'll try adding some code to verify the delete before proceeding.

The only other explanation I can come up with is that IE's javascript run-time is not executing the code sequentially, which sounds pretty bizarre. I'm fairly new to javascript, and I'm not a professional. Am I in error assuming that it's execute sequentially?

5:38 pm on Sep 1, 2009 (gmt 0)

WebmasterWorld Senior Member rocknbil is a WebmasterWorld Top Contributor of All Time 10+ Year Member

Well it should run top-down, just like source code is read. But it's hard to say without seeing it. How large is the JS, can you post relevant code if it's not too huge? Have you done the process of elimination, paring it down to the section causing the problem?

I keep a machine with IE6 running, I may have time to look.

4:20 am on Sep 2, 2009 (gmt 0)

5+ Year Member

Thanks for the kind offer. It's pretty huge, though. I think my error was in assuming the old cookie would be deleted just by waving my magic code causing it to go away, and not making sure it really did. Though now I can't duplicate the problem with fake "old" cookies so I'm still baffled. I did add code to verify a cookie delete, and also reduced the number of cookie write verifications to one per page load, whereas I had been doing it for each cookie write, and several items may get changed each page load, with corresponding cookie writes. The problem may have originally been caused, or at least compounded, by the loose data typing. I've been having fits with numerical comparisons and math, and there were a number of those in the verify cookie code, so there may have been unexpected branching due to logical operations giving a true result rather than the expected false. Now I just basically assume everything is a string and parseInt them before any math or logical operations.

Thanks again for your responses. :-)


Featured Threads

Hot Threads This Week

Hot Threads This Month