Right now it does not, and I believe it should.

In fact, perhaps WebIDL should talk about it when calling callback functions?  Not sure on that one....

Yeah, WebIDL probably needs to do something here too.

heycam, is this something that's possible to do? Should you provide me a hook I can do, or something? Or maybe move a bunch of this scripting infrastructure to WebIDL?

I would prefer it if we could avoid moving much of this scripting infrastructure to Web IDL. :)

What difference is there between using the ECMAScript spec terminology for invoking a Function object when invoking callback functions and "jumping to a code entry point"?

See also bug 18242.

heycam: The main differences are that the "entry script" gets set up, script isn't run if the page isn't active, it checks if scripting is disabled, and it does microtask-like stuff afterwards.

Maybe, though, we should define "entry script" in terms of JS terms, so that it just hooks in automatically to everything. Maybe something about "When evaluating a 'SourceElements' JS production"?

What happens when I add a function that has no SourceElements involved (say Array.prototype.sort) as an event listener?

Seriously, you can't talk about JS objects and functions in syntactic terms.  It just doesn't work.

bz: So what _does_ work?

Talking about them as objects.  There's an actual ES object here, a callable one.  

Of course then you run into issues with callable objects not necessarily having a "script" associated with them.  To the extent that what you care about is a global, not a script, this is not a problem since they do always have an associated global...  but if you want a "script", then you have a problem.

So how do I refer to the "object" that's at the top of the "stack", in ES terms?

(Note that ES talks about code execution in syntactic terms. Code execution is the result of evaluating syntactic components.)

> So how do I refer to the "object" that's at the top of the "stack", in ES terms?

That's a good question for public-script-coord.

> Note that ES talks about code execution in syntactic terms.

Not for things like the callback to Array.prototype.sort and whatnot... those are just objects with a [[Call]].

Looks like this got fixed. bz, is the spec sufficient now?

(Note that this will actually need to change a bit, because right now the entry script gets set to the handler's script, but all browsers actually use the context of the element on which the event handler was invoked to do this. But they do this for addEventListener() too, which will probably require DOM changes... maybe I should file a new bug for this.)

http://www.hixie.ch/tests/adhoc/html/script/callbacks/001.html

> but all browsers actually use the context of the element on which the event
> handler was invoked to do this.

Do which this?  Event handlers in Firefox should use the "script settings object" based on the callable being invoked, I would think.  Unless you're testing in a super-ancient version of Firefox, of course...  I can't tell which part of your big testcase is trying to test this part and how it's going about it.

Hm, interesting. Further testing actually shows that Firefox is actually
inconsistent about this, acting one way for .onclick and another for
addEventListener('click'). Also, browsers don't like event handlers being
set to window.open at all. I wonder why it works for setTimeout but not
event listeners.

http://www.hixie.ch/tests/adhoc/html/script/callbacks/002.html

RESULTS:
Firefox:
   local:                                        outer
   .onclick from iframe:                         iframe
   addEventListener from iframe:                 outer
   .onclick and addEventListener to window.open: exception

Chrome:
   local:                                        outer
   .onclick from iframe:                         outer
   addEventListener from iframe:                 outer
   .onclick and addEventListener to window.open: exception

Safari:
   local:                                        outer
   .onclick from iframe:                         outer
   addEventListener from iframe:                 outer
   .onclick and addEventListener to window.open: exception

IE10 (thanks Anne):
   local:                                        outer
   .onclick from iframe:                         inner
   addEventListener from iframe:                 inner
   .onclick and addEventListener to window.open: exception

On the 001 test, it's the third batch of tests (the ones with the event listeners in the iframe) that checks this. They're only testing addEventListener, though, not a straight event handler. And for some reason they don't work in IE9.

I should try adjusting that test to use .bind() on the method i'm passing in, in case addEventListener is doing something like setting 'this' to the element or something like that.

Thanks for the smaller testcase!  addEventListener definitely sets "this" to the element when the listener is invoked.  So for the window.open test you need to bind(), indeed.

I also see now what the issue you're running into with Firefox is: you're testing in a release build, where addEventListener isn't using a WebIDL callback yet.  A nightly or Aurora build, where that's on WebIDL would give you:

  Firefox:
    local:                                        outer
    .onclick from iframe:                         iframe
    addEventListener from iframe:                 iframe

which matches IE10 and imo general sanity (but not our old behavior before we started converting things to WebIDL).

I was on an old nightly, heh. Now updated, I agree that it says outer for the first one, and inner for the other four.

I've updated the test:
   http://www.hixie.ch/tests/adhoc/html/script/callbacks/002.html

Firefox uses the settings object of the script of the callback, or the global of the object used in the callback, in the case it's not a script. (So, outer, inner 4 times, outer 4 times.) Chrome uses the settings object of the element the event handler fired on (so outer 9 times).

This seems to be consistent with what we want to do in bug 18242, so what I need to do here is the same as in bug 23744.

*** This bug has been marked as a duplicate of bug 23744 ***