constellation: crash to a new “sad tab” error page

[delan]

Servo historically recovered from crashes by navigating forwards to an about:failure page, but we never got around to reimplementing about:failure in the fetch-based network stack, so it turned into an “Unexpected scheme” error.

That approach was less than ideal though, because navigating forwards trashes your forward history. Even if we were to navigate with replacement, the location bar would show “about:failure” instead of the original URL, and we would lose the original LoadData containing the request body and headers and so on. In both cases, it would be tricky to make the reload command work properly or add a reload button to the error page.

This patch replaces our use of about:failure with an error page that behaves similarly to a network error.

When the constellation detects a panic, we create a replacement pipeline as before, but we now reload the page in place with the same LoadData except with .crash set to the crash details. This gets plumbed through RequestBuilder and Request to the fetch code, which converts it to a NetworkError::Crash, which the HTML parser renders as a new kind of error page. The user can then view the reason and backtrace if any, and click a button to reload the page.

To test this manually, go to data:text/html,<script>document.write()</script> after applying the patch below:

diff --git a/components/script/dom/document.rs b/components/script/dom/document.rs
index c3d83be696..bbaab2182d 100644
--- a/components/script/dom/document.rs
+++ b/components/script/dom/document.rs
@@ -5127,6 +5127,7 @@ impl DocumentMethods for Document {
 
     // https://html.spec.whatwg.org/multipage/#dom-document-write
     fn Write(&self, text: Vec<DOMString>) -> ErrorResult {
+        panic!();
         if !self.is_html_document() {
             // Step 1.
             return Err(Error::InvalidState);

---

• ./mach build -d does not report any errors
• ./mach test-tidy does not report any errors
• These changes fix about:failure doesn't exist any more #17187

• There are tests for these changes OR
  • feedback on how we can test this would be appreciated :)
• These changes do not require tests because ___

[jdm]

For testing, it might be possible to have an iframe that calls window.trap() (

servo/components/script/dom/window.rs

Line 1112 in c623ab9

unsafe { ::std::intrinsics::breakpoint() }

), and then the outer window could check that there's a cross-origin frame?

[mrobinson]

Thanks for this change! This looks fine to me though I have a couple nit-picky comments.

[delan]

For testing, it might be possible to have an iframe that calls window.trap() ([…]), and then the outer window could check that there's a cross-origin frame?

This is interesting! std::intrinsics::trap and std::intrinsics::abort just kill the whole process, unless we are in multiprocess mode, but we can add a window.panic() function gated behind dom.servo_helpers.enabled. I’m not sure if the crash error page will count as cross-origin though, looking into it.

[delan]

For testing, it might be possible to have an iframe that calls window.trap() ([…]), and then the outer window could check that there's a cross-origin frame?

This is interesting! std::intrinsics::trap and std::intrinsics::abort just kill the whole process, unless we are in multiprocess mode, but we can add a window.panic() function gated behind dom.servo_helpers.enabled. I’m not sure if the crash error page will count as cross-origin though, looking into it.

<!-- tests/wpt/mozilla/tests/crash-page.sub.html -->
<iframe style=border:solid
src="{{location[scheme]}}://{{hosts[alt][]}}:{{location[port]}}/_mozilla/crash-page-inner.html">
</iframe>

<!-- tests/wpt/mozilla/tests/crash-page-inner.html -->
<script>panic()</script>

When the iframe crashes, we close all of the pipelines under the top-level browsing context and navigate that, so the page containing the iframe is gone too.

[mrobinson]

Thanks! It sounds like testing this is tricky for now. Just a couple tiny comments: