If we detect the WebView is not visible to the user (ex. if it is not attached
to a window or the WebView is marked as invisible with View#setVisibility()
),
then WebView does not show an interstitial at all. In this case, we just return
the ERROR_UNSAFE_RESOURCE
network error and block the unsafe resource.
This behavior is determined in the code by
AwContents#canShowInterstitial()
.
The main interstitials in Chrome are Loud interstitials, which are blocking pages that show detailed informational text to users and are (usually) red in background color. WebView supports these interstitials when we believe WebView is the predominant part of the application UI (such as in browser apps).
When we suspect WebView is a smaller (or otherwise less prominent) part of the application UI, we show a gray Quiet interstitial, which is meant to feel like a less-scary error page.
There are Small, Medium, and Giant Quiet interstitials. Medium interstitials are when we have enough space to show textual information, Small interstitials are when there’s not enough space, and Giant interstitials are whenever part of the WebView hangs out of the viewport.
Small interstitial | 4 Medium interstitials | Giant interstitial (hanging off bottom right of viewport) |
---|---|---|
WebView returns ERROR_UNSAFE_RESOURCE
to the application when the user
clicks «back to safety.» This is to stay consistent with expectations of legacy
applications (to communicate the page failed to load).
WebView supports the onSafeBrowsingHit()
callback, allowing applications to
implement custom interstitials. This also involves exposing threat type
constants,
to indicate what threat WebView observed.
WebView will not show a «back to safety» button on the interstitial if there’s no previous page in the history, or if we’re showing a Quiet interstitial.
With «back to safety» button (like Chrome) | No «back to safety» button (WebView only) |
---|---|