InstantExtended: Add js api for custom logo.

InstantExtended: Add js api for custom logo.

Background: When the Instant page is warm and the search provider has a
doodle, we want to show it immediately without first showing the
baked-in logo (the user has already seen the baked-in logo transition
away, and seeing that on every NTP would be annoying.)

This adds an API which promises that the current overlay will respond to
an NTP contextchange with a SetInstantPreviewHeight to show a custom
logo. In this case, the NTP can just rely on Instant to draw the logo.

BUG=142785

[Jered, 2012-10-10 16:51:52]

Please review.

[sreeram, 2012-10-10 18:57:03]

Plumbing has_logo through the BrowserWindow interface seems misplaced. It seems
like this state belongs in SearchModel or somewhere similar from where the
search_view_controller can extract the info. Perhaps @dhollowa can suggest the
right course here?

I am also mildly concerned about the IPC bloat (due to all of our searchbox
changes). @sky, what do you think? If nobody cares, this is fine with me too. If
you think we should keep IPC surface small whenever possible, the has_logo bit
can be communicated back in the existing InstantSupportDetermined IPC.

http://codereview.chromium.org/11094047/diff/1/chrome/browser/instant/instant...
File chrome/browser/instant/instant_controller.cc (right):

http://codereview.chromium.org/11094047/diff/1/chrome/browser/instant/instant...
chrome/browser/instant/instant_controller.cc:556: (IsOutOfDate() &&
!active_tab_is_ntp_))
Don't do the IsOutOfDate or active_tab_is_ntp_ checks. It's entirely possible
that the hidden page will finish loading when Instant is in an out-of-date state
(for example, the omnibox has lost focus), and the user is on a regular, non-ntp
page. We still want to note the fact that it has a doodle.

[Jered, 2012-10-10 22:03:54]

Rietveld ate my code... let's pick up on issue 11091050.

On 2012/10/10 18:57:03, sreeram wrote:
> Plumbing has_logo through the BrowserWindow interface seems misplaced. It
seems
> like this state belongs in SearchModel or somewhere similar from where the
> search_view_controller can extract the info. Perhaps @dhollowa can suggest the
> right course here?
> 
> I am also mildly concerned about the IPC bloat (due to all of our searchbox
> changes). @sky, what do you think? If nobody cares, this is fine with me too.
If
> you think we should keep IPC surface small whenever possible, the has_logo bit
> can be communicated back in the existing InstantSupportDetermined IPC.
> 
>
http://codereview.chromium.org/11094047/diff/1/chrome/browser/instant/instant...
> File chrome/browser/instant/instant_controller.cc (right):
> 
>
http://codereview.chromium.org/11094047/diff/1/chrome/browser/instant/instant...
> chrome/browser/instant/instant_controller.cc:556: (IsOutOfDate() &&
> !active_tab_is_ntp_))
> Don't do the IsOutOfDate or active_tab_is_ntp_ checks. It's entirely possible
> that the hidden page will finish loading when Instant is in an out-of-date
state
> (for example, the omnibox has lost focus), and the user is on a regular,
non-ntp
> page. We still want to note the fact that it has a doodle.

[Jered, 2012-10-10 22:10:47]

http://codereview.chromium.org/11094047/diff/1/chrome/browser/instant/instant...
File chrome/browser/instant/instant_controller.cc (right):

http://codereview.chromium.org/11094047/diff/1/chrome/browser/instant/instant...
chrome/browser/instant/instant_controller.cc:556: (IsOutOfDate() &&
!active_tab_is_ntp_))
On 2012/10/10 18:57:04, sreeram wrote:
> Don't do the IsOutOfDate or active_tab_is_ntp_ checks. It's entirely possible
> that the hidden page will finish loading when Instant is in an out-of-date
state
> (for example, the omnibox has lost focus), and the user is on a regular,
non-ntp
> page. We still want to note the fact that it has a doodle.

Done.