When it should be doing this:
var theEvent = img.onload; theEvent.call(img);

Anyway, did anyone figure out a workaround for this? I’ve noticed that Safari also returns an onload event for broken images :( and I can’t reference reference it’s properties because of this bug.

In our discussion, the type of code executing is function code.

That is your assertion, not mine. You are drawing a conclusion based on an initial assumption that you are correct.
It appeared to me that this was Global code, which invalidates the rest ot that portion of your argument.

Are you suggesting that Safari is the only browser getting it right? If so, read on…

That’s exactly what I was suggesting, as you are well aware.
I presume that you have seen a program similar to our Who wants to be a Millionaire? It is well known that in the game, you must only use Ask the Audience on the easier questions - ‘collective ignorance’ trumps ‘collect intelligence’ once things get tricky.
Alternatively, do you think that either George Bush or Tony Blair are really the best people to run their respective countries?
Three against one is hardly an over-whelming majority anyway!

…of course I don’t expect you to be convinced of this,

And I don’t expect you to convince me, I expect you to convince yourself before you raise a bug report.

I’m sure you have a valid reason for presenting your example code, but one of the reasons that I have had to think hard about this is that I have never written code in this style, and don’t expect to: __proto__ etc. is there for a reason; I hope you have made that clear in your writings.

Regards, Mike

If you look at the page that is labelled as p.71 of: The ECMA-262 Spec you will see three variations on ‘Function Definition’.

All along I’ve been saying that the value of this depends on how the function is called, not how it is declared. Quoting from the spec…

From p.39:

10.1.7 This
There is a this value associated with every active execution context. The this value depends on the caller and the type of code being executed and is determined when control enters the execution context. The this value associated with an execution context is immutable.

Translation: this depends on how and where the currently-executing code was called, and what type of code is currently executing (global code, eval code, or function code). In our discussion, the type of code executing is function code.

So how is this determined for function code?

From p.40:

The caller provides the this value. If the this value provided by the caller is not an object (including the case where it is null), then the this value is the global object.

The “global object” in a browser environment is window.

Translation: when the caller doesn’t provide a value for this (i.e. the function was called as a standalone function (e.g. doAlert();), this is window. But when the caller does provide a value (e.g. value.doAlert();), this will be that value.

Not quite convinced? This is stated more formally later in the spec.

From p.44:

11.2.3 Function Calls
The production CallExpression : MemberExpression Arguments is evaluated as follows:
[…]
6. If Type(Result(1)) is Reference, Result(6) is GetBase(Result(1)). Otherwise, Result(6) is null.
7. If Result(6) is an activation object, Result(7) is null. Otherwise, Result(7) is the same as Result(6).
8. Call the [[Call]] method on Result(3), providing Result(7) as the this value and providing the list Result(2) as the argument values.

There are a lot of formal declarations to pull apart to understand this, but basically it comes down to Result(7) being caller in caller.someFunction() when MemberExpression is of the form caller.someFunction, and being null when MemberExpression is of the form someFunction.

Back to you, omnicity:

Kevin: I know that you were able to synthesise a similar construct with individual statements that worked the way that you wanted, but it was not the same as merely splitting the compound statement in two.

In this case, it is exactly the same. Starting with this:

img.onload = function() { 
  alert(this); // What is this? 
};

…if the only change I make is to declare the function with a name rather than using an anonymous function, then this is what I get:

img.onload = doAlert;

function doAlert() {
  alert(this); // What is this?
};

The only side-effect of this change is to declare doAlert as a function in the global (window context) namespace. But the fact that I assign a copy of it to onload (thereby putting that copy in img context) means that there will be no change to the way the function executes in response to the event.

To get your form, I need to make an additional change, which is to wrap the reference to the newly-declared function in another anonymous function reference:

img.onload = function() { doAlert(); };

function doAlert() {
  alert(this); // What is this?
}

With this change, doAlert is no longer in img context when it runs in response to the event. It’s the anonymous function that has img context, and it calls doAlert in the global namespace, thus causing this to be window.

…of course I don’t expect you to be convinced of this, as you seem to have a different understanding of the meaning of the syntax involved than I do anyway. Allow me to take another approach to convincing you.

Consider my code again:

img.onload = function() { 
  alert(this); // What is this? 
};

Also consider my alternative formulation:

img.onload = doAlert;

function doAlert() { 
  alert(this); // What is this? 
};

If we set this script up so that img is a reference to an HTML img element, and then assign img.src a new value (as my original code above does), then executing either of these code formulations on a range of current browsers (Internet Explorer 6, Firefox 1, and Opera 8 among others) will reveal that this is a reference to the img object on every browser except Safari.

Are you suggesting that Safari is the only browser getting it right? If so, read on…

Now consider this code:

mylink.onclick = function() { 
  alert(this); // What is this? 
};

Also consider the alternative formulation:

mylink.onclick = doAlert;

function doAlert() { 
  alert(this); // What is this? 
};

This time, make mylink a reference to an HTML hyperlink (an a element with an href attribute). When you click the link in the range of current browsers (including Internet Explorer 6, Firefox 1, Opera 8, and Safari!), either of these formulations will reveal that this is the hyperlink (the value of its href will be displayed, as that is what the toString method of a hyperlink is supposed to do).

If Safari were right in the previous case, why is it wrong in this case? Are you saying Safari is the only browser to get it right, and it only gets it right when it comes to the onload event handler of an Image object?

You can test even more generally by running this code on various browsers:

var myObject = {};
myObject.myMethod = function() {
  alert(this);
}

myObject.myMethod(); // outputs [object Object]

As you can see, this is not window, but the object that I stored in myObject. This result is consistent across all current browsers, including Safari.

And my alternative formulation still holds:

var myObject = {};
myObject.myMethod = doAlert;

function doAlert() {
  alert(this);
}

myObject.myMethod(); // outputs [object Object]

If you look at the page that is labelled as p.71 of:
The ECMA-262 Spec
you will see three variations on ‘Function Definition’.
The second one, (the first ‘FunctionExpression’), I believe is what we are discussing here. Unfortunatly, in that document there is at least a minor typo: since step two states: Return Result(2).
Which is recursive and illogical, and appears to have knocked out the formatting for the next line.

Does anyone have a correct copy of this section? There is no explanation of why this block differs from the other two, so I don’t want to second-guess the authors intentions.

Personally, I believe that any compound statement in any language should act the same way as the individual statements evaluated individually. If they don’t then it is a bug in the the language. Kevin: I know that you were able to synthesise a similar construct with individual statements that worked the way that you wanted, but it was not the same as merely splitting the compound statement in two.

I see what you’re trying to say, and it’s basically the same thing I’m trying to say — it’s just a different way of looking at things.

You’re saying: if a function is assigned as the value of an object property (”named”), then it receives the object as the value of this. But if it is just called outright (”called”), it has no object as its context and therefore this gets window as its value.

I’m saying: when a function is called as an object method (i.e. the function has been assigned as the value of any object property), it executes with that object as its context, so this is the object. But if a function is called as a simple function, then it doesn’t receive any special object as its context, so this is the window.

We’re saying the same thing, just using different terminology and a slightly different point of view.

I think the bottom line that both of you have not mentionned is that the language is interpreted as statements. As such:
var myFunc = doSomething; //1
and
var myFunc = doSomething(); //2

Are two completely different statements. The first one assigns a function ‘pointer’, or a function call ‘context’ (including possibly a closure) to myFunc, whereas the second one calls doSomething’2 and assigns myFunc the result of that function call.
This might seem trivial, but it’s essential: you can name a function without calling it. And by assigning by name you make a copy of the value of the variable (in this case a function).
Anonymous functions are also a way of naming a function without giving it a name. They do not execute the function, just describe it.

As you will notice in the examples, copying is via:
element.onclick = doSomething element.addEventListener('click',doSomething,false) element.onclick = function () {this.style.color = '#cc0000';} <element onclick="this.style.color = '#cc0000';">
and refering via:
element.onclick = function () {doSomething()} element.attachEvent('onclick',doSomething) <element onclick="doSomething()">

The first samples are all naming a function, whereas the last ones are all calling it. Except for the pesky attachEvent method which seems to not really abide by a standard way of doing things (namely copying the function ‘pointer’ instead of instancing it).

Kevin, I personally don’t using the term “method of” for these discussions. It is more like you are overriding a virtual function pointer on an object. The method is always there, it’s called “onclick”, you’re just changing the value it holds.

The ruling logic is not about being a method of, but rather the difference of naming a function versus calling it. That is, these things are not limited to object methods.

In essence, it is the onclick method that has a ‘this’ context. Not the actual doSomething function. But when you set the value of onclick to doSomething, you have given it the same context.

Anyways, my two cents.