19211 2012-10-02 15:20:55 +0000 The event handler processing algorithm talk about jumping to a code entry-point 2013-11-11 18:46:08 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED DUPLICATE 23744 http://www.whatwg.org/specs/web-apps/current-work/#events P2 critical Unsorted 23780 1 contributor ian bzbarsky cam ian mike contributor oldest_to_newest 75061 0 contributor 2012-10-02 15:20:55 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html Multipage: http://www.whatwg.org/C#events Complete: http://www.whatwg.org/c#events Comment: Should the event handler processing algorithm talk about jumping to a code entry point? Posted from: 173.48.30.113 by bzbarsky@mit.edu User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/18.0 Firefox/18.0 75062 1 bzbarsky 2012-10-02 15:22:01 +0000 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.... 80699 2 ian 2012-12-30 03:46:19 +0000 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? 84907 3 cam 2013-03-25 04:57:11 +0000 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"? 88483 4 ian 2013-05-30 22:29:00 +0000 See also bug 18242. 89525 5 ian 2013-06-18 23:43:48 +0000 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"? 89537 6 bzbarsky 2013-06-19 01:44:39 +0000 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. 90150 7 ian 2013-07-02 22:00:00 +0000 bz: So what _does_ work? 90158 8 bzbarsky 2013-07-02 22:09:51 +0000 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. 90271 9 ian 2013-07-03 21:59:18 +0000 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.) 90319 10 bzbarsky 2013-07-04 03:15:17 +0000 > 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]]. 95903 11 ian 2013-11-06 22:31:22 +0000 Looks like this got fixed. bz, is the spec sufficient now? 95982 12 ian 2013-11-07 22:21:43 +0000 (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 96014 13 bzbarsky 2013-11-08 03:03:17 +0000 > 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. 96058 14 ian 2013-11-08 23:18:13 +0000 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 96066 15 ian 2013-11-08 23:52:32 +0000 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. 96068 16 ian 2013-11-09 00:24:22 +0000 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. 96074 17 bzbarsky 2013-11-09 01:53:51 +0000 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). 96135 18 ian 2013-11-11 18:46:08 +0000 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 ***