I suspect the change to attempt to download a new request immediately is responsible.

Looking - It might be a timing issue, we are definitely checking for a connection before trying the download, it might be that the API we use has some latency for connection changes.

Please add more info as soon as you investigate. Need to determine if this is M54.

Can you share the URL? Did you try the same URL without the transition to airplane mode? That is, we should rule out that it is not a prerender failure with the page.

I haven't repro-ed yet with setting airplane mode first but I was able to get a request started and then quickly go to airplane mode and get a PRERENDER_FAILURE with FINAL_STATUS_UNSUPPORTED_SCHEME. This seems to be set in 4 different places. One place has to do with redirects so I wonder first about it.

Repro-ed again setting airplane mode after adding.
I think we need to fix for M54. 

Ok, got a repro with logging at the site that generate this final status. It hit here: https://cs.chromium.org/chromium/src/chrome/browser/prerender/prerender_contents.cc?rcl=1472469725&l=469

on the url:  data:text/html,chromewebdata

This looks like it's the internal URL for the error page:

// This error URL is loaded in normal web renderer processes, so it should not
// have a chrome:// scheme that might let it be confused with a WebUI page.
const char kUnreachableWebDataURL[] = "data:text/html,chromewebdata";

see https://cs.chromium.org/chromium/src/content/public/common/url_constants.cc?rcl=0&l=58

// Special URL used to start a navigation to an error page.
CONTENT_EXPORT extern const char kUnreachableWebDataURL[];

In a separate mail thread on options in prerenderer, there is some prospect of understanding if we hit this error page path vs. a redirect issue from the page itself. But we may not know at prerenderer level why we have an error page (so no strong signal that is was due to lost connectivity). 

In my manual evaluations so far (~70 page on GIN-3g, 50 pages on GIN-2g), the Unsupported Scheme was the most common error I ran into. In all but one case, subsequent retries succeeded leading me to believe they were due to connectivity problems. The one that consistently repros is a bad url - unable to load it in visible tab.

I think the current behavior (of no retries) will be detrimental to the Downloads experience in the EM environments and we should take some action for M54 to allow a couple of retries for any Unsupported Scheme errors. We can do this at the Offliner level (since the prerender level doesn't that much stronger information anyway).

Originally I was thinking of splitting the handling of Unsupported Scheme errors by whether we currently have a network connection or not but dimich@ makes good point that knowledge can lag in time from when we see the error.

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

commit 27e86c877f293dec2693281e7848e4d61a95ba4c
Author: dougarnett <dougarnett@chromium.org>
Date: Wed Aug 31 17:34:17 2016

[Offline Pages] Handle prerender FinalStatus UnsupportedScheme as a cancel rather than failure.
Losing network connection while prerendering can show up as an Unsupported Scheme failure
currently as it sees a special data URL in path toward rendering an error page. We don't want
a flakey network connection fail a background load request on just a single try, so for now,
we will treat this specific error type as a cancel rather than a failure so that it is subject
some limited retrying. The down side, is that for some page that has a repeatable redirect
to an unsupported scheme, we will waste some retries on it that we otherwise could skip.

Ideally, we could get a different final status code from the prerenderer if it could clearly distinguish a network failure condition but it does not currently have such knowledge.

BUG= 642025 

Review-Url: https://codereview.chromium.org/2294933003
Cr-Commit-Position: refs/heads/master@{#415673}

[modify] https://crrev.com/27e86c877f293dec2693281e7848e4d61a95ba4c/chrome/browser/android/offline_pages/prerendering_loader.cc
[modify] https://crrev.com/27e86c877f293dec2693281e7848e4d61a95ba4c/chrome/browser/android/offline_pages/prerendering_loader_unittest.cc
[modify] https://crrev.com/27e86c877f293dec2693281e7848e4d61a95ba4c/components/offline_pages/background/request_coordinator.cc
[modify] https://crrev.com/27e86c877f293dec2693281e7848e4d61a95ba4c/components/offline_pages/background/request_coordinator_unittest.cc
[modify] https://crrev.com/27e86c877f293dec2693281e7848e4d61a95ba4c/components/offline_pages/background/request_notifier.h

Your change meets the bar and is auto-approved for M54 (branch: 2840)

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

commit fb7fb8344b2af613675770e6446e21d847fcaefb
Author: Pete Williamson <petewil@chromium.org>
Date: Wed Aug 31 21:36:50 2016

[Offline Pages] Handle prerender FinalStatus UnsupportedScheme as a cancel rather than failure. Losing network connection while prerendering can show up as an Unsupported Scheme failure currently as it sees a special data URL in path toward rendering an error page. We don't want a flakey network connection fail a background load request on just a single try, so for now, we will treat this specific error type as a cancel rather than a failure so that it is subject some limited retrying. The down side, is that for some page that has a repeatable redirect to an unsupported scheme, we will waste some retries on it that we otherwise could skip.

Ideally, we could get a different final status code from the prerenderer if it could clearly distinguish a network failure condition but it does not currently have such knowledge.

BUG= 642025 

Review-Url: https://codereview.chromium.org/2294933003
Cr-Commit-Position: refs/heads/master@{#415673}
(cherry picked from commit 27e86c877f293dec2693281e7848e4d61a95ba4c)

Review URL: https://codereview.chromium.org/2298063004 .

Cr-Commit-Position: refs/branch-heads/2840@{#80}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/fb7fb8344b2af613675770e6446e21d847fcaefb/chrome/browser/android/offline_pages/prerendering_loader.cc
[modify] https://crrev.com/fb7fb8344b2af613675770e6446e21d847fcaefb/chrome/browser/android/offline_pages/prerendering_loader_unittest.cc
[modify] https://crrev.com/fb7fb8344b2af613675770e6446e21d847fcaefb/components/offline_pages/background/request_coordinator.cc
[modify] https://crrev.com/fb7fb8344b2af613675770e6446e21d847fcaefb/components/offline_pages/background/request_coordinator_unittest.cc
[modify] https://crrev.com/fb7fb8344b2af613675770e6446e21d847fcaefb/components/offline_pages/background/request_notifier.h

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

commit fb7fb8344b2af613675770e6446e21d847fcaefb
Author: Pete Williamson <petewil@chromium.org>
Date: Wed Aug 31 21:36:50 2016

[Offline Pages] Handle prerender FinalStatus UnsupportedScheme as a cancel rather than failure. Losing network connection while prerendering can show up as an Unsupported Scheme failure currently as it sees a special data URL in path toward rendering an error page. We don't want a flakey network connection fail a background load request on just a single try, so for now, we will treat this specific error type as a cancel rather than a failure so that it is subject some limited retrying. The down side, is that for some page that has a repeatable redirect to an unsupported scheme, we will waste some retries on it that we otherwise could skip.

Ideally, we could get a different final status code from the prerenderer if it could clearly distinguish a network failure condition but it does not currently have such knowledge.

BUG= 642025 

Review-Url: https://codereview.chromium.org/2294933003
Cr-Commit-Position: refs/heads/master@{#415673}
(cherry picked from commit 27e86c877f293dec2693281e7848e4d61a95ba4c)

Review URL: https://codereview.chromium.org/2298063004 .

Cr-Commit-Position: refs/branch-heads/2840@{#80}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/fb7fb8344b2af613675770e6446e21d847fcaefb/chrome/browser/android/offline_pages/prerendering_loader.cc
[modify] https://crrev.com/fb7fb8344b2af613675770e6446e21d847fcaefb/chrome/browser/android/offline_pages/prerendering_loader_unittest.cc
[modify] https://crrev.com/fb7fb8344b2af613675770e6446e21d847fcaefb/components/offline_pages/background/request_coordinator.cc
[modify] https://crrev.com/fb7fb8344b2af613675770e6446e21d847fcaefb/components/offline_pages/background/request_coordinator_unittest.cc
[modify] https://crrev.com/fb7fb8344b2af613675770e6446e21d847fcaefb/components/offline_pages/background/request_notifier.h