deleting window properties
Seems like there’s really something special about window and document objects in IE. Just as with iterating over window properties, there seems to be some weirdness about deleting the properties in window DOM object.
In IE, deleting a custom window property doesn’t work. The following code is fully ECMAScript compliant.
-
window.p = 'VAL';
-
delete window.p;
But it throws an exception in IE: Object doesn’t support this action. The same action works on custom objects:
-
var o = {};
-
o.p = 'VAL';
-
delete o.p;
Just like with iterating over properties, it seems as if IE treats window like a special object, and it’s custom properties as something out of reach for certain actions. So I’ve come up with a solution to delete properties that works on all tested browsers:
-
try {
-
delete obj.prop;
-
}
-
catch (e) {
-
obj.prop = undefined;
-
}
You can test this here. This issue is present even in IE8, which is supposed to be much better with standards, but this example clearly shows that some very basic behavior is still missing from their Javascript engine.
Although IE JS engine is buggy setting global variables is evil and moreover deleting them is even worse.
Try to use namespace (object).
What’s your use case for this? How did you discover this?
window.p isn’t the horrible kind of a global variable. Yes, it’s available globally, but it’s set directly onto an object (window) and therefore has its place (namespace if you will). This differs significantly from setting just p = 34; anywhere, because in that case the visibility is determined by the scope.
I found this out when I was developing our advertising javascript code (the so-called invocation code). There, the user sets some variables, such as:
httpool_publisher_id = ‘1234567890′;
httpool_color_border = ‘#f0f0f0′;
etc.
And then includes our ad-serving javascript, which serves a single ad block with the predefined configuration.
But not all of these variables are required. When a variable isn’t set, the default value should be used. But in order to detect which isn’t set, I have to unset all of them after initializing the ad block, otherwise the values might leak into the next block — by not being set in the invocation code of the next block.
It’s a very specific case and I can’t really resort to namespaces, because it’s user-land code and an industry standard.
Well, I sort off agree with you, it’s industry standard, because it’s simple, but it is also simple solvable with objects:
httpool = {size:1};
ad(httpool);
httpool = {size:2, border: “red”};
ad(httpool);
These are two different object so you don’t need to unset values when checking for property existence.
If I borrow jQuery’s extend function your ad function would look like:
defaults = {
size: 1,
border: “blue”
};
function ad(options)
{
options = jQuery.extend({}, defaults, options);
options.size…
options.border…
}
P.S.
Just crossed my mind, instead of unsetting values just set default ones
Yes, that’s a good example of how it could be done, but alas, the code we’re using is out in the wild, we’d have to support the current model for backwards compatibility, and it would take a lot of time before everybody would change to the new model (we may be talking years here; we already changed a little thing 2 years ago, and some users still haven’t switched). This is one of those things where quick decisions, based on what’s used elsewhere, come back to haunt you years later.
As for setting default values instead of unsetting variables, it’s a good idea, and will think about it. It should work in theory, but depends on how everything else in our JS works. Also, unsetting variables makes sure our ad blocks don’t leave any traces behind, so other javascripts are unable to read these values, so it acts as a security measure as well. But as I said, I’ll think this through the next time I touch this. Thanks for the idea.