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}
Committed: https://chromium.googlesource.com/chromium/src/+/71e8d307789f1cf492f4803bdceab898e8105a47

[alexmos, 2017-03-02 01:33:50]

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 data URLs 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
==========

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 data URLs 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
==========

[alexmos, 2017-03-02 01:33:52]

The CQ bit was checked by alexmos@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-02 01:34:28]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-02 03:09:33]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-02 03:09:33]

Dry run: This issue passed the CQ dry run.

[alexmos, 2017-03-02 18:01:35]

The CQ bit was checked by alexmos@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-02 18:01:59]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-02 19:47:27]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-02 19:47:28]

Dry run: This issue passed the CQ dry run.

[alexmos, 2017-03-02 21:50:00]

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 data URLs 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
==========

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
==========

[alexmos, 2017-03-02 21:58:55]

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

[alexmos, 2017-03-02 21:58:56]

Hey Charlie -- no rush on this, but this is one attempt to fix the transfer bug
with data URLs for plugin mime types.  I *think* this will make us more robust
to not call Transfer() when the actual transfer will not be performed due to
CanSubframeSwapProcess returning false.  Another approach could be to make
IsRendererTransferNeededForNavigation return false in the first place (by
pulling in some logic from CanSubframeSwapProcess into it), so that we won't
even attempt a transfer is such cases, but that seems more involved, and
transfers will hopefully be gone soon anyway.

[Charlie Reis, 2017-03-08 22:04:13]

Whew, that's pretty subtle.  I think it's ok, especially if we can remove this
once PlzNavigate ships and there's no transfers anymore.  LGTM.

[alexmos, 2017-03-09 17:34:21]

The CQ bit was checked by alexmos@chromium.org

[commit-bot: I haz the power, 2017-03-09 17:35:01]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-09 19:08:17]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1489080861812590,
"parent_rev": "1e2d08a7fc2db1297a7f2a28c40659af534c309e", "commit_rev":
"71e8d307789f1cf492f4803bdceab898e8105a47"}

[commit-bot: I haz the power, 2017-03-09 19:08:58]

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
==========

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}
Committed:
https://chromium.googlesource.com/chromium/src/+/71e8d307789f1cf492f4803bdcea...
==========

[commit-bot: I haz the power, 2017-03-09 19:08:59]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/chromium/src/+/71e8d307789f1cf492f4803bdcea...