nealrosen
commented
1 year ago During today's working group call, the decision to use return values rather than callbacks for most commands was explained. The reason was that it isn't necessary for same frame calls because those commands must return immediately anyways. And the solution proposed on the call was to modify the postMessage handling logic in the stub code to address this.
While this resolves the issue from the point-of-view of the CMP, it forces the calling script in the iframe to know whether it is in an iframe or not which isn't ideal. While the GPP API docs don't provide something like this, I was assuming/hoping that a proxy API similar to this from the TCF spec could be defined in the iframe to allow scripts to call the CMP without knowing whether it is in an iframe or not.
If it is agreed that a proxy API should be able to be supported for GPP, then I believe the only solution is to use callbacks for everything, as was done with the tcfapi.
The window.__gpp_msghandler references in the example stub code assumes that all commands support a callback parameter, though most commands do not support a callback parameter. The documentation for the getGPPData command describes the callback parameter as "not used".
If these commands only support synchronously returning the value directly without using a callback, how can an asynchronous postmessage interface work?
Similarly, the addEventListener command returns an EventListener object immediately, then uses the callback for any future state changes. When calling the CMP from inside an iframe, only the callbacks would trigger responses to the caller. So, they would not receive the initially returned EventListener object. This means the caller can't tell if the CMP has loaded and therefore won't call the callback, or if it is still loading and the callback will be called once loaded.