Cc'ing thestig@, halcanary@ for more inputs on this.

wjmaclean: is this a GuestView thing?

I'm ooo this week, so I can't easily verify, but I would guess it's a ChildFrameCompositingHelper here:

https://cs.chromium.org/chromium/src/content/renderer/child_frame_compositing_helper.cc?rcl=0&l=119

Even though this code is for out-of-process-iframes, current BrowserPlugin-based guestviews (PDF included) also use the compositing helper.

You can also by using --site-per-process and navigate to a page with a cross-site iframe, then using task manager to kill the iframe's renderer.

I know OOPIF explicitly doesn't want to provide too much information (imagine a 10x10 pixel iframe, not uncommon), but it would be nice perhaps to be able to customize this display, and perhaps allow the user to choose a 'standard interstitial' via the WebView/GuestView API.

Adding lfg@ and creis@ to get some more ideas here.

[+kenrb]

Yeah, the same graphic is displayed for any GuestView and out-of-process iframes crash.  As wjmaclean@ mentions, this can be used in small frames (where there's no room for context but some sort of tooltip might be helpful) as well as full-page cases (like PDF and signin).

Ken, do you think it would be difficult to use the standard Aw Snap in the case that the child frame is the whole page?

Just to add some more context, this is a discussion that has gone around in the past: https://bugs.chromium.org/p/chromium/issues/detail?id=273089

Fwiw, I personally think it would be nice to be able to choose the behaviour in the case of Web/GuestView, and that the standard interstitials should be among the options.

See also RenderWidgetHostViewGuest::Show() at
https://cs.chromium.org/chromium/src/content/browser/frame_host/render_widget_host_view_guest.cc?rcl=0&l=97

For <webview>, this can be customized by the embedding app (look at how browser sample does it), so the pdf extension should be able to do it.

I don't mind changing the default, but we need some UX input here, since the same image/page has to be displayed in very small iframes, as well as full-page contents.

I think Charlie is suggesting that we might use a different graphic when it is full page.

I don't know how often iframes cover the entire page, but it is more likely to happen with GuestView. I agree that it can be a bit confusing as it is, but there is also the question of what happens if the GuestView or iframe covers, for instance, 98% of the current viewing surface, whether something different should be displayed. UX input seems appropriate here, for some opinions on whether it is worth the effort.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

lfg: which sample are you referring to comment 6. When you say the "pdf extension should be able to do it" do you really mean "MimeHandlerView can do it when the PDF plugin it hosts crashes" ?

Re #10: My comment in #6 was wrong -- I forgot this was MimeHandlerViewGuest, so there's significant amount of work involved in customizing the crashed icon.

For WebViewGuest, we dispatch an event to the embedding page (done in WebViewGuest::RenderProcessGone), which allows the embedder to know when the child process crashes.

So for MimeHandlerViewGuest and possibly the PDF JS code, we will need to follow the WebViewGuest example and plumb things through to customize the crashed icon?