Make it possible to load a new Url in hosted mode

Make it possible to load a new Url in hosted mode

This adds an interface to handle loading a new inside the
current activity when the session id inside an incoming hosted
intent is valid and matches with the current one.

Committed: https://crrev.com/4a0ebaa2eb0ddc4e618cfc19ba722efad3733bd4
Cr-Commit-Position: refs/heads/master@{#331456}

[Yusuf, 2015-05-21 20:42:58]

yusufo@chromium.org changed reviewers:
+ lizeb@chromium.org, pasko@chromium.org

[Benoit L, 2015-05-22 08:48:58]

lgtm, thanks
(non committer though).
Just one minor question.

https://codereview.chromium.org/1157433002/diff/1/chrome/android/java_staging...
File
chrome/android/java_staging/src/org/chromium/chrome/browser/hosted/HostedContentHandler.java
(right):

https://codereview.chromium.org/1157433002/diff/1/chrome/android/java_staging...
chrome/android/java_staging/src/org/chromium/chrome/browser/hosted/HostedContentHandler.java:11:
* TODO(yusufo): Add a way to handle mayLaunchUrl as well.
Why would we need to handle mayLaunchUrl here?

[pasko, 2015-05-26 17:30:07]

First thoughts, will continue in ~30min.

Commit description:
s/handle loading a new/handle loading a new URL/

https://codereview.chromium.org/1157433002/diff/1/chrome/android/java_staging...
File
chrome/android/java_staging/src/org/chromium/chrome/browser/document/ChromeLauncherActivity.java
(right):

https://codereview.chromium.org/1157433002/diff/1/chrome/android/java_staging...
chrome/android/java_staging/src/org/chromium/chrome/browser/document/ChromeLauncherActivity.java:268:
boolean handled = HostedActivity.shouldActiveContentHandleIntent(getIntent());
this way of naming is slightly confusing:
shouldDoX() returns true when it has already done X

how about:
handleInActiveContentIfNeeded(intent) returns true if needed and handled, false
otherwise

?

https://codereview.chromium.org/1157433002/diff/1/chrome/android/java_staging...
File
chrome/android/java_staging/src/org/chromium/chrome/browser/toolbar/HostedToolbar.java
(right):

https://codereview.chromium.org/1157433002/diff/1/chrome/android/java_staging...
chrome/android/java_staging/src/org/chromium/chrome/browser/toolbar/HostedToolbar.java:119:
return mUseDarkColors;
I am totally not an expert in this code, so please assume I am missing something
obvious here.

In omnibox/LocationBarLayout.java shouldEmphasizeHttpsScheme() depends on 
getSecurityLevel(), isUsingBrandColor(), isIncognito().

Why is it different here? Is the difference temporary? Even if mUseDarkColors is
always set correctly according to security policies (which I have not verified),
someone can change it forgetting about the influence of color on https scheme
emphasis.

[Yusuf, 2015-05-26 17:34:47]

https://codereview.chromium.org/1157433002/diff/1/chrome/android/java_staging...
File
chrome/android/java_staging/src/org/chromium/chrome/browser/toolbar/HostedToolbar.java
(right):

https://codereview.chromium.org/1157433002/diff/1/chrome/android/java_staging...
chrome/android/java_staging/src/org/chromium/chrome/browser/toolbar/HostedToolbar.java:119:
return mUseDarkColors;
On 2015/05/26 17:30:07, pasko wrote:
> I am totally not an expert in this code, so please assume I am missing
something
> obvious here.
> 
> In omnibox/LocationBarLayout.java shouldEmphasizeHttpsScheme() depends on 
> getSecurityLevel(), isUsingBrandColor(), isIncognito().
> 
> Why is it different here? Is the difference temporary? Even if mUseDarkColors
is
> always set correctly according to security policies (which I have not
verified),
> someone can change it forgetting about the influence of color on https scheme
> emphasis.

You are right. We should also be looking at the security state here. One
difference is for this we are always in hosted mode, so checking for incognito
or brandColor shouldn't apply. We should return false by default, but check SSL
state at the beginning to return true if error or warning

[pasko, 2015-05-26 19:17:38]

looked through the rest, it's all great, thanks

[pasko, 2015-05-26 19:47:19]

lgtm modulo the nits I mentioned before

[Yusuf, 2015-05-26 22:13:53]

The CQ bit was checked by yusufo@chromium.org

[Yusuf, 2015-05-26 22:13:53]

The patchset sent to the CQ was uploaded after l-g-t-m from pasko@chromium.org,
lizeb@chromium.org
Link to the patchset: https://codereview.chromium.org/1157433002/#ps20001
(title: "Renamed call and added security state to http scheme emphasis logic")

[commit-bot: I haz the power, 2015-05-26 22:14:29]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1157433002/20001

[commit-bot: I haz the power, 2015-05-26 22:27:41]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-05-26 22:30:31]

Patchset 2 (id:??) landed as
https://crrev.com/4a0ebaa2eb0ddc4e618cfc19ba722efad3733bd4
Cr-Commit-Position: refs/heads/master@{#331456}