addEventHandler implementation appears to be imcomplete

[nealrosen]

Here are some of the things I'm seeing that cause me to believe this command is not fully implemented. Please let me know if I'm missing something.

• I'm seeing a return value from __gpp('addEventHandler') of {param: undefined, next: undefined, callback: ƒ}, which does not match the IAB spec.
• Only the stub code includes an eventName property in the response
• I am unable to trigger an event to fire. After the CMP has loaded, I tried calling cmpApi.setGppString() then cmpApi.fireUpdate().

[chuff]

I believe this should now be working in 3.0.7. I also removed the cmpapi update method and replaced it with a few methods that reflect the defined event types from the spec. I also updated the stub so that the cmpapi could retrieve the stub queued event listeners. Let me know.

[nealrosen]

Looks much better. I'm not clear why CMPs would need to call the cmpApi.fireEvent() to trigger another event to callers of the addEventListener command. For example, shouldn't calling cmpApi.setCmpStatus() be sufficient to trigger the event? In any case, I'm closing this issue because you have addressed the issues I raised.

FYI, there are additional issues with the addEventListener command, and frankly all others. It is due to the stub code (both from IAB docs and this implementation) making the assumption that all commands support only callbacks. Most commands do not support callbacks, only directly returning with some value. The stub does not pass returned values in postMessage calls to iframes. There is an issue and PR related to this on the documentation repo. I am working with Jan Winkler on this.

[chuff]

I'm open to suggestion on the fire methods. The "cmpStatus", "cmpDisplayStatus", and "error" events don't currently require a separate fireEvent call. The only one that does is "sectionChange". I implemented it that way so that the event handler could receive one event when all of the fields are set rather than one each time the "setFieldValue" method is called. The generic fireEvent method was actually put in there to handle the generic event from the spec "[API.prefix] or [API-prefix].[Eventname]".

[nealrosen]

Oh ok, I didn't realize the cmpStatus event doesn't require a separate fireEvent call. Thanks.