CMP API (@iabgpp/cmpapi) will not import existing event listeners from a stub using the "Example stub code" from the GPP CMP API Specification

[NevilleS]

Overview

Hello all!

We were testing some edge cases for the interaction between a __gpp CMP stub implementation and then subsequently loading the CmpApi and ran into a very subtle issue.

When CmpApi is created, it creates a new EventListenerQueue that gets existing queued commands from any existing window.__gpp implementation:

iabgpp-es/modules/cmpapi/src/cmpapi/EventListenerQueue.ts

Line 21 in b03e54c

let events = window["__gpp"]("events") || [];

However, there's a subtle issue here: this relies on an "events" command, e.g. __gpp("events") which returns the internal event queue from the stub. This is implemented by the official stub here:

iabgpp-es/modules/stub/src/stub.js

Line 22 in b03e54c

if (b.length == 1 && b[0] == "events") {

The issue is that the "events" command isn't part of the GPP specification, so it's not guaranteed to exist in a stub! In particular, the example stub implementation in the GPP standard doesn't include this command: https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Core/CMP%20API%20Specification.md#examples

To summarize:

1. Publisher implements a stub following the GPP specification using the example here: https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Core/CMP%20API%20Specification.md#examples
2. Publisher uses their stub to call __gpp("addEventListener", () => ...) to register an event listener with the GPP API
3. Publisher initializes a CMP implementation that uses the @iabgpp/cmpapi library to implement the API
4. CmpApi initializes and does not import the existing event listener (from step tcfcav2 unit tests #2), causing that listener to never receive GPP events

Possible Solutions

1. This can be avoided by ensuring publishers avoid using the "example" GPP stub from the specification, and instead use the published stub from @iabgpp/stub. This is probably what 99% of implementations do anyways! In this scenario, I'd recommend updating the GPP specification to recommend this and link to the @iabgpp/stub implementation instead
2. Alternatively, the CmpApi implementation could be updated to detect if the "example" GPP stub is being used and, if so, fallback to importing the __gpp.events array instead of trying to call __gpp("events") if it doesn't exist. This might have it's own issues, but...