Maintaining legacy web sites

Home / Maintaining legacy web sites

Over the weekend, I had an interesting experience updating an old, legacy website that uses ASP. ASP is interesting, but the more interesting thing is that many of these old applications rely on specific browser modes or default to “quirks” mode.


The update was the result of the site breaking in newer browsers. Our customer machines were updated to use IE11 and, fortunately, Microsoft has started to retire some of their quirky stuff that only worked in IE. But, with that retiring and changing of behavior, sites can stop working.

A notable omission, for example, in IE11 “edge” mode is that VBScript no longer works. For the page that I was updating that used a VBScript Msgbox, JavaScript’s “confirm” was a good enough replacement. Microsoft at least mentions this and it’s easy enough to discover with a Google search:

https://msdn.microsoft.com/en-us/library/dn384057(v=vs.85).aspx

The VBScript MsgBox is interesting. The usage in this case was to display a Yes/No prompt, so there was a single method called YesNo. The MsgBox returns a value of 6 if the “Yes” button is pressed. You can see the documentation for it here:

https://msdn.microsoft.com/en-us/library/sfw6660x(v=vs.84).aspx

Rewriting the YesNo is pretty straight-forward with confirm() like so:

function YesNo(msg1, msg2) {
    var returnVal = confirm(msg1);
    if (returnVal) {
        return 6;
    } else {
        return 7;
    }
}

Bear in mind that these ASP pages do not have a DOCTYPE set. Much to my chagrin, setting them to anything, thus forcing them to not render in quirks mode, causes the layouts to break. Since my time investment in these updates was limited, I couldn’t change their document/rendering mode. But, another weird behavior was that button tags no longer fired their click events. What the what?

So, having simple HTML like this no longer worked:

<button onclick="javascript:someMethod()">Label</button>

Changing this to an HTML input made it work, though:

<input type="button" onclick="javascript:someMethod()" value="Label" />

I can only surmise this is, again, due to some change in IE’s dealing with quirks mode. At any rate, it was a breaking change that had to be dealt with.

Another interesting thing that I observed, and it may have been normal JavaScript behavior, was that accessing a form element’s children by name could return either an HTMLCollection, NodeList, or single Element. This is one of those things for cross-browser support that users of jQuery probably take for granted. I found this little bit of innocuous code in the page:

document.someForm.someElementByName.style.visibility = "hidden";

The problem, though, was that there were two elements with the same name in the form. One was a hidden input used for posting back when the primary, user interactive element was disabled. This is pretty common since disabled inputs are not included in form posts. But, this piece of code was silently throwing an exception. I only witnessed it due to noticing the exception in my debug tools. The fix is pretty straight-forward though. We have use JavaScript prototyping to assign class-level methods to detect when the item being accessed is a collection. Note that the collection type can vary by browser:

Element.prototype.isNodeList = function() { return false; }
NodeList.prototype.isNodeList = HTMLCollection.prototype.isNodeList = function(){ return true; }

With those prototype methods in place, we can then handle the style changes in a non-breaking, exception-free way:

if (document.someForm.someElementByName.isNodeList()) {
	for (var i = 0; i < document.someForm.someElementByName.length; i++) {
		document.someForm.someElementByName.item(i).style.visibility = "hidden";
	}
} else {
	document.someForm.someElementByName.style.visibility = "hidden";
}

Sure, this could be written even more succinctly with jQuery, or some other newer JavaScript frameworks, but sometimes when fixing older legacy sites, that luxury is not available.

One other thing that’s interesting with these old legacy ASP pages is that it’s obvious that the developers who wrote the JavaScript did not start with a JavaScript background. I find that text formatting is out of whack and lines of code are not even terminated. Over the years, I’ve noticed that lack of line terminators is highly prevalent in VBA/VBScript, VB.NET, and other VB based languages derivatives.

Sometimes maintaining legacy web sites is an eye opener. They can be like a can of worms or like a box of chocolates – you never know what you’re going to find.

Leave a Reply