How do I stop my webpage cleanly in Firefox?

Question

I have created an IIS MVC webpage.

Users find that if they leave it open overnight it is in some "frozen" state in the morning and it has also frozen any other tabs that might be open in the brower.

Therefore, they have to kill the whole browser window and log into my webpage again.

How can I cleanly shutdown(or put into nice state) my webpage at 10PM?

I have tried the following, which works on Chrome, but not Firefox:

setTimeout(function () { quitBox('quit') }, millisTill10);

function quitBox(cmd) {
    if (cmd == 'quit') {
        open(location, '_self').close();
        window.close();
    }
    return false;
}

I am happy to leave the tab there - but put it into some kind of clean, dead state, that would not interfere with the other tabs.

I have tried to catch the error to fix it - but I have no idea what is causing it to freeze. The code below does NOT catch it:

window.onerror = function(error, url, line) {
alert('Inform please ERR:'+error+' URL:'+url+' L:'+line);
};

Fuller version:

    window.onerror = function (errorMsg, url, lineNumber, column, errorObj) {
        var stackTrace = "Not available";
        try {
            stackTrace = errorObj.prototype.stack
        } catch (e) {
            try {
                stackTrace = errorObj.stack
            } catch (e) {
                try {
                    stackTrace = errorObj.error.stack
                } catch (e) {
                }
            }
        }

        alert('Please inform of Error: ' + errorMsg + ' Script: ' + url + ' Line: ' + lineNumber
        + ' Column: ' + column + ' StackTrace: ' + errorObj + ' ST: ' + stackTrace);
    }

Answer 1

Debugging a Browser Death

Rather than looking at how to "kill" the tab, it might be worth looking at why the application is dying in the first place. Firefox is a single-process browser (currently), but it has a lot of safety checks in place to keep the process running, which means that there's a pretty short list of things that can actually "kill" it.

First off, let's cross off some things that can't kill it: Plugins like Java and Flash. These run in a separate process already (if they're running at all): So at most, if they're runaways, they'll kill themselves but the rest of the browser will still be running.

Second, you're not seeing memory warnings. Firefox is pretty good about displaying an error dialog when JavaScript consumes too much memory, so if you're not seeing that, odds are really good it's not an out-of-memory issue.

The Most Likely Causes

What that leaves is a fairly short list of possibilities:

• Browser bug (unlikely, but we'll list it anyway)
• Browser add-on/extension bug
• Infinite loop in JavaScript
• Infinite recursion in JavaScript
• Not-quite-infinite-but-close-enough loop/recursion in JavaScript

Now let's cross those off.

A browser bug is unlikely, but possible. But, as a general rule when debugging, assume it's your code that's broken, not the third-party framework/tool/library around you. There are a thousand really sharp Mozilla devs working daily to kill any bugs in it, which means that anything you see failing probably has your code as a root cause.

A browser extension/add-on bug is possible, but if you're seeing this on everybody's computers, odds are good that they all have different configurations and it's not an issue with an extension/add-on. Still, it's probably worth testing your site in a fresh Firefox install and letting it sit overnight; if it isn't broken in the morning, then you have a problem with an extension/add-on.

A true infinite loop or infinite recursion is also pretty unlikely, based on your description: That would likely be readily detectable at a much earlier stage after the page has been loaded; I'd expect that at some point, the page would just suddenly go from fully responsive to fully dead — and, more importantly, the browser has an "Unresponsive script" dialog box that it would show you if it was stuck in a tight infinite loop. The fact that you're not seeing an "Unresponsive script" dialog means that the browser is still processing events, but likely processing them so slowly or rarely that it might as well be completely frozen.

Not Quite Infinite Death

More often than not, this is the root cause of "dead page" problems: You have some JavaScript that works well for a little bit of data, and takes forever with a lot of data.

For example, you might have code on the page tracking the page's behavior and inserting messages about it into an array, like this, so that the newest messages are at the top: logs.unshift(message) That code works fine if there are relatively few messages, and grinds to a halt when you get a few hundred thousand.

Given that your page is dying in the middle of the night, I'd wager dollars to donuts that you have something related to regular tracking or logging, or maybe a regular Ajax call, and when it kicks off, it performs some action that has overall O(n^2) or O(n^3) behavior — it only gets slow enough to be noticeable when there's a lot of data in it.

You can also get similar behavior by accidentally forcing reflows in the DOM. For example, we had a chunk of JavaScript some years ago that created a simple bulleted list in the UI. After it inserted each item, it would measure the height of the item to figure out where to put the next one. It worked fine for ten items — and died with a hundred, because "measure the height" really means to the browser, "Since there was a new item, we have to reflow the document to figure out all the element sizes before we can return the height." When inserting, say, the 3rd item, the browser only has to recompute the layout of the two before it. But when inserting the 1000th item, the browser has to recompute the layout of all 999 before it — not a cheap operation!

I would recommend you search through your code for things like this, because something like it is probably your root cause.

Finding the Bug

So how do you find it, especially in a large JavaScript codebase? There are three basic techniques:

• Try another browser.
• Divide and conquer.
• Historical comparison.

Try Another Browser

Sometimes, using another browser will produce different behavior. Chrome or IE/Edge might abort the JavaScript instead of dying outright, and you might get an error message or a JavaScript console message instead of a dead browser. If you haven't at least tried letting Chrome or IE/Edge sit on the page overnight, you're potentially ignoring valuable debugging messages. (Even if your production users will never use Chrome or IE/Edge, it's at least worth testing the page in them to see if you get different output that could help you find the bug.)

Divide-and-Conquer

Let's say you still don't know what the cause is, even bringing other browsers into the picture. If that's the case, then I'd tackle it with the approach of "divide and conquer":

1. Remove half of the JavaScript from the page. (Find a half you can remove, and then get rid of it.)
2. Load the page, and wait for it to die.
3. Analyze the result:
   • If the page dies, you know the problem is still in the remaining half of the code, and not in the half you removed.
   • If the page doesn't die, you know the problem is in the half you removed, so put that code back, and then remove the good half of the code so you're left with only the buggy code in the page.
4. Repeat steps 1-3, cutting the remaining JavaScript in half each time, until you've isolated the bug.

Since it takes a long time for your page to die, this may make for a long debugging exercise. But the divide-and-conquer technique will find the bug, and it will find it faster than you think: Even if you have a million lines of JavaScript (and I'll bet you have far less), and you have to wait overnight after cutting it in half each time, it will still take you only twenty days to find the exact line of code with the bug. (The base-2 logarithm of 1,000,000 is approximately 20.)

Historical Analysis

One more useful technique: If you have version control (CVS, SVN, Git, Mercurial, etc.) for your source code, you may want to consider testing an older, historical copy of the code to see if it has the same bug. (Did it fail a year ago? Six months ago? Two years ago?) If you can eventually rewind time to before the bug was added, you can see what the actual change was that caused it, and you may not have to hunt through the code arbitrarily in search of it.

Conclusion

In short, while you can possibly put a band-aid on the page to make it fail gracefully — and that might be a reasonable short-term fix while you're searching for the actual cause — there's still very likely a lot more you can do to find the bug and fix it for real.

I've never seen a bug I couldn't eventually find and fix, and you shouldn't give up either.

---

---

Addendum:

I suppose for the sake of completeness in my answer, the simple code below could be a suitable "kill the page" band-aid for the short term. This just blanks out the page if a user leaves it sitting for eight hours:

<script type='text/javascript'><!--
    setTimeout(function() {
        document.location = 'about:blank';
    }, 1000 * 60 * 60 * 8);        // Maximum of 8 hours, counted in milliseconds
--></script>

Compatibility: This works on pretty much every browser with JavaScript, and should work all the way back to early versions of IE and Netscape from the '90s.

But if you use this code at all, don't leave it in there very long. It's not a good idea. You should find — and fix! — the bug instead.