Block navigations in extensions via ShouldTransferNavigation (not via OpenURL).

Block navigations in extensions via ShouldTransferNavigation (not via OpenURL).
(this is relanding a slightly tweaked r421287).

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 (tracked in https://crbug.com/650694) 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 #2
   above (i.e. avoid OpenURL only for POST requests).

BUG=646261
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
TBR=sky@chromium.org, rdevlin.cronin@chromium.org

Review-Url: https://codereview.chromium.org/2377833002
Cr-Commit-Position: refs/heads/master@{#421645}
(cherry picked from commit 1d02573dbb13b5d7bd76f172afdf19a6389dc2f7)

Committed: https://chromium.googlesource.com/chromium/src/+/1fd4604fd78908736589d8ac5e3b0e3347c4c6ce

[Łukasz Anforowicz, 2016-09-29 22:15:55]

Description was changed from

==========
Block navigations in extensions via ShouldTransferNavigation (not via OpenURL).
(this is relanding a slightly tweaked r421287).

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 (tracked in https://crbug.com/650694) 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 #2
   above (i.e. avoid OpenURL only for POST requests).

BUG=646261
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
TBR=sky@chromium.org, rdevlin.cronin@chromium.org

Review-Url: https://codereview.chromium.org/2377833002
Cr-Commit-Position: refs/heads/master@{#421645}
(cherry picked from commit 1d02573dbb13b5d7bd76f172afdf19a6389dc2f7)
==========

to

==========
Block navigations in extensions via ShouldTransferNavigation (not via OpenURL).
(this is relanding a slightly tweaked r421287).

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 (tracked in https://crbug.com/650694) 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 #2
   above (i.e. avoid OpenURL only for POST requests).

BUG=646261
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
TBR=sky@chromium.org, rdevlin.cronin@chromium.org

Review-Url: https://codereview.chromium.org/2377833002
Cr-Commit-Position: refs/heads/master@{#421645}
(cherry picked from commit 1d02573dbb13b5d7bd76f172afdf19a6389dc2f7)

Committed:
https://chromium.googlesource.com/chromium/src/+/1fd4604fd78908736589d8ac5e3b...
==========

[Łukasz Anforowicz, 2016-09-29 22:15:56]

Committed patchset #1 (id:1) manually as
1fd4604fd78908736589d8ac5e3b0e3347c4c6ce.