I'm not sure quite what the problem is, although, it seems related to calling a base class method from a subclass. This has been tested with r34254.
See URL for test case.
* See http://126.96.36.199/search?q=cache:u4k4sf4FNswJ:dev.mootools.net/ticket/711+Webkit+mootools+class&hl=en&client=safari&strip=1
If the problem is caused by a change in behaviour of WebKit, then it's definitely preferable to file a bug report in WebKit's bug tracker as it's often an unintentional change.
I think we need a reduced test case to make headway on this issue.
Created attachment 21453 [details]
Reduced test case
The problem is that arguments.callee.caller is returning null when the function is called via Function.apply.
Created attachment 21454 [details]
this test case shows that caller skips native function callers
The problem is that Machine::retrieveCaller() calls getCallerFunctionOffset(), which stops when it sees a null codeBlock. In that case, we want to check the prior call frame instead.
Created attachment 21571 [details]
Patch in progress
Here's a patch in progress. It fixes the bug, but the code is somewhat ugly. I made it by inlining the calls to getCallFrame() and getCallerFunctionOffset() and modifying the logic to handle this special case. I am not quite sure of the necessity of the second if (!exec) at this hour.
Interestingly enough, the patch I posted works on the two test cases but not the URL linked in the bug. I'll try to figure out the difference.
Created attachment 21581 [details]
So, it turns out that the earlier reductions for a different bug. Here is a new reduction of the bug, working from the MooTools source. It can probably be reduced further, but I wanted to dump it on Bugzilla in case I have to do something else later.
There is no immediate native caller that is the problem, and all of the callers of the functions leading up to the one that is the problem are the same in Safari 3.1 and ToT.
Sorry, when I said that ToT is the same as Safari 3.1 on all of those cases, I meant ToT with my patches. The call chain is as follows:
initialize() in Class:
Safari 3.1 and ToT agree that the caller is null.
initialize() in ExampleClass.Inherited:
Safari 3.1 says that the caller is initialize() in class, whereas ToT says that the caller is null. My patch fixes this, because this function is called by using apply in the body of initialize() in Class.
self.parent() in Extends:
Safari 3.1 says that the caller is initialize() in ExampleClass.Inherited, whereas both ToT and ToT with my patch say that the caller is null.
Thus, the problem is not directly due to a native call. I'll try to reduce it further and figure out what's going on.
Created attachment 21582 [details]
Here is a further reduction of the bug. It has two cases to demonstrate that the native call messes up the later attempt to get a JS caller.
The problem is this code in
Register* callerCallFrame = (*registerBase) + callerOffset;
if (!callerCallFrame[Machine::CallerCodeBlock].u.codeBlock) // test for eval frame
It is testing whether the caller is an eval frame by testing whether the caller's caller has a codeBlock, but this also happens when the caller's caller is native code. Removing the code fixes the bug, but causes an assertion failure when the caller is eval code. The easiest fix is probably to add a CodeType field to CodeBlock.
Created attachment 21584 [details]
Here's a fix. I won't put it up for review until I write some layout tests.
Created attachment 21585 [details]
Proposed patch with test
Comment on attachment 21585 [details]
Proposed patch with test
Landed in r34457. I will make a new bug for the issue with a direct native caller.