I used to use an extension in my browser called ForecastFox to give me a heads-up on upcoming weather. I never liked that it used accuweather.com for its forecasts, and I always wanted finer control over a million things, but it was pretty handy. I finally had to get rid of it, though, because it would sometimes get stuck in a state where it was trying to update its info, and it became a CPU hog. Frustrating, but oh well.
These days I get my forecast from channel 9’s site, a poorly designed site but usually a fairly reliable forecast inasmuch as Syracuse has such a thing. But when there are severe weather alerts their site is useless, so in those situations—or when I want a ten-day forecast, as I sometimes do—I turn to the Weather Channel’s site, weather.com. Even though they do the stupid naming-winter-storms thing.
The other day we had some wind advisories, so I headed over to weather.com—and encountered a crapload of blank gray boxes. No real content at all, except for a few menu headers. This was the result of a content loading script gone horribly wrong. It took very little time to find the culprit: A script on the site was trying to use my browser’s geolocation feature, which is disabled, and as a result that kept all the other scripts on the site from running. (As of this writing, it still isn’t fixed.)
As a programmer, I know what it’s like to make a big mistake, but a mistake of this magnitude from a site with a major online presence like that one—and one would assume multiple developers—is really, really inexcusable.
In my case, the value of navigator.geolocation is null. That’s what’s causing the script, which doesn’t check for that case, to choke. And when it chokes, all the subsequent scripts fail, because they didn’t put in precautions against this predictable scenario.
This is bad Web development. Again I know how easy it is to make a mistake, to miss something in testing, and even to be blindsided by the way one browser does something differently. But this seems like it should have been a very, very avoidable case, especially given the manpower and budget involved. Most properties of the navigator object should be considered iffy as a general rule, especially if you take into account that the property in question is the kind of thing a user might disable.
I reported the problem late Monday night. I finally got a response today that their development team is looking into it. In spite of the fact that other users noticed this days before I did and they too discovered the “solution” (re-enabling geolocation), this has gone unfixed in all that time. I would tend to think feedback along the lines of “Your site isn’t working at all for some people” would be triaged a little higher than that.
As a man more than capable of making mistakes myself, my usual inclination is to cut them some slack, but we’re talking about a trivial fix to an issue that they should have seen coming, with the resources to act on it right away. It’s just not excusable for the problem to have dragged out this long.