Bug 1308400 added a variant to SandboxReport::ProcType for file processes, but it's not mapped to a string in SandboxReportWrapper::GetProcType. This will throw a JS exception on release builds, and crash with an assertion failure on debug builds, if there's a rejected syscall in a file content process and about:support / Troubleshoot.jsm is then used.

This touches l10n strings, which could be a problem for uplift. One alternative is to map SandboxReport::ProcType::FILE to "content" (same as SandboxReport::ProcType::CONTENT), uplift that, and then land a second patch on m-c which gives it its own string.

On non-debug builds, this will replace the entire "sandbox" branch of the Troubleshoot.jsm data with an error message, which in turn causes the formatter in about:support to throw an exception. Fortunately, "sandbox" is still the last one in the list, so bug 1374327 won't result in collateral damage to other parts of about:support in this case. (I tested this on a debug build with the assertion removed.)

Comment on attachment 8918491 [details] Bug 1408568 - Handle SandboxReport::ProcType::FILE correctly in XPCOM bindings. https://reviewboard.mozilla.org/r/189354/#review194902

Pushed by jedavis@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/25089d5c04f4 Handle SandboxReport::ProcType::FILE correctly in XPCOM bindings. r=gcp