Fix transfers for data URLs with plugin mime types.

Fix transfers for data URLs with plugin mime types.

Typically, when a local frame navigates to a data URL, the request is
serviced in the renderer without going up to the browser process.
However, this isn't true for some data URLs, such as those with plugin
mime types.  Those go up to the browser, where they stalled due to
conflicting logic that first decided that a transfer is needed, marked
the current RFH as transferring, but then decided that a process
transfer isn't allowed and kept the load in the current RFH.

When the process transfer is prevented by CanSubframeSwapProcess, the
load will always stay in the current RFH.  This CL tries to recognize
scenarios where this happens for transfers that also starts in the
current RFH, so that we can avoid calling Transfer() for the current
RFH unnecessarily.

BUG=697513
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2729523003
Cr-Commit-Position: refs/heads/master@{#455821}
(cherry picked from commit 71e8d307789f1cf492f4803bdceab898e8105a47)

Review-Url: https://codereview.chromium.org/2845223002 .
Cr-Commit-Position: refs/branch-heads/3029@{#781}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}
Committed: https://chromium.googlesource.com/chromium/src/+/0454f5814f0bcd28398d93ec6700fc34adae20a0

[Charlie Reis, 2017-04-28 17:16:51]

creis@chromium.org changed reviewers:
+ alexmos@chromium.org

[Charlie Reis, 2017-04-28 17:16:51]

FYI: Merging to M58.

[Charlie Reis, 2017-04-28 17:17:29]

Description was changed from

==========
Fix transfers for data URLs with plugin mime types.

Typically, when a local frame navigates to a data URL, the request is
serviced in the renderer without going up to the browser process.
However, this isn't true for some data URLs, such as those with plugin
mime types.  Those go up to the browser, where they stalled due to
conflicting logic that first decided that a transfer is needed, marked
the current RFH as transferring, but then decided that a process
transfer isn't allowed and kept the load in the current RFH.

When the process transfer is prevented by CanSubframeSwapProcess, the
load will always stay in the current RFH.  This CL tries to recognize
scenarios where this happens for transfers that also starts in the
current RFH, so that we can avoid calling Transfer() for the current
RFH unnecessarily.

BUG=697513
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2729523003
Cr-Commit-Position: refs/heads/master@{#455821}
(cherry picked from commit 71e8d307789f1cf492f4803bdceab898e8105a47)
==========

to

==========
Fix transfers for data URLs with plugin mime types.

Typically, when a local frame navigates to a data URL, the request is
serviced in the renderer without going up to the browser process.
However, this isn't true for some data URLs, such as those with plugin
mime types.  Those go up to the browser, where they stalled due to
conflicting logic that first decided that a transfer is needed, marked
the current RFH as transferring, but then decided that a process
transfer isn't allowed and kept the load in the current RFH.

When the process transfer is prevented by CanSubframeSwapProcess, the
load will always stay in the current RFH.  This CL tries to recognize
scenarios where this happens for transfers that also starts in the
current RFH, so that we can avoid calling Transfer() for the current
RFH unnecessarily.

BUG=697513
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2729523003
Cr-Commit-Position: refs/heads/master@{#455821}
(cherry picked from commit 71e8d307789f1cf492f4803bdceab898e8105a47)

Review-Url: https://codereview.chromium.org/2845223002 .
Cr-Commit-Position: refs/branch-heads/3029@{#781}
Cr-Branched-From:
939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}
Committed:
https://chromium.googlesource.com/chromium/src/+/0454f5814f0bcd28398d93ec6700...
==========

[Charlie Reis, 2017-04-28 17:17:30]

Committed patchset #1 (id:1) manually as
0454f5814f0bcd28398d93ec6700fc34adae20a0.