In the extensions code, we try to minimize IPCs and tracking in the browser process by only sending IPCs to add/remove event listeners for the first/last event of a given type being added/removed.  Unfiltered events will send one IPC for the first listener for a given event (per extension), and another IPC for the first listener from a lazy context for an event (per extension).  Filtered events use a single IPC for adding/removing listeners, whether they are lazy or not.  In theory, this is nice, but it breaks in subtle edge cases.  Consider:

Extension registers listener for event "foo" in non-lazy context A
Extension registers listener for event "foo" in lazy context B

If event "foo" is unfiltered, the renderer will send one IPC to add a listener for event "foo", and a separate to add a lazy listener for event "foo".  The lazy listener will be added to the prefs, and persisted across runs.

If event "foo" is filtered, the renderer will send only one IPC to the browser to add a non-lazy listener for context A.  When the listener is added to lazy context B, no IPC is sent, since it wasn't the first listener.  This means the listener is not persisted.

In practice, this isn't a *terrible* problem - most lazy background pages should be registering listeners synchronously at startup, and thus will be the first to run.  However, there are some potential cases in which that's not the case, and it would be nice to close the hole.