Bug 1608760 - Make ClonedErrorHolder::ToErrorValue() deal with a null filename. r=bzbarsky

If you serialize and then deserialize a JSErrorReport with a null filename
field, then we end up passing a null filename to JS::CreateError, which ends
up crashing. Perhaps CreateError should be robust against a null filename,
but the fact that whatever latent null filename issue wasn't causing crashes
until this serialization was added suggests it might be reasonable to deal
with it inside ClonedErrorHolder.

This patch causes a null string to instead become an empty string. We could do
this on the sending side, but by dealing with it on the receiving side we get
the bonus of keeping a malicious sender from crashing us.

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

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

dom/ipc/ClonedErrorHolder.cpp

@@ -279,6 +279,15 @@ bool ClonedErrorHolder::ToErrorValue(JSContext* aCx,
   if (mType == Type::JSError) {
     JS::Rooted<JSString*> filename(aCx);
     JS::Rooted<JSString*> message(aCx);
+
+    // For some unknown reason, we can end up with a void string in mFilename,
+    // which will cause filename to be null, which causes JS::CreateError() to
+    // crash. Make this code against robust against this by treating void
+    // strings as the empty string.
+    if (mFilename.IsVoid()) {
+      mFilename.Assign(EmptyCString());
+    }
+
     if (!ToJSString(aCx, mFilename, &filename) ||
         !ToJSString(aCx, mMessage, &message)) {
       return false;