This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22757 - "If listener's callback is a Function object, it..."
Summary: "If listener's callback is a Function object, it..."
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: DOM (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-22 19:28 UTC by Ian 'Hixie' Hickson
Modified: 2013-07-23 23:03 UTC (History)
4 users (show)

See Also:


Attachments

Description Ian 'Hixie' Hickson 2013-07-22 19:28:43 UTC
http://dom.spec.whatwg.org/#dispatching-events

[[
If listener's callback is a Function object, its callback this value is the event's currentTarget attribute value.
]]

What should browsers do for this step? Seems to just be a definition, which doesn't make much sense for a step...
Comment 1 Boris Zbarsky 2013-07-22 19:34:50 UTC
> What should browsers do for this step?

Set the "callback this value" as defined in http://dev.w3.org/2006/webapi/WebIDL/#dfn-callback-this-value perhaps?

Or put another way, the "callback this value" is an input to the WebIDL steps for invoking a callback operation, and whatever spec defines that a callback operation is invoked needs to say what that input is.

Of course the DOM spec linked in comment 0 doesn't say anything about invoking the operation, which seems bogus to me.  It should be talking about calling the listener's handleEvent and shouldn't say anything in particular about Function objects (especially because what it says actually contradicts WebIDL when non-Function callables are involved).
Comment 2 Anne 2013-07-22 20:32:36 UTC
Yes it does talk about invoking it. What do you mean? And "of course"? o_O

https://github.com/whatwg/dom/commit/196cfd52e0c05a31228e2d49cc17fa6f9ab9cf22
Comment 3 Boris Zbarsky 2013-07-22 21:43:48 UTC
> Yes it does talk about invoking it.

Maybe I'm just being blind but where?  I see no mention of calling .handleEvent on the listener anywhere in the spec linked in comment 0 or in the commit linked in comment 2.

> And "of course"?

http://dictionary.reference.com/browse/course under "Idioms" item 32a:

32. of course,
  a. certainly; definitely: Of course I'll come to the party.
Comment 4 Anne 2013-07-23 04:11:03 UTC
Your assumption that specs don't say anything about a particular scenario is not very nice, since most often they do. That's what I meant, I don't need a dictionary definition.

As for invoking the callback, it's done in http://dom.spec.whatwg.org/#concept-event-listener-invoke (4.7 at the moment). I kinda thought IDL would handle the Function/handleEvent distinction. I guess not.

heycam, suggestions?
Comment 5 Boris Zbarsky 2013-07-23 04:32:37 UTC
I don't think I was making any assumptions, just making a statement about the spec in question....

> As for invoking the callback, it's done in http://dom.spec.whatwg.org/#concept-
> event-listener-invoke (4.7 at the moment).

My point is, that text is wrong if you mean to actually invoke the callback the way it should be invoked.

> I kinda thought IDL would handle the Function/handleEvent distinction. I guess
> not.

It does.  Calling the handleEvent operation of the EventListener interface, with the "callback this value" set to the event's currentTarget, will do the right thing per WebIDL.  See http://dev.w3.org/2006/webapi/WebIDL/#es-user-objects the list of steps for what happens when an operation of a callback interface is called, with particular attention to step 2 and step 5, which transparently handle the case when the underlying JS object happens to be a Function object.

So from the DOM point of view an EventListener is just an IDL object with a handleEvent operation, which the DOM spec should be calling, with the right "callback this value".  Then WebIDL takes care of the rest.
Comment 6 Cameron McCormack 2013-07-23 04:38:41 UTC
(Mid-aired by Boris, but can't be bothered editing my reply to remove duplicate information...)

(In reply to comment #4)
> Your assumption that specs don't say anything about a particular scenario is
> not very nice, since most often they do. That's what I meant, I don't need a
> dictionary definition.
> 
> As for invoking the callback, it's done in
> http://dom.spec.whatwg.org/#concept-event-listener-invoke (4.7 at the
> moment). I kinda thought IDL would handle the Function/handleEvent
> distinction. I guess not.
> 
> heycam, suggestions?

Web IDL does handle the Function vs { handleEvent: ... } differences, so you shouldn't need to handle the two cases differently.  If you want, you can define the callback this value regardless of whether a Function object was used -- the callback this value will only be used when it is a Function object, anyway.  Might be good in that case to have a note to point out that if a { handleEvent: ... } object is passed then that object is the this value.

Boris is right that it needs to specifically talk about calling handleEvent on the object, since callback interfaces are things which in general can have any number of operations on them.  (Even if a Function object were used, its [{Call]] behaviour is considered as the implementation of the handleEvent operation, so it still makes sense, wrt Web IDL, to talk about handleEvent there.)  Such is the difference between callback interfaces and callback function types.

If it's helpful, I can add a term you can link to for calling an operation on a object that implements a callback interface.