[FIX] Prevent setting of __nextSuper on frozen objects

[rondale-sc]

This fixes #5324

If the object is frozen we should not modify it. This includes the setting of __nextSuper which is used by _super.

[stefanpenner]

this seems like a good work around, but since since a somewhat recent fix to super, we are actually apply this wrapper to methods and objects that we where not before.

I am slightly concerned that this will be even more of a performance drain then the current super is...

@mixonic any thoughts?

[rwjblue]

Object.isFrozen does not work in IE6 - IE8.

http://kangax.github.io/compat-table/es5/

[rondale-sc]

@rwjblue So should we go with this solution we should polyfill Object.isFrozen and Object.freeze?

Been talking about this a bit and I'm not entirely certain why we are setting super then applying the function then resetting super to sup (which could more accurately be called originalSuper). This seems like we are putting a bandaid on a gunshot wound.

Also, I thought ie6-ie8 test suite would run on travis. Is that not correct?

Found a bit more context from #3683. Getting a better understanding of what is going on here. I have confirmed that contains worked in v1.4.0 and not on master.

This is interesting to me because this._super was still being modified in v.1.4.0 but did not trigger the error (which is the whole point of this PR ^_~). So trying to find out what changed between then and now.

So far I've been focusing on makeCtor and the o_defineProperty polyfill which both seem to have changed around this. Hopefully I'll have more information soon.

[mixonic]

@stefanpenner can we stash __nextSuper on meta of the object instead of on the object? This would avoid the mutation.

[rondale-sc]

@mixonic where would that happen? (tryin' to keep up. :)

[stefanpenner]

@mixonic so currently we are super wrapping literally everything. Which means to store on the meta would mean to first create a meta for everything and this just continues to slow down our method calls.

I wonder if the older functionality was actually with less caveats then this one..

[mixonic]

@stefanpenner only what has a possible _super is wrapped. The reason contains is problematic is that it is provided by Enumerable, then replaced by Array.

A few options:

• Creating a meta for every array is definitely not good. However, creating a meta for anything that uses _super, then re-writing the Array to mixin some base of Enumerable that doesn't cause super wrappers to trigger seems reasonable. I can do this regardless, but after that maybe meta is a more reasonable solution.
• I doubt we use defineProperty to avoid triggering an exception on frozen objects, and it is slow so not a great solution anyway.

For now I can fix the contains triggered issues on arrays by using a mixin that doesn't trigger any wrappers. I'd like to explore using meta more, but carefully.

[jamesarosen]

I don't know whether you've already considered this, but isSealed might be good to check as well. If the object doesn't already have the __nextSuper property, then even a sealed, unfrozen object will throw an exception on set.

[stefanpenner]

this may be fixed by #5444
@mixonic c/d?

[mixonic]

Ignoring sets of __nextSuper on frozen objects is not a viable option. It would mean _super behaved differently on frozen and normal objects.

Closing in favor of #5464

[mixonic]

@rondale-sc thank you for the research and effort! @stefanpenner's commit buys us some time to figure out the real cause.

[jamesarosen]

It looks like I was wrong about Object.seal. It prevents extension, but doesn't cause an exception, so won't cause a problem here.