Bug 1134923 removed the use of those functions in gecko, and left some
for the XPCOM standalone glue. The XPCOM standalone glue was severely
stripped down in bug 1306327, with the effect of removing the
implementation for those functions.
The remains in nsXPCOM.h are:
XPCOM_API(void*) NS_Alloc(size_t aSize);
XPCOM_API(void*) NS_Realloc(void* aPtr, size_t aSize);
XPCOM_API(void) NS_Free(void* aPtr);
With no implementation left, the first arm is never actually used, and
the second arm means every remaining use of those functions in the tree
is a macro expansion to one of moz_xmalloc, moz_xrealloc or free.
This introduces filtering to avoid attempting to dispatch notifications
to WebExtensions processes and other types of content processes.
This is dependent upon bug 1395827 changing xpcshell to create its child
processes with a remote type of "web" in order to not break the push
xpcshell tests.
Previously, all `PushNotifier` methods checked the process type, and
either called `Notify*{Workers, Observers}` or sent an IPDL message.
The message handlers then called back in to `PushNotifier` from the
remote process.
This was clearer when we only sent worker event notifications to the
content process, and fired all observer notifications in the parent.
It became more complicated once we started notifying observers for all
subscriptions in both processes (bug 1266433). This makes it harder to
see omissions; for example, "push-subscription-modified" isn't
currently forwarded to the child, but "push-subscription-change" and
"push-message" are.
This patch moves the remoting code into `PushNotifier::Dispatch`, and
adds a base `PushDispatcher` class. Each notification type subclasses
this class and implements logic for sending messages and firing
observers and worker events. It's more code, but a bit easier to see
which methods are called where.
MozReview-Commit-ID: 7Q0eD7qXOrW
