It is likely necessary to define a new mechanism for clearing unused pushIDs. Disabling cleanup during onUnload allows push to continue functioning after the video is played, but it also results in an accumulation of old pushIDs. However, there are other cases where unused pushIDs accumulate, so an improved cleanup mechanism should be investigated.

Each browser window/tab has a set of pushIDs with active listeners. When a listen.icepush returns with a set of notifications, these need to be dispatched to the various browser windows via two mechanisms: local storage events and cookie polling. When a notification occurs (including a noop) each pushID in each window can have an associated timestamp so that the listening window can determine if a given pushID is still active. pushIDs with very old associated timestamps can be garbage collected.

(copied from MOBI-193)

Introduced mechanism for expiring PushIds on the client to avoid ID acumulation when they are not properly deregistered. The bridge now keeps track of the last time a pushID notification was received, if after a certain interval (configured through org.icepush.pushIdTimeout context parameter, used on the server side as well) no more notifications were received for this ID then it is discarded.

The mechanism described in previous comment was removed from the bridge. The way it used to work would have invalidated any notifications that occur less often than the pushID expiration interval.

A simple fix was applied to make sure that only one instance of a pushID will show up in the list of IDs kept by 'ice.pushids' cookie.

This issue is not being reopened since it is "fixed" in EE 3.3. A clone will be created for the general cleanup strategy.