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.
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';
break;
case 'ff':
p = 'Components';
break;
case 'op':
p = 'opera';
break;
case 'sf':
case 'gc':
case 'wk':
p = 'defaultstatus';
break;
}
return p && window[p] !== undefined;
}
And another from some kind of design firmās site:
browser = (function() {
return {
[snip]
'firefox': window.sidebar,
'opera': window.opera,
'webkit': undefined !== window.defaultstatus,
'safari': undefined !== window.defaultstatus && typeof CharacterData != 'function',
'chrome': typeof window.chrome === 'object',
[snip]
}
})();
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() {
window.defaultstatus="ok"
}
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.