A historical look at lowercase defaultstatus

08 Mar 2019

The other day I was doing some research on DOM methods and properties that Chrome implements, and has a usecounter for, but don’t exist in Firefox.

defaultstatus caught my eye, because like, there’s also a use counter for defaultStatus.

(The discerning reader will notice there’s a lowercase and a lowerCamelCase version. The less-discerning reader should maybe slow down and start reading from the beginning.)

As far as I know, there’s no real spec for these old BOM (Baroque Object Model) properties. It’s supposed to allow you to set the default value for window.status, but it probably hasn’t done anything in your browser for years.

image of some baroque art shit

Chrome inherited lowercase defaultstatus from Safari, but I would love to know why Safari (or KHTML pre-fork?) added it, and why Opera, Firefox or IE never bothered. Did a site break? Did someone complain about a missing status on a page load? Did this all stem from a typo?

DOMWindow.idl has the following similar-ish comments over the years and probably more, but nothing that points to a bug:

This attribute is an alias of defaultStatus and is necessary for legacy uses. For compatibility with legacy content.

It’s hard to pin down exactly when it was added. It’s in Safari 0.82’s kjs_window.cpp. And in this “old” kde source tree as well. It is in current KHTML sources, so that suggests it was inherited by Safari after all.

Curious to see some code in the wild, I did some bigquerying with BigQuery on the HTTPArchive dataset and got a list of ~3000 sites that have a lowercase defaultstatus. Very exciting stuff.

There’s at least 4 kinds of results:

1) False-positive results like var foo_defaultstatus. I could re-run the query, but global warming is real and making Google cloud servers compute more things will only hasten our own destruction.

2) User Agent sniffing, but without looking at navigator.userAgent. I guess you could call it User Agent inference, if you really cared to make a distinction.

Here’s an example from some webmail script:

O.L3 = function(n) {
    switch (n) {
        case 'ie':
            p = 'execScript';
        case 'ff':
            p = 'Components';
        case 'op':
            p = 'opera';
        case 'sf':
        case 'gc':
        case 'wk':
            p = 'defaultstatus';
    return p && window[p] !== undefined;

And another from some kind of design firm’s site:

browser = (function() {
    return {
        'firefox': window.sidebar,
        'opera': window.opera,
        'webkit': undefined !== window.defaultstatus,
        'safari': undefined !== window.defaultstatus && typeof CharacterData != 'function',
        'chrome': typeof window.chrome === 'object',

3a) Enumerating over global built-ins. I don’t know why people do this. I see some references to Babel, Ember, and JSHint. Are we making sure the scripts aren’t leaking globals? Or trying to overwrite built-ins? Who knows.

3b) Actual usage, on old sites. Here’s a few examples:

<body background="images/bvs_green_bkg.gif" bgcolor="#598580" text="#A2FF00" onload="window.defaultstatus=document.title;return true;">
<body onload="window.defaultstatus='Индийский гороскоп - ведическая астрология, джйотиш онлайн.'">

This one is my favorite, and not just because the site never calls it:

function rem() {

OK, so what have we learned? I’m not sure we’ve learned much of anything, to be honest.

If Chrome were to remove defaultstatus the code using it as intended wouldn’t break—a new global would be set, but that’s not a huge deal. I guess the big risk is breaking UA sniffing and ended up in an unanticipated code-path, or worse, opting users into some kind of “your undetected browser isn’t supported, download Netscape 2” scenario.

Anyways, window.defaultstatus, or window.defaultStatus for that matter, isn’t as cool or interesting as Caravaggio would have you believe. Thanks for reading.