Ensure that the OSK on Windows 8 shows up when we tap on an editable field in any WebContents.

Ensure that the OSK on Windows 8 shows up when we tap on an editable field in any WebContents.

The current implementation was displaying the OSK only when we tapped on a WebContents hosted by a Browser window. This
relied on the ChromeRenderViewObserver object in the renderer sending an IPC message ChromeViewHostMsg_FocusedNodeTouched
which is handled by the Chrome browser code via a WebContentsObserver implementation.

Based on discussions with jam and comments from avi in the review, we decided to implement this functionality in content.

Fixes are as below:-
1. We have a new IPc message ViewHostMsg_FocusedNodeTouched which is defined in the view_messages.h file.
2. This IPC is sent by the RenderViewImpl::didHandleGestureEvent method if we tapped on an editable field.
3, This IPC is handled by the RenderViewHostImpl class. We display the OSK on Windows 8 Aura if a focused editable
   node was tapped.
4. The ChromeViewHostMsg_FocusedNodeTouched IPC has been deleted along with the didHandleGestureEvent method in the
   RenderViewObserver interface.

BUG=321576, 319219
R=jam@chromium.org, palmer@chromium.org, jam
TBR=jschuh

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=237646

[Avi (use Gerrit), 2013-11-27 14:55:45]

This sounds like rather essential functionality, having the onscreen keyboard
show up when it needs to. I'd argue for putting this into content, actually. It
really does need to be in every WebContents.

jam@, WDYT?

[jam, 2013-11-27 17:17:40]

On 2013/11/27 14:55:45, Avi wrote:
> This sounds like rather essential functionality, having the onscreen keyboard
> show up when it needs to. I'd argue for putting this into content, actually.
It
> really does need to be in every WebContents.
> 
> jam@, WDYT?

In talking with Ananta, it seemed that this is Chrome specific UI. Will every
embedder of content want this to happen on Windows 8?

https://codereview.chromium.org/89873002/diff/40001/chrome/browser/ui/tab_con...
File chrome/browser/ui/tab_contents/core_tab_helper.cc (right):

https://codereview.chromium.org/89873002/diff/40001/chrome/browser/ui/tab_con...
chrome/browser/ui/tab_contents/core_tab_helper.cc:47:
TouchWebContentsObserver::CreateForWebContents(web_contents);
this should be created where CoreTabHelper gets created, not inside
CoreTabHelper. i.e. move this to BrowserTabContents::AttachTabHelpers.

https://codereview.chromium.org/89873002/diff/40001/chrome/chrome_browser_ui....
File chrome/chrome_browser_ui.gypi (right):

https://codereview.chromium.org/89873002/diff/40001/chrome/chrome_browser_ui....
chrome/chrome_browser_ui.gypi:72:
'browser/ui/touch_web_contents_observer_win.cc',
nit: tabs

[Avi (use Gerrit), 2013-11-27 17:43:11]

On 2013/11/27 17:17:40, jam wrote:
> In talking with Ananta, it seemed that this is Chrome specific UI. Will every
> embedder of content want this to happen on Windows 8?

Is there a chrome-specific OSK?

I'm imagining an embedder of content, perhaps even Content Shell. I want to get
it working on Windows 8, and of course I need the OSK to come up when an
editable field is tapped. So I have to write code. Boilerplate, which makes this
silly.

If Chrome needs to have a Chrome-specific OSK, fine, but I would argue that
bringing up an OSK so that the user can actually use the web page they're
looking at is basic functionality that belongs in content.

Can we have something in, say, ContentBrowserClient that allows an embedder to
override the choice of OSK, but if it's not implemented, content is smart enough
to bring up the standard Win8 OSK?

[jam, 2013-11-27 17:50:31]

On 2013/11/27 17:43:11, Avi wrote:
> On 2013/11/27 17:17:40, jam wrote:
> > In talking with Ananta, it seemed that this is Chrome specific UI. Will
every
> > embedder of content want this to happen on Windows 8?
> 
> Is there a chrome-specific OSK?
> 
> I'm imagining an embedder of content, perhaps even Content Shell. I want to
get
> it working on Windows 8, and of course I need the OSK to come up when an
> editable field is tapped. So I have to write code. Boilerplate, which makes
this
> silly.
> 
> If Chrome needs to have a Chrome-specific OSK, fine, but I would argue that
> bringing up an OSK so that the user can actually use the web page they're
> looking at is basic functionality that belongs in content.
> 
> Can we have something in, say, ContentBrowserClient that allows an embedder to
> override the choice of OSK, but if it's not implemented, content is smart
enough
> to bring up the standard Win8 OSK?

if every embedder of chrome wants this, i'm fine with doing it always. i'd
prefer always doing this inside content, or outside as is, then to adding to CBC

[Avi (use Gerrit), 2013-11-27 18:03:09]

On 2013/11/27 17:50:31, jam wrote:
> On 2013/11/27 17:43:11, Avi wrote:
> > On 2013/11/27 17:17:40, jam wrote:
> > > In talking with Ananta, it seemed that this is Chrome specific UI. Will
> every
> > > embedder of content want this to happen on Windows 8?
> > 
> > Is there a chrome-specific OSK?
> > 
> > I'm imagining an embedder of content, perhaps even Content Shell. I want to
> get
> > it working on Windows 8, and of course I need the OSK to come up when an
> > editable field is tapped. So I have to write code. Boilerplate, which makes
> this
> > silly.
> > 
> > If Chrome needs to have a Chrome-specific OSK, fine, but I would argue that
> > bringing up an OSK so that the user can actually use the web page they're
> > looking at is basic functionality that belongs in content.
> > 
> > Can we have something in, say, ContentBrowserClient that allows an embedder
to
> > override the choice of OSK, but if it's not implemented, content is smart
> enough
> > to bring up the standard Win8 OSK?
> 
> if every embedder of chrome wants this, i'm fine with doing it always. i'd
> prefer always doing this inside content, or outside as is, then to adding to
CBC

You don't seem convinced. Here's my scenario and question:

- A random app embedding content is run on Windows 8. The user using that app
taps on a text field. Should the app developer expect that in this scenario, an
OSK should appear?

My answer is yes. My rationale is: Being able to actually type into <input>
fields is basic functionality. Typing into an input field on Win8 requires an
OSK. The <input> tag is part of the web platform. If something is part of the
web platform, it belongs in content. Therefore, implementing basic OSK support
belongs in content.

Making it extensible by the embedder is a great goal. But basic support for
basic functionality needs to be in there. We implement IMEs in content, yes?
Why? Because people want to actually put characters into <input> fields. I fail
to see why a basic OSK is any different than an IME.

[jam, 2013-11-27 18:13:06]

On 2013/11/27 18:03:09, Avi wrote:
> On 2013/11/27 17:50:31, jam wrote:
> > On 2013/11/27 17:43:11, Avi wrote:
> > > On 2013/11/27 17:17:40, jam wrote:
> > > > In talking with Ananta, it seemed that this is Chrome specific UI. Will
> > every
> > > > embedder of content want this to happen on Windows 8?
> > > 
> > > Is there a chrome-specific OSK?
> > > 
> > > I'm imagining an embedder of content, perhaps even Content Shell. I want
to
> > get
> > > it working on Windows 8, and of course I need the OSK to come up when an
> > > editable field is tapped. So I have to write code. Boilerplate, which
makes
> > this
> > > silly.
> > > 
> > > If Chrome needs to have a Chrome-specific OSK, fine, but I would argue
that
> > > bringing up an OSK so that the user can actually use the web page they're
> > > looking at is basic functionality that belongs in content.
> > > 
> > > Can we have something in, say, ContentBrowserClient that allows an
embedder
> to
> > > override the choice of OSK, but if it's not implemented, content is smart
> > enough
> > > to bring up the standard Win8 OSK?
> > 
> > if every embedder of chrome wants this, i'm fine with doing it always. i'd
> > prefer always doing this inside content, or outside as is, then to adding to
> CBC
> 
> You don't seem convinced. Here's my scenario and question:
> 
> - A random app embedding content is run on Windows 8. The user using that app
> taps on a text field. Should the app developer expect that in this scenario,
an
> OSK should appear?
> 
> My answer is yes. My rationale is: Being able to actually type into <input>
> fields is basic functionality. Typing into an input field on Win8 requires an
> OSK. The <input> tag is part of the web platform. If something is part of the
> web platform, it belongs in content. Therefore, implementing basic OSK support
> belongs in content.
> 
> Making it extensible by the embedder is a great goal. But basic support for
> basic functionality needs to be in there. We implement IMEs in content, yes?
> Why? Because people want to actually put characters into <input> fields. I
fail
> to see why a basic OSK is any different than an IME.

Sorry I wasn't clear. I just didn't know enough about this IPC to know whether
this is basic functionality or not. i.e. does this IPC not get delivered on
desktops or laptops when there's a keyboard attached? If so, then I agree with
your logic and putting it in content sgtm

[ananta, 2013-11-27 20:52:38]

As per avi's comments and a discussion with jam, moved this functionality to
content\renderer and content\browser.

[jam, 2013-11-27 22:22:00]

lgtm

https://codereview.chromium.org/89873002/diff/60001/content/browser/renderer_...
File content/browser/renderer_host/render_view_host_impl.cc (right):

https://codereview.chromium.org/89873002/diff/60001/content/browser/renderer_...
content/browser/renderer_host/render_view_host_impl.cc:2246: #endif  //
?

[ananta, 2013-11-27 22:57:13]

https://codereview.chromium.org/89873002/diff/60001/content/browser/renderer_...
File content/browser/renderer_host/render_view_host_impl.cc (right):

https://codereview.chromium.org/89873002/diff/60001/content/browser/renderer_...
content/browser/renderer_host/render_view_host_impl.cc:2246: #endif  //
On 2013/11/27 22:22:01, jam wrote:
> ?

Done.

[ananta, 2013-11-27 23:19:46]

+palmer for IPC review. Please review the changes to render_messages.h and
view_messages.h

Thanks
Ananta

[palmer, 2013-11-27 23:39:12]

IPC security LGTM.

[ananta, 2013-11-27 23:46:27]

TBR'ing jschuh for content\common\view_messages.h

[ananta, 2013-11-27 23:47:17]

Committed patchset #5 manually as r237646.