One detail: I think net error page is actually implemented in html/css, which does the fade in and whatnot. That's not really possible with a crash.

Grey background instead of black is definitely a big plus on a white page :)

Re #1: It should be possible to implement it in html/css if required, since it's the subframe process that crashed, and the sad frame is rendered by the parent frame (it gets a notification from the browser that the subframe process crashed).

On comment #2, while it might technically be possible, wouldn't it require transitioning the RemoteFrame to a LocalFrame? That would be complex enough that might not be worth the effort. I don't know if fallback content can be used for that, but in general we have been trying to isolate error pages in their own process, so this will go in a direction opposite of what we are aiming for.

Re#3: Yes, if we don't want to spawn a new process for the error frame we probably need to transition to a LocalFrame.

Yeah, I agree that this may not be worth the effort. It really boils down to which design we want and how much effort we want to put at implementing it.

If it's just about changing the bgcolor, the value comes from https://cs.chromium.org/chromium/src/content/renderer/child_frame_compositing_helper.cc?rcl=bdaa29eb9df18cdd6c9b9819dd0438b0eb1deef9&l=42 and it's a fairly simple change.

another wild idea, credit to tedchoc@: keep showing the last frame of the iframe, and just grey it out

The graphics pipeline could in theory just keep rendering the last frame which does not require the iframe being alive. Need to ensure hit testing still works as expected, ie input events should go to the parent frame that's still alive. There are lots of edge cases though. What happens if the size of the iframe changes, what if the iframe never submitted a frame because it was offscreen when it was killed, what if graphics pipeline threw the frame away. Probably has security implications for surfaces embedding, and probably breaks a lot of assumptions in code.

#5: interesting idea.  Though since the parent frame renders sad frame graphics today, we should be careful not to give it access to the crashed frame's last frame - that would be a security issue (info leak).  So the last submitted frame would need to be kept and composited from somewhere else in the graphics pipeline; don't know how hard that is.  Also, I'd worry about how users would perceive greyed out frames. For example, they might still expect to be able to click on an grey ad or select text and be surprised that it doesn't work.

> Though since the parent frame renders sad frame graphics today, we should be careful not to give it access to the crashed frame's last frame - that would be a security issue (info leak).

Oh my idea is to have the graphics pipeline retain the content of the dead iframe, and just have the parent frame keep embedding it, same as embedding a live iframe.

The security change is not info leak, since the content of the child iframe is never in the parent frame. The security change is the parent's ability to retain the content of the dead frame for longer that it is retained currently.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ffa01b02a0d4e28ed3e78dea49c55a85dc4a1475

commit ffa01b02a0d4e28ed3e78dea49c55a85dc4a1475
Author: Bo Liu <boliu@chromium.org>
Date: Thu Sep 27 00:06:05 2018

Make sad frame background gray

Less jarring on a page with white background.

Bug: 884819
Change-Id: I40ef521090d6146ba0abe2f78de0656d824988ef
Reviewed-on: https://chromium-review.googlesource.com/1247030
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Bo <boliu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#594529}
[modify] https://crrev.com/ffa01b02a0d4e28ed3e78dea49c55a85dc4a1475/content/renderer/child_frame_compositing_helper.cc

Thanks Bo for landing r594529 - the sad frames are now grey instead of black. 

BTW, this might be a minor detail, but I've noticed that sometimes the sad frame graphic is not centered properly and also larger than normal and blurry.  For example, I see this when killing the subframe process on http://csreis.github.io/tests/cross-site-iframe-simple.html on both Android and Mac Canary, but on Linux and Windows it looks fine.  I'm curious if there's an issue with coordinate calculations in ChildFrameCompositingHelper::ChildFrameGone().

My blind guess is not dealing with density correctly. kEnableUseZoomForDSF got flipped back and forth recently, which affects units blink uses. Could be that? Could maybe explain why linux and windows are ok since they usually have screen density of 1.