600693 - Harmony proxies: this in function proxy construct trap not bound to undefined

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect, P2)

Description

[Tom Van Cutsem]

The |this| binding inside a function proxy's construct trap is currently bound to the global object. According to the harmony:proxies spec, the construct trap of a function proxy, if provided, is always called with |this| bound to undefined.

var f = Proxy.createFunction({},function(){},function() { print(this); })
new f();

prints: [object global]
expected: undefined

Comment 1

[Jeff Walden [:Waldo]]

This is a half-dozen-line-fix in JSProxyHandler::construct once bug 514570 lands (imminently).

Comment 2

[Andreas Gal :gal]

we will wait with this until bug 514570 is fixed

Comment 3

[Brendan Eich [:brendan]]

(In reply to comment #2)
> we will wait with this until bug 514570 is fixed

Fixed now -- suggest you as assignee ;-).

/be

Comment 4

[David Mandelin [:dmandelin]]

Unblocking assuming we don't need full Harmony proxies for 2.0.

Comment 5

[David Bruant]

Still a bug in FF4b11

Comment 6

[Brendan Eich [:brendan]]

This works:

var f = Proxy.createFunction({},function(){},function() { "use strict"; print(this); });

new f(); // undefined

at least if you are up-to-date on tm tip (may require fix for bug 636364). Is there really a bug here given how we have prototyped proxies in the pre-harmony ES5 world?

/be

Comment 7

[Brendan Eich [:brendan]]

IOW, Harmony is a super-set of ES5 strict, but ES5 strict is neither a subset nor a superset of ES5 or "JS in reality". Using proxies in ES5 non-strict or JS in reality means you get non-Harmony, non-strict |this| binding, at least for |new|.

Could be this is still a bug, but at least it has a workaround.

/be

Comment 8

[Tom Van Cutsem]

I don't feel too strongly about this. The proxies spec. is written for Harmony, so didn't take ES5-non-strict semantics into account. I agree the current behavior makes sense for "JS in reality", but it does make the FF4 Proxy implementation slightly less future-proof.

Comment 9

[Brendan Eich [:brendan]]

Future-proofers should "use strict" early in their code and all should be well, I hope -- agreed?

/be

Comment 10

[Mark S. Miller]

I do not understand what the bug is. From the two code samples above:

    var f = Proxy.createFunction({},function(){},
                                 function() { print(this); })
    new f();

    prints: [object global]
    expected: undefined //[1]

and

    var f = Proxy.createFunction({},function(){},
                                    function() { "use strict";print(this); });

    new f(); // undefined

are not only consistent with the specified behavior, they are required by the specified behavior, where the construct trap's [[Call]] is invoked with it's this-binding bound to undefined. If the construct trap is a non-strict function, then its [[Call]] behavior must coerce undefined to global. If it is strict, then not. That seems to be exactly what's happening above.

Am I missing something? How could any other behavior be correct?

Comment 11

[Tom Van Cutsem]

Ok I discovered the source of confusion. All this time, I was under the impression that the value of |this| in the construct trap was independent of the strictness of the construct trap (i.e. always |undefined|). Reading MarkM's reply, I went back to look at both the proxies spec and the ES5 spec. Long story short: as MarkM indicates, the current behavior is correct, and this bug can be closed.

Full detail: in the proxies spec (<http://wiki.ecmascript.org/doku.php?id=harmony:proxies_semantics#detailed_semantics_of_additional_behavior_for_function_proxies>), when [[Construct]] is called on a Function Proxy, step 5 calls the [[Call]] method of the trap, passing |undefined| as the |this| binding. Control then transfers presumably to a built-in [[Call]] method, which according to ES5 13.2.1 establishes a new execution context. ES5 10.4.3 then further states that |this| is then bound differently depending on the strictness of the called function. I had hitherto thought it was the caller's job to do the |this|-coercion, which is why I though |this| was unconditionally |undefined| for the construct trap.

I will update my test suite accordingly.