Bug 34553 – arguments.callee.caller is null in JavaScript functions defined in top and called via fn.call() or fn.apply() from an iframe

• Status: RESOLVED
• Resolution: FIXED
• Component: Frames

[Christian Eager]

Created attachment 48089 [details]
Test case

Steps to reproduce
---------------
1. Create an iframe.
2. Define a function ("topFunction") in top that accesses arguments.callee.caller
3. Write a function that calls "topFunction":
  * normally: top.topFunction()
  * via call: top.topFunction.call()
  * via apply: top.topFunction.apply(this, arguments)

Results
-------
arguments.callee.caller is defined only for the normal function call.

Expected
--------
arguments.callee.caller is defined in all cases

[Christian Eager]

Created attachment 48234 [details]
Testcase

A clearer testcase than the original, which uses alert() instead of console.log()

[Christian Eager]

This bug also occurs when Function.caller is referenced.

In the testcase, top.A could be defined as:

    function A(string) {
        var passOrFail = A.caller != null ? "[PASS]" : "[FAIL]";
        alert(passOrFail + " Caller is " + string + ".");
    }

and the test would still fail.

[Andrea Giammarchi]

same happens for getters/setters, e.g.

var o = {
    exec: function exec() {
        var wtf = this.test;
    }
};

Object.defineProperty(o, "test", {
    get: function get() {
        alert(get.caller);
        return "test";
    }
});

o.exec();

Expected result: get.caller should be the function exec

Current result: get.caller is null

This happens only in WebKit ( latest nightly ) and Safari. It works as expected in every other browser.
The same thing can be reproducible via __defineGetter__ or __defineSetter__

var o = {
    exec: function exec() {
        var wtf = this.test;
    }
};

o.__defineGetter__("test", function test() {
    alert(test.caller);
    return "test";
});

o.exec();

Please fix this stuff and consider to put caller in ES5 specs since it is extremely important ( and you have it internally for scope resolution reason ), thanks.

Best Regards,
    Andrea Giammarchi

[Oliver Hunt]

call and apply are native functions so caller is meant to be null (it's technically a bug that apply/call don't break the lookup when done directly)

[Andrea Giammarchi]

Oliver please check my comment before you mark it as a bogus since there is no explicit call or apply ( maybe implicit behind the scene, I need to investigate in WK source code )

https://bugs.webkit.org/show_bug.cgi?id=34553#c3

Thanks,
    Andrea Giammarchi

[Oliver Hunt]

ES5 defines the "caller" property as throwing for strict mode functions.  It leaves non-strict mode behaviour undefined, but in that case old behaviour applies -> if the caller function is a native function then it is reported as null.

getters and setters are an entirely different issue.

[Andrea Giammarchi]

which means I should open a new bug for non "use strict" case? I'll do it now then.

[Oliver Hunt]

(In reply to comment #7)
> which means I should open a new bug for non "use strict" case? I'll do it now then.

?
the non-strict behaviour is as expected.  We don't currently support strict mode.

You'r comments however are referring to getters and setters which have a completely different set of semantics.

[Andrea Giammarchi]

Please check bug 45480 then, thanks.

https://bugs.webkit.org/show_bug.cgi?id=45480

[Alexey Shvayka]

(In reply to Christian Eager from comment #0)
> Created attachment 48089 [details]
> Test case

Christian, thank you for detailed report and nice test case!
As of 2021, all major browsers [PASS], including Safari TP 123.
However, there is an intent not to expose cross-realm callers (see step 12 of https://github.com/claudepache/es-legacy-function-reflection/blob/master/spec.md#get-functionprototypecaller).
Until then, I am adding the test case as part of https://bugs.webkit.org/show_bug.cgi?id=225277.