Bug 1603714: Do not treat third-party module data integrity error as IPC error; r=mhowell

I still do not yet have a good grasp of the root cause of this data integrity
issue, however I also think that having the browser process crash because of it
is far worse.

This also adds a check in our telemetry processing that the deserialized event
is valid.

We'll probably need to add more diagnostic information in the future, but I'd
like to get rid of the IPC errors in Nightly in time for holidays.

Depends on D58046

Differential Revision: https://phabricator.services.mozilla.com/D58047

--HG--
extra : moz-landing-system : lando

toolkit/components/telemetry/other/UntrustedModules.cpp

@@ -211,6 +211,10 @@ static bool SerializeEvent(JSContext* aCx, JS::MutableHandleValue aElement,
                            const IndexMap& aModuleIndices) {
   MOZ_ASSERT(NS_IsMainThread());
 
+  if (!aEvent) {
+    return false;
+  }
+
   JS::RootedObject obj(aCx, JS_NewPlainObject(aCx));
   if (!obj) {
     return false;

toolkit/xre/UntrustedModulesData.h

@@ -553,10 +553,11 @@ struct ParamTraits<mozilla::UntrustedModulesData> {
       return false;
     }
 
+    // NB: While bad data integrity might for some reason result in a null
+    // mModule, we do not fail the deserialization; this is a data error,
+    // rather than an IPC error. The error is detected and dealt with in
+    // telemetry.
     aResult->mModule = aModulesMap.Get(resolvedNtName);
-    if (!aResult->mModule) {
-      return false;
-    }
 
     return true;
   }