Add Function#caller and Function#arguments to Annex B

claudepache commented 8 years ago

... because I doubt that any browser vendor would kill them.

I have written a strawman here: https://github.com/claudepache/es-legacy-function-reflection

Some notes:

Function#caller and Function#arguments are specced as configurable getters on Function.prototype rather than properties of individual functions, following Firefox's example.
Moreover, a basic realm check is performed (step 3 of GetTopMostExecutionContextIfLeakable), so that after those properties are deleted, they cannot be recovered from another realm.
As arguments.caller is not supported by any browser, I think that step 9 of CreateUnmappedArgumentsObject can be removed.
arguments.callee is currently specced in ECMA262 as unavailable for sloppy-mode functions with nonsimple parameter list. Question: Should Function#arguments and Function#caller be disabled for those functions as well?

claudepache commented 8 years ago

In fact, arguments.callee is already specced as Step 24 of CreateMappedArgumentsObject, and it was already specced in ES3. Restricting that issue to Function#caller and Function#arguments

claudepache commented 8 years ago

EDIT 2019-12-09: Modified the test functions in order to prevent PTC to be triggered, and added Safari 13 result.

Different browsers have different semantics for Function#caller.

Consider the function:

function f() {
    var r = f.caller;
    return r;
}

Consider the testcases:

// the caller is a sloppy-mode function
(function g() { 
    var r = f();
    return r;
})();

// the caller is a strict-mode function
(function h() { 
    "use strict";
    var r = f();
    return r;
})();

// the caller is a built-in function
[1,2].reduce(f);
// the following additional test may show that PTC has not eliminated reduce() in Safari:
[1,2].reduce(function f () { throw new Error; }); // and inspect the stack of the error

Here are the results:

Browser	caller is sloppy (`g`)	caller is strict (`h`)	caller is builtin (`reduce`)
Safari 9	`g()`	throw a TypeError	`reduce()` 👎
Safari 13	`g()`	throw a TypeError	`null`
Firefox 46	`g()`	throw a TypeError	`null`
Chrome 50	`g()`	`null`	`null`
Edge 13	`g()`	`null`	`reduce()` 👎

The question is: Do we pick the semantics of Firefox or the one of Chrome?

bterlson commented 8 years ago

The goal here is to specify the absolute minimum observable semantics required to run web code.

Edge 15 throws a TypeError for case h, so we should probably go with that since it's not likely to break the web.

If caller is built-in, null seems best. I'd prefer a TypeError but that seems unlikely to be web compatible?

Function#arguments and Function#caller should be disabled for functions with non-simple parameter lists (ie. not have the own properties, so look up to throwers). Spidermonkey seems to do this now so we can probably get away with this too?

littledan commented 8 years ago

I'm not sure if divergence among browsers is enough to prove that picking one of them will not cause issues for users of a particular browser. Ideally, to make a decision, we would have some more data about how often a case occurs (infrequent cases are more OK to change semantics) as we got for __defineGetter__. It would also be nice to do some analysis by searching through existing codebases to see how caller is used and examine whether any issues are apparent.

bterlson commented 8 years ago

@littledan which of the proposed semantics are you worried about? I guess the type error for accessing caller when caller is strict is most concerning. I doubt that non-simple parameter lists not supporting this is worrying from a compat perspective.

allenwb commented 8 years ago

The effect of f.caller when the caller of f is a strict mode function was specified in ES5.1: http://www.ecma-international.org/ecma-262/5.1/#sec-15.3.5.4

Note that the specified behavior was to throw a TypeError.

That was removed from the ES6 spec. after Mark Miller and I convinced ourselves that it was no longer necessary because of other ES6 spec. changes. But I don't remember the details right now. It is probably captured somewhere in bugs.ecmascript.org.

domenic commented 8 years ago

I vaguely recall us just hoping browsers would just leave that property off (f.hasOwnProperty("caller") === false).

It seems like nobody does that though, either defining a property with value null, or a throwing getter, if I am reading @claudepache's table right.

bterlson commented 8 years ago

I vaguely recall we had a different semantics prior to putting throwers on Function.prototype (and that the change came somewhat late). I wonder if making that change made it so we shoul dhave added the ES5.1 15.3.5.4 semantics back?

allenwb commented 8 years ago

It is covered in http://tc39.github.io/ecma262/#sec-forbidden-extensions

allenwb commented 8 years ago

The bigger question is what is the result of:

// the caller is a sloppy-mode function
function g() { 
    return f(0); 
};

function f(n) {
   var caller1 = f.caller;
   if (n==0) f(1);
   var caller2 = f.caller;
   if (n==0) console.log(caller1===caller2);
}

Does it log true or false? Presumably depends upon whether or not there is a single state slot in the function object. I think we talked about this at a TC39 meeting but nobody really want to put energy into fullyspecifying this highly deprecated "feature" so it didn't go into Annex B.

It probably isn't interoperable for cases like the above now. I suspect that no implementation would really want to waste time changing their implementation to make it inter-operable for such cases. What value comes from specifying it?

WebReflection commented 8 years ago

possibly no value, but that "quiz" is easy to solve. Recursion makes the caller the function itself: least surprise.

The answer is false then, and since that's unlikely real-world code, nobody gonna suffer from such answer.

It'd be worst/unreasonable practice, in my opinion, to ask twice for a fn.caller, and in the same function body, if you're expecting the same result.

Just my 2 cents

On Thu, May 12, 2016 at 12:11 AM, Allen Wirfs-Brock < notifications@github.com> wrote:

The bigger question is what is the result of:

// the caller is a sloppy-mode functionfunction g() { return f(0); }; function f(n) { var caller1 = f.caller; if (n==0) f(1); var caller2 = f.caller; if (n==0) console.log(caller1===caller2); }

Does it log true or false? Presumably depends upon whether or not there is a single state slot in the function object. I think we talked about this at a TC39 meeting but nobody really want to put energy into fullyspecifying this highly deprecated "feature" so it didn't go into Annex B.

It probably isn't interoperable for cases like the above now. I suspect that no implementation would really want to waste time changing their implementation to make it inter-operable for such cases. What value comes from specifying it?

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/tc39/ecma262/issues/562#issuecomment-218605762

claudepache commented 8 years ago

@allenwb Good point

The bigger question is what is the result of:

// the caller is a sloppy-mode function function g() { return f(0); };

function f(n) { var caller1 = f.caller; if (n==0) f(1); var caller2 = f.caller; if (n==0) console.log(caller1===caller2); } Does it log true or false? Presumably depends upon whether or not there is a single state slot in the function object.

Good point. Fortunately, it logs true in all current mainstream browsers.

What value comes from specifying it?

It is useful to make sure that implementations does not do unadvisable things; and it may be easier or safer to achieve that by a simple specification.

WebReflection commented 8 years ago

if it's about setting it up at the beginning and dropping it at the end (or restoring the previous) then true would be reasonable result, yet I don't think it makes any sense to ask for a caller down the road, specially not after a recursive call.

A non-issue to solve, probably not even needed to be specified?

On Thu, May 12, 2016 at 8:46 AM, Claude Pache notifications@github.com wrote:

@allenwb https://github.com/allenwb Good point

The bigger question is what is the result of:

// the caller is a sloppy-mode function function g() { return f(0); };

function f(n) { var caller1 = f.caller; if (n==0) f(1); var caller2 = f.caller; if (n==0) console.log(caller1===caller2); } Does it log true or false? Presumably depends upon whether or not there is a single state slot in the function object.

Good point. Fortunately, it logs true in all current mainstream browsers.

What value comes from specifying it?

It is useful to make sure that implementations does not do unadvisable things; and it may be easier or safer to achieve that by a simple specification.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/tc39/ecma262/issues/562#issuecomment-218673734

claudepache commented 8 years ago

@bterlson

Function#arguments and Function#caller should be disabled for functions with non-simple parameter lists (ie. not have the own properties, so look up to throwers). Spidermonkey seems to do this now so we can probably get away with this too?

Are you sure? I just tested this in Firefox Nightly web console:

function f(x = 1) { return f.caller }
(function g(x = 1) { return f() })(); // returns: function g()

In case there is confusion about the absence of own properties: Firefox doesn't have own properties anymore on individual functions, but it doesn't mean that the functionality is gone. Instead, all logic has been displaced inside the Function.prototype.{caller,arguments} accessors.

rossberg commented 8 years ago

In V8, these properties have a purely "best effort" implementation. Whether they work, and with what specific semantics, depends on a variety of static and dynamic factors, like optimisation levels. IOW, there is not even a consistent "Chrome semantics".

Changing this would introduce significant overhead and complexity, in particular wrt Function#arguments.

We hence see zero -- or even negative -- value in elevating these (mis)features to the standard, even if it's just Annex B. We can serve the community better by spending our resources elsewhere.

bterlson commented 8 years ago

@claudepache I am not sure! Confirmed your example is correct. I wish I had the sample I was using before as js.exe was the only one throwing on it. Alas, it is missing. I also updated today so possibly it's a recent change. Anyway, I would still hope we could not do this.

@rossberg-chromium would you agree that there is some semantics here required to run the web? If so, that is what we should spec. If not, you (and all of us) should just remove this functionality. You can always choose when to fix bugs (or, not to fix them) :)

rossberg commented 8 years ago

@bterlson, not necessarily. They are probably used primarily for debugging and other diagnostics, rather than actual programmatic logic. In that case, a best-effort implementation is still useful, despite the reliable intersection semantics being practically empty.

claudepache commented 8 years ago

They are probably used primarily for debugging and other diagnostics, rather than actual programmatic logic.

In that case, they could probably be neutered (by returning null or a fake empty Argument object) or plainly removed, as they are already inoperative for strict-mode functions and implementations provide better diagnostic tools. Some volunteer to try that?

Otherwise, if they are bound to remain, I think that a minimal specification, allowing implementation-defined behaviour at some well-guarded places if desired, is useful. For example, here are two points that could be improved relatively to the current situation:

Some implementations give unwarranted access to builtin functions through the .caller property. If we could limit leaks to sloppy-mode functions, it would be great.
Some implementations use an own property for sloppy-mode functions but not for the other ones (relying on the inheritance from Function.prototype), and that may lead to confusions:

function B() {}
var C = (function() { 
    "use strict"
    return class C extends B {} 
})()
C.arguments // will return B.arguments ... oops

rossberg commented 8 years ago

They are probably used primarily for debugging and other diagnostics, rather than actual programmatic logic.

In that case, they could probably be neutered (by returning null or a fake empty Argument object) or plainly removed, as they are already inoperative for strict-mode functions and implementations provide better diagnostic tools. Some volunteer to try that?

Given the turmoil we are seeing around tail call elimination, we might not (yet) get away with a regression like that.

At the same time, there is no good reason to encourage new code to use these features. Nor for us to waste time on them. Any useful spec text will cause both.

Otherwise, if they are bound to remain, I think that a minimal

specification, allowing implementation-defined behaviour at some well-guarded places if desired, is useful. For example, here are two points that could be improved relatively to the current situation:

-

Some implementations give unwarranted access to builtin functions through the .caller property. If we could limit leaks to sloppy-mode functions, it would be great.

Some implementations use an own property for sloppy-mode functions but not for the other ones (relying on the inheritance from Function.prototype), and that may lead to confusions:

function B() {}var C = (function() { "use strict" return class C extends B {} })()C.arguments // will return B.arguments ... oops

Yeah, but there is nothing that could be done about this other than poison pills -- which we just got rid of in ES6, and don't want back. Hence this seems like exactly the kind of issue that the spec cannot fix anyway.

Why are you saying that access to built-in callers is unwarranted? Not saying that they should be accessible, but I don't see why they must not be either.

allenwb commented 8 years ago

On May 17, 2016 5:56 AM, Claude Pache notifications@github.com wrote:

Some implementations give unwarranted access to builtin functions through the .caller property. If we could limit leaks to sloppy-mode functions, it would be great.

This is a spec. violation if the built-in is implemented via a strict ES function

rossberg commented 8 years ago

On 17 May 2016 at 15:36, Allen Wirfs-Brock notifications@github.com wrote:

On May 17, 2016 5:56 AM, Claude Pache notifications@github.com wrote:

Some implementations give unwarranted access to builtin functions through the .caller property. If we could limit leaks to sloppy-mode functions, it would be great.

This is a spec. violation if the built-in is implemented via a strict ES function

Allen, in what sense is "implemented via a strict ES function" a meaningful characterisation within the spec? How would that be observable?

claudepache commented 8 years ago

Some implementations use an own property for sloppy-mode functions but not for the other ones (relying on the inheritance from Function.prototype), and that may lead to confusions:
function B() {}var C = (function() {
    "use strict"
    return class C extends B {}
})()C.arguments // will return B.arguments ... oops
Yeah, but there is nothing that could be done about this other than poison pills -- which we just got rid of in ES6, and don't want back. Hence this seems like exactly the kind of issue that the spec cannot fix anyway.

No, something can be done, and Firefox has done it: remove those own properties on every individual functions, including sloppy-mode ones, and define "arguments" and "caller" accessor properties on Function.prototype that take different action according to the received this value.

zenparsing commented 8 years ago

At the same time, there is no good reason to encourage new code to use these features. Nor for us to waste time on them. Any useful spec text will cause both.

Plus one's aren't very helpful, I know. But +1 all the same (particularly to the second point).

claudepache commented 8 years ago

At the same time, there is no good reason to encourage new code to use these features. Nor for us to waste time on them. Any useful spec text will cause both.

Plus one's aren't very helpful, I know. But +1 all the same (particularly to the second point).

Minus ones are nevertheless useful to point to actions that people don’t want to be taken.

I have updated the proposed spec in order to allow some implementation-defined behaviour, while keeping safety and soundness for non-sloppy functions. In particular, V8 is allowed to keep its nondeterministic semantics in order to discourage their use :-)

allenwb commented 8 years ago

On May 17, 2016 8:58 AM, rossberg-chromium notifications@github.com wrote:

On 17 May 2016 at 15:36, Allen Wirfs-Brock notifications@github.com wrote:

On May 17, 2016 5:56 AM, Claude Pache notifications@github.com wrote:

Allen, in what sense is "implemented via a strict ES function" a meaningful characterisation within the spec? How would that be observable?

See https://tc39.github.io/ecma262/#sec-built-in-function-objects If a built-in is implemented using a strict node ECMAScript function object then the clause 16.1 rules about caller apply.

rossberg commented 8 years ago

Allen, in what sense is "implemented via a strict ES function" a meaningful characterisation within the spec? How would that be observable?

See https://tc39.github.io/ecma262/#sec-built-in-function-objects If a built-in is implemented using a strict node ECMAScript function object then the clause 16.1 rules about caller apply.

I still don't understand how this is observable. An implementation can always pretend that all its built-ins are exotic, regardless of their actual implementation details. AFAICS, there is no way a program can tell their "true nature".

claudepache commented 8 years ago

After reflection, I understand that putting this in Annex B may not be desirable.

However, there is still room for improvement w.r.t. the current situation, maybe by putting more constraints in Section 16.2 Forbidden Extensions. Concretely:

forbid to leak anything else than sloppy-mode ECMAScript function (functions with an [[ECMAScriptCode]] internal slot and for which [[Strict]] is false);
if an implementation choose to implement a given builtin using an ECMAScript function, it must be a strict-mode one.

And, in order to minimise API surface and avoid the issue of function objects inheriting from others, the following may be nice (implemented by Firefox):

disallow to add caller and arguments own properties on individual function objects; instead, only corresponding deletable accessor properties on Function.prototype are allowed.

rossberg commented 8 years ago

I like the first two suggestions. I'm less thrilled about the latter, because that means that all functions, including strict ones, will have these properties (even if they throw on some). That seems strictly worse than the own property approach, where they only show up on non-sloppy functions in some inheritance corner cases.

claudepache commented 8 years ago

I'm less thrilled about the latter, because that means that all functions, including strict ones, will have these properties (even if they throw on some).

This is already the case according to the current spec, because the AddRestrictedFunctionProperties() operation is applied to %FunctionPrototype%, see CreateIntrisics().

One could just kill AddRestrictedFunctionProperties() instead; but really, I don’t think that it is in any way better than the current inherit-from-sloppy-mode-function hazard.

claudepache commented 8 years ago

disallow to add caller and arguments own properties on individual function objects; instead, only corresponding deletable accessor properties on Function.prototype are allowed.

Alternatively, a getter might be installed on each sloppy-mode function, which checks its this-value and refuses to work when used as inherited. I don’t think it is better, but I don’t care much.

More importantly, currently some implementations violate the spec, as they define, on each sloppy-mode function, an arguments and a caller property, and make them as nonwritable and nonconfigurable; but yet their value does observably change over time (6.1.7.3).

claudepache commented 8 years ago

More importantly, currently some implementations violate the spec, as they define, on each sloppy-mode function, an arguments and a caller property, and make them as nonwritable and nonconfigurable; but yet their value does observably change over time (6.1.7.3).

Just opened:

evilpie commented 7 years ago

Ping, can we move this forward? Firefox has been shipping getters on Function.prototype without any problems. @claudepache @bterlson

bterlson commented 7 years ago

@evilpie sure, if it's web compatible I'm fine moving "caller" and "arguments" to proto getters.

I understand the desire to not specify actual machinery in Annex B and the biggest advantage of putting this text in Forbidden Extensions is that an implementation might one day remove these properties entirely.

I like @claudepache's 3 updates, but I wonder if the specification that built-in functions implemented in ECMAScript be strict mode functions should go in 9.3 Built-in Function Objects instead? Disallowing "arguments" and "caller" own properties and forbidding leaking of non-sloppy function state seem like fine 16.2 Forbidden Extensions additions. @evilpie thoughts? Want to write a (needs-consensus) PR?

chicoxyzzy commented 7 years ago

was arguments.caller removed only in Firefox Nightlies or it was removed from SpiderMonkey completely?

evilpie commented 7 years ago

@chicoxyzzy We completely removed arguments.caller in bug 1324208 and unless we see regressions in the wild (unlikely because it threw before), we will ship Firefox 53 (current Nightly) on 2017-04-18.

@bterlson Sorry, seems like I ignored your request. I will take a shot at documenting this.

ljharb commented 5 years ago

@evilpie any update?

evilpie commented 5 years ago

I am not working on this. Maybe @claudepache could refresh their old proposal. Firefox seems to have some more restrictions: https://searchfox.org/mozilla-central/rev/c43240cef5829b8a2dec118faff8a5e1fec6ae1b/js/src/vm/JSFunction.cpp#132-179.

We only allow FunctionDeclaration or FunctionExpression, which aren't async, generators etc. Also no methods/getters etc.

arguments.caller was completely removed, not even the poison pill remains.

claudepache commented 5 years ago

arguments.caller was completely removed, not even the poison pill remains.

(arguments.caller is out of the scope of this Issue, and is anyway dead, done and dusted per #689.)

claudepache commented 5 years ago

Firefox seems to have some more restrictions: https://searchfox.org/mozilla-central/rev/c43240cef5829b8a2dec118faff8a5e1fec6ae1b/js/src/vm/JSFunction.cpp#132-179.

We only allow FunctionDeclaration or FunctionExpression, which aren't async, generators etc. Also no methods/getters etc.

Good point. I've opened https://github.com/claudepache/es-legacy-function-reflection/issues/1.

zoobot commented 5 years ago

Is there a replacement for arguments.callee.name to get the function name from within the function in strict mode?

I want the function names to go into the log when it errors and I don't want to have to change my logger line every time I copy paste it to a new function.

Thanks

claudepache commented 5 years ago

@zoobot (new Error).stack will give the information you need for your purpose (although the format will differ among engines, as it is not standardised). — But this thread is not the proper place to discuss that issue; you may be interested in the Error Stacks proposal.

zoobot commented 5 years ago

Thanks @claudepache

I wish there was a way to just get the name from inside the function like arguments.callee.name did...

util = require('util');

function testNAME() {
  console.log(`arguments.callee.name: ${arguments.callee.name} \n`);

  console.log(`Object.getOwnPropertyDescriptor(new Error(), 'stack'): ${Object.getOwnPropertyDescriptor(new Error(), 'stack')}  \n`);

  console.log(`Object.getOwnPropertyDescriptor(new Error(), 'stack'): ${util.inspect(Object.getOwnPropertyDescriptor(new Error(), 'stack'), false, 10, true)} \n`);

  console.log(`Object.getOwnPropertyDescriptor(new Error(), 'stack'): ${util.inspect(Object.getOwnPropertyDescriptor(new Error(), 'stack'), false, 10, true)} \n`);

}

testNAME()

arguments.callee.name: testNAME

Object.getOwnPropertyDescriptor(new Error(), 'stack'): [object Object]

Object.getOwnPropertyDescriptor(new Error(), 'stack'): { value: [32m'Error\n at testNAME (/mnt/tb/TB-warehouse-automation/test5.js:7:118)\n at Object. (/mnt/tb/TB-warehouse-automation/test5.js:14:1)\n at Module._compile (internal/modules/cjs/loader.js:689:30)\n at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)\n at Module.load (internal/modules/cjs/loader.js:599:32)\n at tryModuleLoad (internal/modules/cjs/loader.js:538:12)\n at Function.Module._load (internal/modules/cjs/loader.js:530:3)\n at Function.Module.runMain (internal/modules/cjs/loader.js:742:12)\n at startup (internal/bootstrap/node.js:266:19)\n at bootstrapNodeJSCore (internal/bootstrap/node.js:596:3)'[39m, writable: [33mtrue[39m, enumerable: [33mfalse[39m, configurable: [33mtrue[39m }

Object.getOwnPropertyDescriptor(new Error(), 'stack'): [32m'testNAME (/mnt/tb/TB-warehouse-automation/test5.js:9:118)\n at Object. (/mnt/tb/TB-warehouse-automation/test5.js:14:1)\n at Module._compile (internal/modules/cjs/loader.js:689:30)\n at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)\n at Module.load (internal/modules/cjs/loader.js:599:32)\n at tryModuleLoad (internal/modules/cjs/loader.js:538:12)\n at Function.Module._load (internal/modules/cjs/loader.js:530:3)\n at Function.Module.runMain (internal/modules/cjs/loader.js:742:12)\n at startup (internal/bootstrap/node.js:266:19)\n at bootstrapNodeJSCore (internal/bootstrap/node.js:596:3)'[39m

ljharb commented 5 years ago

In that case it’s your own function, you already know the name.

zoobot commented 5 years ago

arguments.callee.name would be super useful if it was standard, as is arguments.caller.name for that matter, though I just learned about it.

I probably spend a lot of time of my life rewriting function names when I copy logs from one function to another. I don't want to have to rewrite every log line after looking at the name. Plus I am human and forget to change the name in the log so it slows down dev. I want dev to be faster. I wish I could use arguments.callee.name or have a replacement for it.

This is way faster and less prone to typos/forgetfulness logger.log('debug', arguments.callee.name ${util.inspect(opts, false, 10, true)}); than this logger.log('debug', saveToOpts ${util.inspect(opts, false, 10, true)}); to get a function name in the log when you are copying and pasting that line all over the place all day every day.

ljharb commented 5 years ago

@zoobot this seems like what you want is a new proposal, for something like function.name - I'd suggest giving https://github.com/tc39/ecma262/blob/master/CONTRIBUTING.md#creating-a-new-proposal a shot.

I'm going to hide all these comments as off topic, if you don't mind :-)

zoobot commented 5 years ago

Thanks @ljharb I will try that creating a new proposal link. Function.name exists but I don't see the point of it because you have to already know the name of the function... Not a replacement for arguments.callee.name and arguments.caller.name. :/

If you leave these comments here, it will save time for whoever searches this subject after me.

ljharb commented 5 years ago

@zoobot to clarify, i mean literally function.name, a contextual metakeyword that would only work in a function, and would work in every function.

jorendorff commented 5 years ago

Is there anything we can do to help this work land?

We got a bug report about Function caller properties last month: https://bugzilla.mozilla.org/show_bug.cgi?id=1527810

Would love to see this standardized so implementations can converge.

ljharb commented 5 years ago

I believe we next need a PR, unless i missed one farther upthread.

claudepache commented 5 years ago

We got a bug report about Function caller properties last month: https://bugzilla.mozilla.org/show_bug.cgi?id=1527810

The relevant issue is: Given that the caller of f is strict, what should f.caller do. Here is a minimal testcase:

// "don't use strict"
function g() { "use strict"; return f() }
function f() { return f.caller; }
g();

Chrome and Safari return null. Firefox throws a TypeError (and that, since long ago: I've just tested FF17 released in 2012). Both behaviours are OK, although throwing a TypeError is subjectively strictly better in the sense that it is a better incitation for 🔥ing that from their code.

Whether Firefox should change behaviour depends, I think, on how hard it is needed for web compatibility.

tc39 / ecma262

Add Function#caller and Function#arguments to Annex B #562

Some implementations give unwarranted access to builtin functions through the .caller property. If we could limit leaks to sloppy-mode functions, it would be great.