`with (scopeProxy) { foo() }` leaks scopeProxy if foo mentions `this`.

Typing valueOf() into the evaluator shim playground (demo/index.html) and hitting the Evaluate button causes the error

please report internal shim error: unexpected scope handler trap called: ownKeys

Unlike other surprising scopeProxy traps, this does not look like an engine bug. We see identical symptoms on Brave, FF, and Safari.

[edit by @kriskowal 2020-08-12:]

Actions needed (to be independently tracked, and this issue closed)

• Create a specification proposal that introduces a hiddenWith symbol that with would respect.
• Document this known-limitation of SES-shim, barring eventual engine support for a hiddenWith symbol.
• Confirm that absent hiddenWith, revealing the ScopeProxy does not break containment.

[allenwb]

(grr…it’s too easy to accidentally loose/close a github tab with an unsaved text entry field…trying again)

This should be easy (at least at the ECMA-262 spec. level) to fix. Object Environment Records already have a specification mechanism that controls whether or not they make their backing object available for inclusion in resolved References. This is controlled by the setting their withValue to true. With statements normally do that for all with objects. What we need to do is not set withValue to true when the with object is a ScopeProxy.

There are various ways this might be done in the spec, but I suggest doing all the work in with statement evaluation. Specifically we need to put a “not a ScopeProxy” guard on step 5 which currently unconditionally sets withValue.

What does the guard look like? We really don’t want to build knowledge of a specific ScopeProxy definition into this level of ECMA-262. Instead, I suggest we define a new well-known symbol named @@hiddenWith. The guard would be: HasOwnProperty(obj, @@hiddenWith) is false. The definition of ScopeProxy (its proxy handler) would ensure that they always report that they have a @@hiddenWith own property. That’s it!

Actually updating implementations to do this is probably not quite so simple, I assume that they don’t have anything that exactly corresponds to an Object environment record with a withValue flag. But I suspect that adapting an implementation to conform to this updated specification would be a modest effort—and well worth it.

[allenwb]

I left out of my redo: this ECMA-262 specification change appears be backwards compatible with all existing ES code.