mandoline: Fix character entry in html_viewer on Linux.

mandoline: Fix character entry in html_viewer on Linux.

This reverts my previous change (https://codereview.chromium.org/1232703006),
which fixed the double character insertion in the mandoline omnibox, but
broke all text entry in the html_viewer. The correct change was to make
sure we're using an InputMethodMandoline.

In https://codereview.chromium.org/1155013005/, InputMethodMandoline
appears to have been removed by accident while removing
InputMethodEventFilter. However, at least on Linux, we need to *not* use
InputMethodAuraLinux, which operates on a stream of X11 events, instead
of a stream of events that is designed to look like Windows events on
all platforms.

We don't see these problems on Windows because InputMethodWin is already
expecting a stream of events that looks like what Windows natively sends.

BUG=none

Committed: https://crrev.com/bb308a3bc1c07b89b117607af964e4b141bc8550
Cr-Commit-Position: refs/heads/master@{#339672}

[Elliot Glaysher, 2015-07-16 19:59:33]

erg@chromium.org changed reviewers:
+ sadrul@chormium.org, shuchen@chromium.org

[Elliot Glaysher, 2015-07-16 19:59:33]

sadrul: review. Yesterday's change was the Wrong Thing[tm].
shuchen: fyi

[Elliot Glaysher, 2015-07-16 21:43:16]

erg@chromium.org changed reviewers:
+ sadrul@chromium.org
- sadrul@chormium.org

[Elliot Glaysher, 2015-07-16 21:43:34]

sadrul: review. Yesterday's change was the Wrong Thing[tm].
shuchen: fyi

(Resending because I sent to the wrong sadrul.)

[Shu Chen, 2015-07-17 01:54:08]

shuchen@chromium.org changed reviewers:
+ suzhe@chromium.org

[Shu Chen, 2015-07-17 01:54:09]

Can you please share some docs to help me understand more about Mojo's
architecture?

+suzhe@ who may have more insights on this.

https://codereview.chromium.org/1234623004/diff/40001/components/view_manager...
File components/view_manager/display_manager.cc (right):

https://codereview.chromium.org/1234623004/diff/40001/components/view_manager...
components/view_manager/display_manager.cc:283: // We want to emulate the
WM_CHAR generation behaviour of Windows.
I don't recommend to emulate the WM_CHAR, because WM_KEYDOWN doesn't always
cause a WM_CHAR.

As input method is a platform dependent thing, why not instead implement 2
classes?
 - InputMethodMandolineX11
 - InputMethodMandolineWin

https://codereview.chromium.org/1234623004/diff/40001/mandoline/ui/aura/windo...
File mandoline/ui/aura/window_tree_host_mojo.cc (right):

https://codereview.chromium.org/1234623004/diff/40001/mandoline/ui/aura/windo...
mandoline/ui/aura/window_tree_host_mojo.cc:44:
SetSharedInputMethod(input_method_.get());
Please notice that my refactoring cl
https://codereview.chromium.org/1236923003/diff/60001/ui/aura/window_tree_hos...
will avoid dispatching key events to input method in aura::WindowTreeHost.
Instead, the subclass'es of aura::WindowTreeHost needs to take care of it.

[James Su, 2015-07-17 04:13:54]

I cannot give any concrete comments without understanding the whole picture.

Please share background and design docs to us.

Specifically I want to know:
1. What's the relationship between aura/views and mojo?
2. In mandoline, where is the platform abstraction layer? What's the
relationship between this layer and the current DesktopWindowTreeHostXxx layer?

[Elliot Glaysher, 2015-07-17 17:52:36]

go/what-is-mandoline

What we want to do is rebuild chrome from the ground up as a set of services in
their own processes which talk to each other over the mojo IPC system.

components/view_manager/ is our cross platform view manager which owns the
handle to the native window, and presents an interface so that different
processes can draw ui and receive events (the browser_ui, toplevel html_viewer,
iframes, pdfium, etc.)

In the current mandoline prototype (and all this is currently experimental),
the view_manager process communicates to and composites from the html_viewer
process (which uses no views/aura) and the omnibox process (which does use
views/aura). We serialize the ui::Event structure over IPC from the view_manager
process to whoever currently has input focus.

(So anything that relies on having the native event in a sandboxed process isn't
going to work, and taking a second look through the InputMethodWin code, it
looks like I should expand the InputMethodMandoline setting to all platforms
like it previously was since InputMethodWin is just treating everything as
a fabricated event.)

Long term, views/aura shouldn't know anything about input methods, the
view_manager should have a mojo interface for an input method to plug into that
abstracts away platform differences.

https://codereview.chromium.org/1234623004/diff/40001/components/view_manager...
File components/view_manager/display_manager.cc (right):

https://codereview.chromium.org/1234623004/diff/40001/components/view_manager...
components/view_manager/display_manager.cc:283: // We want to emulate the
WM_CHAR generation behaviour of Windows.
On 2015/07/17 01:54:08, Shu Chen wrote:
> I don't recommend to emulate the WM_CHAR, because WM_KEYDOWN doesn't always
> cause a WM_CHAR.

This is part of the patch which was a revert. That said, if there are more
detailed rules, we should be following them here, because we want things that
connect to the view_manager to not have to care about platform differences.

[James Su, 2015-07-18 03:30:41]

On 2015/07/17 17:52:36, Elliot Glaysher wrote:
> go/what-is-mandoline
> 
> What we want to do is rebuild chrome from the ground up as a set of services
in
> their own processes which talk to each other over the mojo IPC system.
> 
> components/view_manager/ is our cross platform view manager which owns the
> handle to the native window, and presents an interface so that different
> processes can draw ui and receive events (the browser_ui, toplevel
html_viewer,
> iframes, pdfium, etc.)
> 
> In the current mandoline prototype (and all this is currently experimental),
> the view_manager process communicates to and composites from the html_viewer
> process (which uses no views/aura) and the omnibox process (which does use
> views/aura). We serialize the ui::Event structure over IPC from the
view_manager
> process to whoever currently has input focus.
> 
> (So anything that relies on having the native event in a sandboxed process
isn't
> going to work, and taking a second look through the InputMethodWin code, it
> looks like I should expand the InputMethodMandoline setting to all platforms
> like it previously was since InputMethodWin is just treating everything as
> a fabricated event.)
> 
> Long term, views/aura shouldn't know anything about input methods, the
> view_manager should have a mojo interface for an input method to plug into
that
> abstracts away platform differences.
> 
>
https://codereview.chromium.org/1234623004/diff/40001/components/view_manager...
> File components/view_manager/display_manager.cc (right):
> 
>
https://codereview.chromium.org/1234623004/diff/40001/components/view_manager...
> components/view_manager/display_manager.cc:283: // We want to emulate the
> WM_CHAR generation behaviour of Windows.
> On 2015/07/17 01:54:08, Shu Chen wrote:
> > I don't recommend to emulate the WM_CHAR, because WM_KEYDOWN doesn't always
> > cause a WM_CHAR.
> 
> This is part of the patch which was a revert. That said, if there are more
> detailed rules, we should be following them here, because we want things that
> connect to the view_manager to not have to care about platform differences.

Thank you for your information, following are my thoughts based on my
understanding to this information:

1. Looks like in this new architecture the UI process (like the current browser
process) will be a very thin layer, it's simply convert platform events and
graphics operations into IPC and send them to component processes for handling.
Is this understanding correct?

2. If 1. is true, then it means everything from native platform will be handled
asynchronously.

3. Input method is very different than normal native events (like key or mouse
events), which requires extensive synchronous method calls between native
platform IME service and application.
On Windows, it's done via IMM32 and TSF API, on Linux it's done via GtkIMModule
API, on Mac it's done via NSTextInputClient and NSInputManager API.
All of them are synchronous bi-directional APIs, by which the system may call
into the application to get various information synchronously, and the
application may also call into the system to let the system IME perform a
certain action synchronously.

In current aura/views world, we introduced ui::InputMethod API and
ui::TextInputClient API to encapsulate the corresponding native platform IME API
in a cross-platform manner. So inside chrome, if a component wants to support
text input, it just needs to implement ui::TextInputClient API and call back
ui::InputMethod API when necessary, you can see views::TextField as an example.

Specifically, ui::InputMethodWin is not just handling fabricated events, it has
lots of complicated logic for communicating with ui::TextInputClient API and
calling back to system via IMM32 and TSF API synchronously.

In order to make input method works inside a web page, we convert such
bi-directional synchronous API calls into async IPC in RWH/RWHV and Renderer
layer. the conversion is extremely complicated and far from perfect. Although it
has been working for years, it still has lots of issues and cannot support many
scenarios. Mostly because:
1. System IME service will call into application synchronously to retrieve some
information, things like, but not limit to:
1) type of the current text box.
2) the location of the caret, or the selection range or even bounding box of
each character in selected text.
3) the currently selected text
4) the surrounding text before and after the current caret
5) the text under the mouse cursor (Only on Mac)

As we can't do synchronous call via IPC, we need to send all of these
information from renderer to to browser in advanced. In another word, we need to
continuously update these information from renderer to browser whenever they get
changed. See ViewHostMsg_TextInputStateChanged message as an example, there are
several other related messages beside this one.

In order to save IPC cost, we cannot send every thing from renderer to browser,
such as 4) and 5). For 4) we can only send a very small piece of surrounding
text, but for 5) there is no way for us to support it asynchronously, thus 5) is
actually implemented by a synchronous IPC call, see:
https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/re...

2. Even worse, the system ime may call into application synchronously to
retrieve some information immediately after sending some information to the
application, and the information to be retrieved will be updated according to
the newly received information. For example the system IME may update the
composition and then retrieve the selection range (or the caret position)
immediately. In such case there is no way for us to return the up-to-date
information back to the system IME synchronously, if everything is handled in
renderer process in async mode.

In short: asynchronous IPC causes enormous problem in IME support. In perfect
world, it'd be great if the system can provide us a fully asynchronous IME API.
But in reality, we still need to struggle with fully synchronous system IME
APIs.

So back to mandoline, looks like we need to replicate all of the hacky thing we
have done in the current IPC layer between browser and renderer for supporting
IME in the new mojo IPC layer, and introduce a new IME module in view_manager to
convert synchronous platform IME APIs into asynchronous mojo IPC messages.

The new IPC module can be built on top of existing ui:InputMethod
implementations, in another word, we can implement a special ui::TextInputClient
class to convert all synchronous API calls into async mojo IPC messages, and
hook this ui::TextInputClient object into existing ui::InputMethodXxx. 

And in the component side, we need a special ui::InputMethod implementation to
convert mojo IPC messages back into synchronous calls to ui::TextInputClient
API, so that existing text box (like views::TextField) can still work out of
box.

A simple diagram:

ViewManager                                            Process boundary (mojo
IPC)                                components                
------------------------------------------------------|        
|--------------------------------------------------------------------------
ui::InputMethodWin <-> ui::TextInputClientMojo <---> mojo::InputMethodMojo <->
ui::TextInputClient (views::TextField)

[Elliot Glaysher, 2015-07-20 19:56:51]

So all of that is interesting and certainly needs to be addressed, right now we
don't even have layout tests on the shell, input methods don't work at all, and
this patch fixes a regression which is keeping us from typing in the content
window at all.

sadrul: ping owners review.

[sadrul, 2015-07-21 07:28:54]

lgtm

[Elliot Glaysher, 2015-07-21 16:53:04]

The CQ bit was checked by erg@chromium.org

[commit-bot: I haz the power, 2015-07-21 16:53:47]

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

[commit-bot: I haz the power, 2015-07-21 17:15:06]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2015-07-21 17:16:31]

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