Added RenderView.DocumentHasImages query method

Added RenderView.DocumentHasImages query method

This upstreams a method used by Chrome on Android.  It allows the
browser to query the page to see if it contains any image elements.
The request/response pattern was modeled after how script eval
request/response works.  That is, a unique id is generated for every
request and the id is then used to correlate a request with a response.

BUG=115372
TEST=

[Jesse Greenwald, 2012-06-15 21:45:12]

jam, could you review:
  - content/browser/renderer_host/*
  - content/common/*
  - content/public/browser/*

avi, could you review:
  - content/renderer/*

[joth, 2012-06-15 21:57:00]

thanks Jesse.

https://chromiumcodereview.appspot.com/10553014/diff/1/content/public/browser...
File content/public/browser/render_view_host.h (right):

https://chromiumcodereview.appspot.com/10553014/diff/1/content/public/browser...
content/public/browser/render_view_host.h:261: // Determine wether or not the
document has any image elements.
typo: whether

https://chromiumcodereview.appspot.com/10553014/diff/1/content/public/browser...
content/public/browser/render_view_host.h:262: virtual int DocumentHasImages() =
0;
document the return value encoding. (I expected a bool from the description)

AIUI we'll want a reference to NOTIFICATION_DOCUMENT_HAS_IMAGES_RESPONSE here
too (as the return value only makes sense within that context, right?)

[Jesse Greenwald, 2012-06-26 23:06:29]

Addressed comments.  PTAL.

https://chromiumcodereview.appspot.com/10553014/diff/1/content/public/browser...
File content/public/browser/render_view_host.h (right):

https://chromiumcodereview.appspot.com/10553014/diff/1/content/public/browser...
content/public/browser/render_view_host.h:261: // Determine wether or not the
document has any image elements.
On 2012/06/15 21:57:00, joth wrote:
> typo: whether

Done.

https://chromiumcodereview.appspot.com/10553014/diff/1/content/public/browser...
content/public/browser/render_view_host.h:262: virtual int DocumentHasImages() =
0;
On 2012/06/15 21:57:00, joth wrote:
> document the return value encoding. (I expected a bool from the description)
> 
> AIUI we'll want a reference to NOTIFICATION_DOCUMENT_HAS_IMAGES_RESPONSE here
> too (as the return value only makes sense within that context, right?)

Done.

[joth, 2012-06-26 23:21:00]

LGTM but somebody else must approve.

[Jesse Greenwald, 2012-07-03 18:22:18]

jam, avi - can you take a look at this change?

Thanks,

[Jesse Greenwald, 2012-07-24 23:19:18]

jam - will you take a look at this because it's added a new content/public API? 
If you're not able to, can you give me an alternate reviewer?

[joth, 2012-08-10 17:59:42]

+jam for owner's approval

[jam, 2012-08-10 18:18:36]

it's not clear to me why this needs to change content at all. i.e. chrome on
android can do its own ipc and get to the webview through RenderView::GetWebView

[joth, 2012-08-10 21:02:25]

On 2012/08/10 18:18:36, John Abd-El-Malek wrote:
> it's not clear to me why this needs to change content at all. i.e. chrome on
> android can do its own ipc and get to the webview through
RenderView::GetWebView

Thanks John - good point. This patch has been sat around for a while, I think
with our new code layout plans putting this into android_webview will make a lot
more sense. (fortunately in this case, it's webview only function so no debate
needed on how to share it with chrome android)

We'll need to bring up a new android_webview_message.h IPC message header and
get that plumbed into place.

Just to confirm, RenderViewHost / RenderViewHostObserver is generally the API
the content client should use to send a request and receive back response on UI
thread?

[jam, 2012-08-10 22:03:15]

On 2012/08/10 21:02:25, joth wrote:
> On 2012/08/10 18:18:36, John Abd-El-Malek wrote:
> > it's not clear to me why this needs to change content at all. i.e. chrome on
> > android can do its own ipc and get to the webview through
> RenderView::GetWebView
> 
> Thanks John - good point. This patch has been sat around for a while, I think
> with our new code layout plans putting this into android_webview will make a
lot
> more sense. (fortunately in this case, it's webview only function so no debate
> needed on how to share it with chrome android)
> 
> We'll need to bring up a new android_webview_message.h IPC message header and
> get that plumbed into place.
> 
> Just to confirm, RenderViewHost / RenderViewHostObserver is generally the API
> the content client should use to send a request and receive back response on
UI
> thread?

yep

[joth, 2012-08-28 00:46:37]

On 2012/08/10 22:03:15, John Abd-El-Malek wrote:
> On 2012/08/10 21:02:25, joth wrote:
> > On 2012/08/10 18:18:36, John Abd-El-Malek wrote:
> > > it's not clear to me why this needs to change content at all. i.e. chrome
on
> > > android can do its own ipc and get to the webview through
> > RenderView::GetWebView
> > 
> > Thanks John - good point. This patch has been sat around for a while, I
think
> > with our new code layout plans putting this into android_webview will make a
> lot
> > more sense. (fortunately in this case, it's webview only function so no
debate
> > needed on how to share it with chrome android)
> > 
> > We'll need to bring up a new android_webview_message.h IPC message header
and
> > get that plumbed into place.
> > 
> > Just to confirm, RenderViewHost / RenderViewHostObserver is generally the
API
> > the content client should use to send a request and receive back response on
> UI
> > thread?
> 
> yep

Just started looking into this... I realized my RenderViewHostObserver would
also need to observe my WebContents (to get informed when the RenderViewHost is
created / changed). At which point, I found WebContentsObserver has Send() and
OnMessageReceived() methods so I could do everything right there with the higher
level API.
Any drawbacks to doing it that way instead?

Thanks,

[jam, 2012-08-28 02:19:18]

On 2012/08/28 00:46:37, joth wrote:
> On 2012/08/10 22:03:15, John Abd-El-Malek wrote:
> > On 2012/08/10 21:02:25, joth wrote:
> > > On 2012/08/10 18:18:36, John Abd-El-Malek wrote:
> > > > it's not clear to me why this needs to change content at all. i.e.
chrome
> on
> > > > android can do its own ipc and get to the webview through
> > > RenderView::GetWebView
> > > 
> > > Thanks John - good point. This patch has been sat around for a while, I
> think
> > > with our new code layout plans putting this into android_webview will make
a
> > lot
> > > more sense. (fortunately in this case, it's webview only function so no
> debate
> > > needed on how to share it with chrome android)
> > > 
> > > We'll need to bring up a new android_webview_message.h IPC message header
> and
> > > get that plumbed into place.
> > > 
> > > Just to confirm, RenderViewHost / RenderViewHostObserver is generally the
> API
> > > the content client should use to send a request and receive back response
on
> > UI
> > > thread?
> > 
> > yep
> 
> Just started looking into this... I realized my RenderViewHostObserver would
> also need to observe my WebContents (to get informed when the RenderViewHost
is
> created / changed). At which point, I found WebContentsObserver has Send() and
> OnMessageReceived() methods so I could do everything right there with the
higher
> level API.
> Any drawbacks to doing it that way instead?
> 
> Thanks,

WebContentsObserver is usually enough. The only times people need to use
RenderViewObserver is around navigations, when different RVHs are swapped.

[joth, 2012-08-28 19:46:37]

On 27 August 2012 19:19, <jam@chromium.org> wrote:

> On 2012/08/28 00:46:37, joth wrote:
>
>> On 2012/08/10 22:03:15, John Abd-El-Malek wrote:
>> > On 2012/08/10 21:02:25, joth wrote:
>> > > On 2012/08/10 18:18:36, John Abd-El-Malek wrote:
>> > > > it's not clear to me why this needs to change content at all. i.e.
>>
> chrome
>
>> on
>> > > > android can do its own ipc and get to the webview through
>> > > RenderView::GetWebView
>> > >
>> > > Thanks John - good point. This patch has been sat around for a while,
>> I
>> think
>> > > with our new code layout plans putting this into android_webview will
>> make
>>
> a
>
>> > lot
>> > > more sense. (fortunately in this case, it's webview only function so
>> no
>> debate
>> > > needed on how to share it with chrome android)
>> > >
>> > > We'll need to bring up a new android_webview_message.h IPC message
>> header
>> and
>> > > get that plumbed into place.
>> > >
>> > > Just to confirm, RenderViewHost / RenderViewHostObserver is generally
>> the
>> API
>> > > the content client should use to send a request and receive back
>> response
>>
> on
>
>> > UI
>> > > thread?
>> >
>> > yep
>>
>
>  Just started looking into this... I realized my RenderViewHostObserver
>> would
>> also need to observe my WebContents (to get informed when the
>> RenderViewHost
>>
> is
>
>> created / changed). At which point, I found WebContentsObserver has
>> Send() and
>> OnMessageReceived() methods so I could do everything right there with the
>>
> higher
>
>> level API.
>> Any drawbacks to doing it that way instead?
>>
>
>  Thanks,
>>
>
> WebContentsObserver is usually enough. The only times people need to use
> RenderViewObserver is around navigations, when different RVHs are swapped.
>
> Perfect, thanks.

[joth, 2012-08-30 21:28:16]

I've taken over this change as an android_webview IPC in
https://chromiumcodereview.appspot.com/10890024/