Closed Bug 1408568 Opened 4 years ago Closed 4 years ago
Report::Proc Type::FILE needs a case in Sandbox Report Wrapper::Get Proc Type
59 bytes, text/x-review-board-request
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.
Assignee: nobody → jld
Priority: -- → P1
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
Attachment #8918491 - Flags: review?(gpascutto) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/25089d5c04f4 Handle SandboxReport::ProcType::FILE correctly in XPCOM bindings. r=gcp
You need to log in before you can comment on or make changes to this bug.