---
title: "The Page That Said `undefined`"
canonical: https://dxdev.com/blog/2026-05-28_page-that-said-undefined/
datePublished: 2026-05-28
---
Some people using a small diagnostic page were handed the word `undefined` instead of the address the page was built to show. The page came back normally, with no crash or blank screen, so the wrong answer could sit there looking respectable while it cost time to find.

I had not started with a broken-looking page. I had started with a simple job: during a change in how visitor addresses reached the site, the page needed to choose the first real answer from three possible places. If the first place had nothing, it should try the second. If that had nothing, it should use the last one.

That sounds like choosing the first ripe apple from three bowls. An empty first bowl should lead you to the next bowl.

The first thing I tried was putting the three choices into one short line and turning the final result into text. I expected that one step to make the answer safe to display. It did not. That conversion happened too late. The page had already picked the wrong thing before it was turned into words.

The old technical name here is **JScript**, an older kind of JavaScript used by this page. In that environment, asking for a missing value did not give me an empty answer. It gave me an empty container.

That distinction sounds fussy until you picture an empty jar on a kitchen counter. The jar has nothing in it, but it is still a jar. If someone asks whether there is *something* on the counter, the answer is yes. The program made the same mistake. It saw the first container, treated it as something worth choosing, and never checked the second or third place where a real answer might be waiting.

When the page finally turned that empty container into text, it did not print a blank. It printed the literal nine-letter word `undefined`.

That is why the bug was so slippery. A basic check could see that the page loaded. The response was successful. There was ordinary-looking text in the body. Nothing announced itself as broken. But for the visitors who needed the fallback path, the page was confidently telling them something that was not true.

I had also been misled by a good piece of shared code. Elsewhere, there was one small routine meant to solve this exact problem. Before it chose among the three possible values, it cleaned each one separately. An absent value became a truly blank answer. A blank answer does not get picked, so the routine naturally moved on to the next possibility.

That shared routine had been working. The three pages that failed did not use it. Each had a copied version of the same idea, with one tiny difference: they chose first and cleaned later.

This was not a dramatic outage. No alarms were needed for a page that technically kept working. The cost was quieter and more familiar. It cost investigation time because the screen looked healthy. It cost patience because a normal response had to be treated as suspicious. And it meant three separate pages, including administrative work, could show the wrong thing before the pattern was clear.

The first repair was not to make the word `undefined` disappear. Hiding it would only have made the page quieter. The real repair was to make each possible answer empty or usable before the page chose among them. Then a controlled request through every affected path returned a real value instead of the wrong word.

That check mattered. Reading a changed line of code and nodding at it is not the same as asking the page the question it must answer in real life.

The larger job came after the visible fix. I searched for other copies of the same shortcut. The trouble was never just one page. The trouble was that a shared, safer recipe and several hand-copied recipes had drifted apart. The old shared routine was protecting itself. The copies were not.

There is a small lesson here that has nothing to do with visitor addresses. A thing that works in one place can give false comfort if the working version has one quiet protection that the copies lack. A spreadsheet, a form, a customer email template, or a website page can all have this problem. The trusted version is not proof that every look-alike is safe.

The empty container that started this was never the villain. It was doing exactly what an empty jar does: existing, taking up a slot, answering "is something here" with yes. The bug was never that JScript lied. It was that two pages asked a container whether it was ripe, and one asked whether it was there at all, and only one of those questions was the right one to ask before a visitor's address got printed to a screen.