Revert of Allow top-level navigation in extension pop-ups if it only triggers a download.

Revert of Allow top-level navigation in extension pop-ups if it only triggers a download. (patchset #12 id:220001 of https://codereview.chromium.org/2352083003/ )

Reason for revert:
It seems that tests introduced in this CL are failing on some non-CQ bots: https://build.chromium.org/p/chromium.win/builders/Win10%20Tests%20x64/builds/4653 (and also 4654 and 4655).

Original issue's description:
> Block navigations in extensions via ShouldTransferNavigation (not via OpenURL).
>
> Before this CL, blocking of top-level navigations in extension pop-ups
> was accomplished by routing them via OpenURL path and blocking (or
> rather - silently dropping) CURRENT_TAB navigations via
> ExtensionViewHost::OpenURLFromTab.  This was problematic for a few
> reasons:
>
> 1. This unnecessarily blocked navigations that end-up being treated
>    as downloads (i.e. because HTTP response says Content-Disposition:
>    attachment).  This was the root cause of the regression raised in
>    https://crbug.com/646261
>
> 2. There are still some remaining issues in handling of POST requests
>    via OpenURL path (e.g. dropping Content-Type header -
>    https://crbug.com/648648).
>
> 3. In the long-term we want to rely less on process isolation
>    accomplished via OpenURL - an exploited renderer process does not
>    necessarily have to go through OpenURL path and can instead choose
>    to use the regular, renderer-initiated path.
>
> After this CL:
>
> 1. ExtensionViewHost::ShouldTransferNavigation is used to block top-level
>    navigations in extension pop-ups (and background pages).
>
> 2. POST navigations do not go through OpenURL path anymore (i.e. this CL
>    effectively reverts the essence of r407586).
>
>    In the long-term we want to make all extension navigations to not go
>    through OpenURL path, but this seems too risky to merge back to M54,
>    so for now we only do #1 above (i.e. avoid OpenURL only for POST
>    requests).
>
> BUG=646261
> CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
>
> Committed: https://crrev.com/953f8c785a134b2b4bd9ff401ff27f7edef4172c
> Cr-Commit-Position: refs/heads/master@{#421287}

TBR=creis@chromium.org,rdevlin.cronin@chromium.org,sky@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=646261
Committed: https://crrev.com/20d7fecd2c5d88e2666743c8d53d9d2b2ea47395
Cr-Commit-Position: refs/heads/master@{#421360}

[Łukasz Anforowicz, 2016-09-27 22:22:20]

The CQ bit was checked by lukasza@chromium.org

[Łukasz Anforowicz, 2016-09-27 22:22:20]

Created Revert of Allow top-level navigation in extension pop-ups if it only
triggers a download.

[commit-bot: I haz the power, 2016-09-27 22:22:41]

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, 2016-09-27 22:23:45]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-09-27 22:25:11]

Description was changed from

==========
Revert of Allow top-level navigation in extension pop-ups if it only triggers a
download. (patchset #12 id:220001 of https://codereview.chromium.org/2352083003/
)

Reason for revert:
It seems that tests introduced in this CL are failing on some non-CQ bots:
https://build.chromium.org/p/chromium.win/builders/Win10%20Tests%20x64/builds...
(and also 4654 and 4655). 

Original issue's description:
> Block navigations in extensions via ShouldTransferNavigation (not via
OpenURL).
> 
> Before this CL, blocking of top-level navigations in extension pop-ups
> was accomplished by routing them via OpenURL path and blocking (or
> rather - silently dropping) CURRENT_TAB navigations via
> ExtensionViewHost::OpenURLFromTab.  This was problematic for a few
> reasons:
> 
> 1. This unnecessarily blocked navigations that end-up being treated
>    as downloads (i.e. because HTTP response says Content-Disposition:
>    attachment).  This was the root cause of the regression raised in
>    https://crbug.com/646261
> 
> 2. There are still some remaining issues in handling of POST requests
>    via OpenURL path (e.g. dropping Content-Type header -
>    https://crbug.com/648648).
> 
> 3. In the long-term we want to rely less on process isolation
>    accomplished via OpenURL - an exploited renderer process does not
>    necessarily have to go through OpenURL path and can instead choose
>    to use the regular, renderer-initiated path.
> 
> After this CL:
> 
> 1. ExtensionViewHost::ShouldTransferNavigation is used to block top-level
>    navigations in extension pop-ups (and background pages).
> 
> 2. POST navigations do not go through OpenURL path anymore (i.e. this CL
>    effectively reverts the essence of r407586).
> 
>    In the long-term we want to make all extension navigations to not go
>    through OpenURL path, but this seems too risky to merge back to M54,
>    so for now we only do #1 above (i.e. avoid OpenURL only for POST
>    requests).
> 
> BUG=646261
> CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
> 
> Committed: https://crrev.com/953f8c785a134b2b4bd9ff401ff27f7edef4172c
> Cr-Commit-Position: refs/heads/master@{#421287}

TBR=creis@chromium.org,rdevlin.cronin@chromium.org,sky@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=646261
==========

to

==========
Revert of Allow top-level navigation in extension pop-ups if it only triggers a
download. (patchset #12 id:220001 of https://codereview.chromium.org/2352083003/
)

Reason for revert:
It seems that tests introduced in this CL are failing on some non-CQ bots:
https://build.chromium.org/p/chromium.win/builders/Win10%20Tests%20x64/builds...
(and also 4654 and 4655).

Original issue's description:
> Block navigations in extensions via ShouldTransferNavigation (not via
OpenURL).
>
> Before this CL, blocking of top-level navigations in extension pop-ups
> was accomplished by routing them via OpenURL path and blocking (or
> rather - silently dropping) CURRENT_TAB navigations via
> ExtensionViewHost::OpenURLFromTab.  This was problematic for a few
> reasons:
>
> 1. This unnecessarily blocked navigations that end-up being treated
>    as downloads (i.e. because HTTP response says Content-Disposition:
>    attachment).  This was the root cause of the regression raised in
>    https://crbug.com/646261
>
> 2. There are still some remaining issues in handling of POST requests
>    via OpenURL path (e.g. dropping Content-Type header -
>    https://crbug.com/648648).
>
> 3. In the long-term we want to rely less on process isolation
>    accomplished via OpenURL - an exploited renderer process does not
>    necessarily have to go through OpenURL path and can instead choose
>    to use the regular, renderer-initiated path.
>
> After this CL:
>
> 1. ExtensionViewHost::ShouldTransferNavigation is used to block top-level
>    navigations in extension pop-ups (and background pages).
>
> 2. POST navigations do not go through OpenURL path anymore (i.e. this CL
>    effectively reverts the essence of r407586).
>
>    In the long-term we want to make all extension navigations to not go
>    through OpenURL path, but this seems too risky to merge back to M54,
>    so for now we only do #1 above (i.e. avoid OpenURL only for POST
>    requests).
>
> BUG=646261
> CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
>
> Committed: https://crrev.com/953f8c785a134b2b4bd9ff401ff27f7edef4172c
> Cr-Commit-Position: refs/heads/master@{#421287}

TBR=creis@chromium.org,rdevlin.cronin@chromium.org,sky@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=646261

Committed: https://crrev.com/20d7fecd2c5d88e2666743c8d53d9d2b2ea47395
Cr-Commit-Position: refs/heads/master@{#421360}
==========

[commit-bot: I haz the power, 2016-09-27 22:25:12]

Patchset 1 (id:??) landed as
https://crrev.com/20d7fecd2c5d88e2666743c8d53d9d2b2ea47395
Cr-Commit-Position: refs/heads/master@{#421360}