Skip to content

Updates needed to better support vendor scripts within iframes calling the CMP #51

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
nealrosen opened this issue Jan 18, 2023 · 2 comments

Comments

@nealrosen
Copy link
Contributor

nealrosen commented Jan 18, 2023

Problem

As currently designed, vendor scripts running within an iframe are unable to get responses from most commands. Most commands do not support callbacks, but the example stub code assumes all commands do support callbacks.

Also, given that most commands use synchronous return values as opposed to asynchronous callback functions adds complexity for vendor scripts running inside iframes. A proxy interface (similar to one defined in the TCF design) can not be created in a way that allows vendor scripts to call the proxy the same way they would call the real CMP. This is due to the fact that all cross-frame communication is inherently asynchronous.

Solution 1 (recommended) - Remove direct return values from all commands and rely solely on callbacks

Pros

  • Aligns with TCF design, allowing for an easier transition to GPP
  • Allows for a proxy interface to be created in a way that vendor scripts need not know whether they are running in the same frame as the CMP or in an iframe

Cons

  • Requires a more significant update to the design

Solution 2 - Leave CMP interface as is. Update example stub code to respond to postMessage calls with direct return values as well as callbacks from the command.

Pros

  • Reduces changes needed to current GPP design

Cons

  • Adds complexity to vendor script. A proxy interface could be created, but it would differ from the CMP design as all commands would need to support callbacks in the proxy interface.
  • If a vendor script is running in an iframe which it does not control, the script that controls the iframe would be responsible for ensuring the vendor script could access the CMP properly.

Solution 3 - Update all commands to support both a return value and a callback. If a callback is passed, then the command should use it. Otherwise, the command should return a value.

Pros

  • Doesn't break the existing design for most commands. The behavior only changes if a callback function is passed to a command that previously did not support it.
    • The addEventListener command might need a breaking change. The initial response to the command is only passed as a return value. This may need to change to be passed as both a return value and to the callback.
  • Allows for a proxy interface to be created that is similar (but not identical) to the CMP. The difference being that only the callback is supported.

Cons

  • Still adds potential confusion and complexity in vendor scripts running within iframes

While I believe Solution 1 should be the preferred approach, if there is too much concern making significant changes at this time, Solution 3 may be sufficient (though not ideal).

@janwinkler
Copy link

Followup: Group decision to go with suggestion 1 as outlined above. We will draft the necessary changes and input to the WG.

@ajsf
Copy link

ajsf commented Mar 14, 2023

Hello,

I am checking in to see if there is an estimated date for when this update will be released? I see that PR #55 has been submitted for this.

At FreeWheel we are waiting for this update to implement GPP in our SDK.

Thanks,
Aaron

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants