Note that we will soon remove this blob-url mechanism to load the main resource response.
You can test it with --enable-features=NavigationMojoResponse. Can you still reproduce your issue?

What is the "onReceivedError" function you are talking about?
Maybe:
1) NavigationHandle::~NavigationHandle()
2) WebContentsImpl::DidFinishNavigation()
3) AwContents::DidFinishNavigation()
4) AwContentsClientBridge::onReceiveError()
5) AwContentsClientCallbackHelper.MyHandler.postOnReceivedError()
6) ...
In this case, I don't expect you to see PlzNavigate internal blob-URL, only the real URLs. Real URLs can have the blob-scheme too.

> Note that we will soon remove this blob-url mechanism to load the main resource response.

Thanks, I'll try the flag. Does that mean the blob URL mechanism will no longer be used at all, or it will still be used for subresources? I want to be sure I test the correct edge case.

> What is the "onReceivedError" function you are talking about?

WebView surfaces network errors to apps with a callback named WebViewClient#onReceivedError. This is implemented with both (4) and (5) in your list.

> In this case, I don't expect you to see PlzNavigate internal blob-URL, only the real URLs. Real URLs can have the blob-scheme too.

I agree we should not show implementation details to the app. I was surprised our code saw these internal URLs, but I'm confident the real pages don't contain blobs.

Is it likewise unexpected that we see blob URLs in our request intercepter (link [1] from initial report)?

Before NavigationMojoResponse, the browser loaded the main resource from the network with the real URL. Then we asked the renderer to load the resource from the browser using a blob-URL.
After NavigationMojoResponse, we switch the implementation of the URLLoaderClient from one in the browser process to one in the renderer process, as soon as we know in which process the navigation must commit into. There is no more blob-URL, only the real one.

No more using the blob-URL mechanism internally to load the main resource doesn't mean there no more blob-URL.
Blob-URLs is a Web feature. See https://developer.mozilla.org/fr/docs/Web/API/Blob
Clients can create blob-url and navigate to it.

I don't think what you are seeing are PlzNavigate internal blob-URLs. I think you are seeing real blob-URLs.

For me, it is unexpected to see an internal blob-URL in WebViewClient#onReceivedError, but it is expected to see them in link [1] from your initial report.

Thanks for the clarification, it makes more sense now. I filed  issue 822983  to continue the discussion around shouldInterceptRequest. I'll leave this open to continue investigation for internally-created blob URLs in onReceivedError. I don't believe my integration test has any web-created blob URLs, but I'll double check what's going on and update this bug.

I'll close this as wontfix, because NavigationMojoResponse has been on by default since dbc14cfafbcff118eb5575534c0439509001e7ef. I'll reopen if I run across similar issues again.