Question

This is a tricky problem which has had me scratching my head for a few days.

I’m working on a project which involves taking an ten year old web application and reworking it as a single-page application. The application is huge – the time we have to work, quite tight, so some shortcuts had to be made.

Overall, however, I’m quite impressed with how far we’ve come, as we’ve had to overcome some interesting technical hurdles.

One involved clearing all custom window variables. Since we’re dynamically reloading different pages of the application, we need to clear all custom variables so we don’t get conflicts. What we do is firstly, load the base bootstrap of the application and save all the properties on the window object in an array.

Then, before we load each new page, we loop through the window properties and clear all the objects that aren’t in our saved array (taking the window state back to before the page was loaded).

Now, this works fine in all the browsers we’ve tested except for IE7 and IE8 (which both need to be supported). The issue seems to be that global variables don’t always seem to register on the window object.

Does anyone have any insight onto this problem? Any idea how to tackle for this IE7?

Any info will be appreciated.

EDIT:
On bootstrap load we do this:

for (i in window) {
   this.globalVars[i] = 1;
}

And then when we load a new page (via AJAX), we do:

for (i in window) {
   if (!this.globalVars[i]){
       window[i] = undefined;
   }
}

FINAL SOLUTION:

In the end the easiest fix given the limited time was to simply change all variables defined as var x; to var x = null;

There was another solution I found, however. There was a small library here which I used as a starting point for an alternate solution: http://www.thomasfrank.se/global_namespace.html

It’s not perfect (may need some tweaking to make it a little more stable, like adding a try-catch block around the AJAX call for example so that cross-domain scripts don’t crash it). The way it works is that all external scripts files and internal scripts are parsed through, extracting a ton of words which can then be used to clear properties from the window object.

We actually experienced something very strange – this script wasn’t properly picking up a lot of our variables… It turns out that it uses document.scripts to get all the loaded scripts on the page to be able to loop through them and parse them. The issue is that jQuery doesn’t load external pages on the page in that way. What it does is simply pass the code to exec from what I know. As such, no script tag is actually added to the page.

The fix for this is to parse the raw AJAX response and store a reference to all the script tags (as well as, I suppose, extract the inline scripts) and then modify the library to be able to handle these files. This should work but all this processing going on was too scary for speed reasons – finding that we could simply do a search & replace on all variable definitions and have most of the job without the requirement of copious amounts of work for each page load made it obvious which path we should take.

Answer 1

As far as I can tell, if you want this to be a solution to “quickly” ensure that 100% of all global-variables are reset, and this is compatible with oldIE, you’ll basically have to save the initial values of window/document properties which you modify… …AND hand-write null values for each global on a particular page.

If you want it to be 100% accurate, fully BC with old-IE… AND without refactoring of any kind… …that’s what I forsee in your future.

Your company sounds like a few I know (I’m sure everyone knows a few) —
“Miracles can happen in no time for no money, if we tell the devs to make them happen.”

If it came down to it, I would have picked through and fixed the global var issue by hand (or wrote a parser to find globally-scoped variables on a page — or at least point to where they might be).
The rest of the framework could be hacked together… …though, I’d still end up wanting to sandbox pages, if at all possible (would make the whole state thing moot, for starters, once there were no globals).

But yeah… …either null each page’s globals by hand, or fix them, by hand, to apply them either as window[key] (if absolutely necessary), or as formerly_global_properties[key] or in an entirely different scope, enclosed in a function.
All will be backwards-compatible, and all will be immeasurably awful.

But hacking the workaround like this and hacking the globals into something workable which can then be worked with/maintained at a later date are both going to be roughly the same amount of work, right?