"Active not defined" in an IFRAME

Has anyone run across a computer that just wont serve up the Active Widget framework correctly? It works fine inside the main body of a page but inside an IFRAME the grid.js file just doesn't seem to execute. We can run the server on any other computer and everything works fine (all clients see everything correctly), but on this one computer, the grids inside an IFRAME don't work. What is very strange is that all clients hitting this server see the exact same thing, the IFRAME grids simple display a Javascript error "Active not defined". The grid.js file is being delivered to the browser so I know that part is fine. The grids on the main part of the page display correctly. And the same client can hit the same server software, running on any other computer, and everything displays just fine.
Any thoughts on this? I have Googled this all day and not found anything concrete. Oh yeah, I am not running this through IIS or Apache, it is a custom server written in Delphi that is serving up the pages.

On the server where it doesn't work: are you loading the main page, the grid.js and the iframe contents using urls with the same server, domain, port and protocol (http/https)?

yes, everything is loaded with relative locations.

Jim,

I would try -

- changing the name of the js file for this iframe only (grid.js->grid123.js), to make sure it is not corrupted cache somewhere. Open the file from IE cache and see whats inside. Check if iframe loads any other js file.

- playing with attributes of the script tag, for example -

<script src="grid.js"></script>
<script src="grid.js" language="javascript"></script>
<script src="grid.js" type="text/javascript"></script>
etc.

- checking which http headers are sent with grid.js file (content-type, encoding). If they are the same on this machine and those which are working fine.

I assume this is not just corrupted client because you say all clients have the same behavior.

I did that. I created a gridx.js and called it only from the IFRAME and it does get sent to the browser (I use Instant SOurce and can see what files are loaded). There are a couple of other js files loaded in the IFRAME and they work fine, it's in one of those files that the error is occuring. And also, there are more then one place in the application where I use IFRAMES and in all casses, the results are the same from that server, the grid.js file is not executed upon loading. I am using the runtime version of the file and we have not compressed the file using ZIP. I did read in many places via Google, that IFRAMES cause many issues with toolkits and application frameworks, they are not the easiest thing in the world to work with. I am assuming that there is something running on her computer that is interfering with the packets but disableing all the usual suspects did not help. I am normally damn good at tracking down bugs but this has stumped me for 3 days now. Since it is only doing this on one machine, and that machine is only used for testing, I think I will not waste any more time trying to solve it and just have her test on a remote machine that is working.

We are going to spend a little time this morning looking at the packets sent to see about the headers, it was something that I thought might be wrong. But if it was sending the wrong header for grid.js then it would send the wrong header for all js files and none of them would work, yet the others do.

Thanks everyone for your assistance. I was hoping someone had run accros this before and could say "Ah Ha! I know what's wrong!" But I guess this is a very rare thing.

I saw something similar once. The machine worked fine with 1.0, 1.0.2 but not 1.0.1. When I was trying to open grid.js on this machine it was empty. At that point I thought it's some weird virus-filtering thing - either firewall/proxy or local anti-virus but I did not prove it, so it might be something else.

If other js files work you may try playing with the content of grid.js - just put alert("hello") instead of regular content and see if this one will load. Or try removing the classes one-by-one (or by 50%) until the script will run.

Thanks,
I was going to start doing that, but that will be a lst resort. We did find some odd things looking at the packets that were related to dates. We have not yet made changes on the server to see if it helps. I'll let you know what we come up with as a solution if in fact we solve this. We might just write the machine off as being un-testable and move on since this is the only machine doing this.

OK, we found the problem. It turns out that the server has a local setting of Chineese PRC for the time. It just so happened that all of the IFRAMES that were not working all had date fields in them that needed to be displayed and apparently the Chineese PRC character set was breaking the AW library. Setting the local back to USA English cleared up the problem. So at this point we might look a little more into why it crashed AW but it's less important now that we have her up and running.

Thanks everyone...