Object.defineProperties(obj, { constructor: .. }} broken in IE8

[Krinkle]

Properties other than constructor seem to work fine. And when using Object.defineProperty directly it works fine as well.

I ran into this when using Object.create to set up a subclass prototype and restoring the constructor property afterwards:

    targetFn.prototype = Object.create( originFn.prototype, {
        // Restore constructor property of targetFn
        constructor: {
            value: targetConstructor,
            enumerable: false,
            writable: true,
            configurable: true
        }
    } );

In modern browsers (e.g. latest Chrome) without the es5-shim, targetFn.prototype.constructor === targetConstructor. But in IE8 the defineProperties call was a no-op.

// Windows 7 / MSIE 8.0 (browserstack.com)
// Blank html file with es5-shim.js and es5-sham.js (v3.4.0)

var a = {};
a.foo = 1;
Object.defineProperty(a, 'foo', { value: 3 });
a.foo;
//> 2
Object.defineProperty(a, 'constructor', { value: String });
a.constructor + '';
//> function String() { [native code] }

var b = {};
b.foo = 1;
Object.defineProperties(b, { foo: { value: 2 }});
b.foo;
//> 2
Object.defineProperties(b, { constructor: { value: String }});
b.constructor + '';
//> function Object() { [native code] }

// ^ Property was not updated

[ljharb]

IE 8 doesn't support property definitions in any way - you'll note that Object.defineProperty is in the es5-sham, which only does a best-effort attempt to shim things. In addition, please note that Object.create(null) can't work in IE 8.

Please read the readme for the caveats on the es5-sham methods.

[Krinkle]

I'm familiar with the sham principle and best-effort attempt it does.

In the library this is for we make a principle to (at the moment) only use ES5 features that can be relatively easily functionally polyfilled back to IE7. We don't use property descriptors with getters/setters, and no Object.create(null).

Property descriptors don't matter much as they're deterministic in other browsers (like strict mode). If the application depends on it, one is probably doing it wrong. It's more to get better feedback during development to avoid doing something you didn't intend. Having it just set the property value in older browsers seems perfectly possible. And is in fact what Object.defineProperty does already. It just doesn't work when triggering it via Object.defineProperties or Object.create( .., ).

I think it's reasonable to aim for consistency within the sham. Either decide property descriptors should be ignored always or used always. Or maybe only when they have a value property. I don't think the current situation was intentional and would hope it's relatively trivial to straighten out (though I couldn't find it).

[Krinkle]

Figured out why it wasn't working. In old IE, the DontEum / enumerable:false behaviour of a property is infectious and overrides it in any objects that inherits the object where such property exists.

Thus, a plain object like { constructor: 123 } yields no iterations when looped over with for-in, because the constructor property of Object.prototype is unenumerable.

See also:

• https://developer.mozilla.org/en-US/docs/ECMAScript_DontEnum_attribute#JScript_DontEnum_Bug

[Krinkle]

The fix for it has already been implemented in es5-shim.js (not sham!) for Object.keys which is subject to the same bug naturally.

[ljharb]

If you can provide a test case, I'll be happy to fix/accept a PR fixing the sham.

Whether it's reasonable or not to be able to ignore descriptors is a decision for each library, and a very subjective one - the ES shims' position on this is that if it doesn't work 100% or 0% in all browsers, it must not be in the shim.