Add a resource throttle for sub frame unless scheme of uri is acceptable

Add a resource throttle for sub frame unless scheme of uri is acceptable

For now, a resource throttle is added only for main frame. But showing a
dedicated app or an intent picker even for sub frame is better than showing
an error page unless scheme of uri is acceptable on chrome on android.

BUG=410524

[Jaekyun Seok (inactive), 2014-09-29 06:12:34]

jaekyun@chromium.org changed reviewers:
+ dtrainor@chromium.org, jam@chromium.org, tedchoc@chromium.org

[Jaekyun Seok (inactive), 2014-09-29 06:12:35]

Please review my change.

Thanks,

[David Trainor- moved to gerrit, 2014-09-29 18:26:45]

dtrainor@chromium.org changed reviewers:
+ davidben@chromium.org

[David Trainor- moved to gerrit, 2014-09-29 18:26:45]

The Android plumbing looks fine.

Adding davidben@ who looks like he knows
chrome_resource_dispatcher_host_delegate.cc.  I'm not sure if that logic is what
we want/if there was a reason we weren't doing this earlier.  David, let me know
if you're the right person for this.  If not I'll try to track down someone
else.  Thanks!

[David Trainor- moved to gerrit, 2014-09-29 21:03:23]

lgtm for android plumbing.

[davidben, 2014-09-29 21:40:44]

That would be how you'd intercept a subframe navigation in today's setup, though
are those something we should intercept? The frame is a component of the page,
rather than a switch to a new one (and so intercepting that into a switch to a
different app makes sense).

What happens right now if an intent dialog gets thrown up and the user selects
Chrome? I'm assuming the original navigation has already been canceled and a new
top-level one is made in its stead? In that case, if the IsAcceptedScheme check
intercepts a load that Chrome was supposed to display, what was in the frame
will end up at the top-level.

https://chromiumcodereview.appspot.com/615433002/diff/20001/chrome/android/ja...
File chrome/android/java/src/org/chromium/chrome/browser/UrlUtilities.java
(right):

https://chromiumcodereview.appspot.com/615433002/diff/20001/chrome/android/ja...
chrome/android/java/src/org/chromium/chrome/browser/UrlUtilities.java:26:
"about", "data", "file", "http", "https", "inline", "javascript");
This list seems incomplete. Chrome can handle quite a few schemes. There's ftp
URLs. Or a web+blah scheme might be registerProtocolHandler'd. Some WebUI on
desktop at least under the chrome: scheme will iframe other pages under the
chrome: scheme.

There's also other schemes that are meaningful, though I don't know if the can
be iframed. view-source:, blob:, filesystem:. Probably others I'm missing.

https://chromiumcodereview.appspot.com/615433002/diff/20001/chrome/browser/re...
File chrome/browser/renderer_host/chrome_resource_dispatcher_host_delegate.cc
(right):

https://chromiumcodereview.appspot.com/615433002/diff/20001/chrome/browser/re...
chrome/browser/renderer_host/chrome_resource_dispatcher_host_delegate.cc:329:
!IsAcceptedScheme(request->url().spec())))) {
Could you add a comment explaining why it's important that only URLs the browser
can't display can be intercepted here?

[davidben, 2014-09-29 21:42:06]

On 2014/09/29 21:40:44, David Benjamin wrote:
> That would be how you'd intercept a subframe navigation in today's setup,
though
> are those something we should intercept? The frame is a component of the page,
> rather than a switch to a new one (and so intercepting that into a switch to a
> different app makes sense).

Er. That was really badly worded:

A top-level navigation is a switch to a different page (and so turning that into
a switch to a different app makes sense), while the frame is a component of the
current page.

[Jaekyun Seok (inactive), 2014-09-29 22:16:13]

On 2014/09/29 21:40:44, David Benjamin wrote:
> What happens right now if an intent dialog gets thrown up and the user selects
> Chrome? I'm assuming the original navigation has already been canceled and a
new
> top-level one is made in its stead? In that case, if the IsAcceptedScheme
check
> intercepts a load that Chrome was supposed to display, what was in the frame
> will end up at the top-level.
> 

Chrome can't handle the scheme of the given url if it was from the sub frame,
and so it can't be listed in an intent picker and a user can't select it.

[Jaekyun Seok (inactive), 2014-09-29 22:17:19]

https://chromiumcodereview.appspot.com/615433002/diff/20001/chrome/android/ja...
File chrome/android/java/src/org/chromium/chrome/browser/UrlUtilities.java
(right):

https://chromiumcodereview.appspot.com/615433002/diff/20001/chrome/android/ja...
chrome/android/java/src/org/chromium/chrome/browser/UrlUtilities.java:26:
"about", "data", "file", "http", "https", "inline", "javascript");
I don't know well about this list. But most of others seem for downloadable
schemes. Maybe we can extend ACCEPTED_SCHEMES and DOWNLOADABLE_SCHEMES later in
a separated CL.

Anyway, I will modify codes to check if the url has a downloadable scheme as
well.

https://chromiumcodereview.appspot.com/615433002/diff/20001/chrome/browser/re...
File chrome/browser/renderer_host/chrome_resource_dispatcher_host_delegate.cc
(right):

https://chromiumcodereview.appspot.com/615433002/diff/20001/chrome/browser/re...
chrome/browser/renderer_host/chrome_resource_dispatcher_host_delegate.cc:329:
!IsAcceptedScheme(request->url().spec())))) {
Yes, I will.

[Jaekyun Seok (inactive), 2014-09-29 22:37:06]

PTAL.

I modified codes to check if the url has a downloadable scheme as well as an
acceptable scheme.

[Jaekyun Seok (inactive), 2014-09-30 03:51:50]

According to Grace, url override only works for the top level url.

So I will abandon this patch.