Add support for edit commands in OOPIFs.

Add support for edit commands in OOPIFs.

Previously, edit commands from the browser were sent via
InputMsg_SetEditCommandsForNextKeyEvent to focused RenderWidgets, but
for OOPIFs the IPC was dropped since it was only handled in
RenderViews.  To fix this, this CL moves the IPC handling and
associated edit command bookkeeping to RenderWidget.

BUG=640706
Committed: https://crrev.com/5656749d827dc6af03caed97958bd1ff035d1e61
Cr-Commit-Position: refs/heads/master@{#418126}

[alexmos, 2016-08-27 00:11:28]

The CQ bit was checked by [email protected] to run a CQ dry run

[commit-bot: I haz the power, 2016-08-27 00:12:24]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-27 00:22:40]

The CQ bit was unchecked by [email protected]

[commit-bot: I haz the power, 2016-08-27 00:22:41]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[alexmos, 2016-08-30 17:57:35]

The CQ bit was checked by [email protected] to run a CQ dry run

[commit-bot: I haz the power, 2016-08-30 17:58:25]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-30 18:05:55]

The CQ bit was unchecked by [email protected]

[commit-bot: I haz the power, 2016-08-30 18:05:56]

Dry run: Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[alexmos, 2016-08-31 22:01:57]

The CQ bit was checked by [email protected] to run a CQ dry run

[commit-bot: I haz the power, 2016-08-31 22:02:52]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[alexmos, 2016-08-31 23:00:35]

[email protected] changed reviewers:
+ [email protected]

[alexmos, 2016-08-31 23:00:36]

Lucas, can you please take an initial look?  This is somewhat related to the
view/widget split you've been working on.

This is a straightforward move of the edit commands IPC and bookkeeping from
RenderView to RenderWidget with two quirks below - let me know if you have any
thoughts about them:

- for now, I left the SetEditCommandForNextKeyEvent/ClearEditCommands exposed in
the public interface in render_view.h.  These are used by the BlinkTestRunner
for eventSender.keyDown(), and I didn't see a straightforward way to move those
to use the widget instead (BlinkTestRunner is a RenderViewObserver,
render_widget.h isn't in content/public, etc.).  Perhaps one option could be to
convert these calls in EventSender to go through the WebWidget public API
instead, using  web_view_test_proxy_base_ (and possibly convert EventSender to
be associated with web_widget_test_proxy_base_ instead?).  But that kind of felt
like it should be in its own CL.

- I moved handleCurrentKeyboardEvent() from WebViewClient to WebFrameClient(). 
This is used by Blink to ask the embedder whether there are any edit commands
defined while processing a key event.  The other option was to move it to
WebWidgetClient, but that required plumbing the source frame on which to execute
the edit commands to RenderWidget, which didn't feel right. (Previously, this
frame was looked up via WebView::focusedFrame(), which seemed bad in itself and
wouldn't have worked from RenderWidget).

[commit-bot: I haz the power, 2016-08-31 23:26:05]

The CQ bit was unchecked by [email protected]

[commit-bot: I haz the power, 2016-08-31 23:26:06]

Dry run: This issue passed the CQ dry run.

[Charlie Reis, 2016-09-02 00:08:16]

Description was changed from

==========
Add support for edit commands in OOPIFs.

Previously, edit commands from the browser were sent via
InputMsg_SetEditCommandsForNextKeyEvent to focused RenderWidgets, but
for OOPIFs the IPC was dropped since it was only handled in
RenderViews.  To fix this, this CL moves the IPC handling and
associated edit command bookkeeping to RenderWidget.

BUG=640706
==========

to

==========
Add support for edit commands in OOPIFs.

Previously, edit commands from the browser were sent via
InputMsg_SetEditCommandsForNextKeyEvent to focused RenderWidgets, but
for OOPIFs the IPC was dropped since it was only handled in
RenderViews.  To fix this, this CL moves the IPC handling and
associated edit command bookkeeping to RenderWidget.

BUG=640706
==========

[lfg, 2016-09-02 17:20:02]

lgtm

On 2016/08/31 23:00:36, alexmos (OOO until 9-6) wrote:
> Lucas, can you please take an initial look?  This is somewhat related to the
> view/widget split you've been working on.
> 
> This is a straightforward move of the edit commands IPC and bookkeeping from
> RenderView to RenderWidget with two quirks below - let me know if you have any
> thoughts about them:
> 
> - for now, I left the SetEditCommandForNextKeyEvent/ClearEditCommands exposed
in
> the public interface in render_view.h.  These are used by the BlinkTestRunner
> for eventSender.keyDown(), and I didn't see a straightforward way to move
those
> to use the widget instead (BlinkTestRunner is a RenderViewObserver,
> render_widget.h isn't in content/public, etc.).  Perhaps one option could be
to
> convert these calls in EventSender to go through the WebWidget public API
> instead, using  web_view_test_proxy_base_ (and possibly convert EventSender to
> be associated with web_widget_test_proxy_base_ instead?).  But that kind of
felt
> like it should be in its own CL.

I think this should be plumbed through WebFrameTestProxy, since we are already
plumbing the rest through WebFrameClient. This doesn't seem like a trivial
change though, because you'll first need a way to find the correct frame to send
the event, then from the frame you'll need a way to find the WebFrameTestProxy.
Also, note that plumbing through WebWidget is not any easier, you'll still need
to find which widget to send it through.

Let's just add a TODO() to the RenderViewImpl functions to remember that this
needs to be fixed.

> - I moved handleCurrentKeyboardEvent() from WebViewClient to WebFrameClient().

> This is used by Blink to ask the embedder whether there are any edit commands
> defined while processing a key event.  The other option was to move it to
> WebWidgetClient, but that required plumbing the source frame on which to
execute
> the edit commands to RenderWidget, which didn't feel right. (Previously, this
> frame was looked up via WebView::focusedFrame(), which seemed bad in itself
and
> wouldn't have worked from RenderWidget).

It's not related to your change, as it was already like this before, but I find
it strange that the edit commands are executed per-frame, but they are stored
per-widget.

https://codereview.chromium.org/2287803002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/web/EditorClientImpl.cpp (right):

https://codereview.chromium.org/2287803002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/web/EditorClientImpl.cpp:79: return webFrame->client()
&& webFrame->client()->handleCurrentKeyboardEvent();
I think the WebLocalFrame client is always non-null. Can you try that?

[alexmos, 2016-09-06 23:52:44]

The CQ bit was checked by [email protected] to run a CQ dry run

[commit-bot: I haz the power, 2016-09-06 23:53:03]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[alexmos, 2016-09-07 00:03:00]

Thanks!  Responses below. 

> I think this should be plumbed through WebFrameTestProxy, since we are already
> plumbing the rest through WebFrameClient. This doesn't seem like a trivial
> change though, because you'll first need a way to find the correct frame to
send
> the event, then from the frame you'll need a way to find the
WebFrameTestProxy.
> Also, note that plumbing through WebWidget is not any easier, you'll still
need
> to find which widget to send it through.
> 
> Let's just add a TODO() to the RenderViewImpl functions to remember that this
> needs to be fixed.

Done, I added a TODO to render_view.h.  I agree that it makes sense to unify
these with handleCurrentKeyboardEvent in WebFrameClient, and that plumbing the
target frame through seems non-trivial for this CL.

> It's not related to your change, as it was already like this before, but I
find
> it strange that the edit commands are executed per-frame, but they are stored
> per-widget.

I find it a bit strange as well, but I guess sending edit commands just mimics
the way we send keyboard events, which is through the widget.  Now that the
browser process knows the currently focused frame, perhaps we can send all of
those through the frame, though that's a much larger cleanup.

https://codereview.chromium.org/2287803002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/web/EditorClientImpl.cpp (right):

https://codereview.chromium.org/2287803002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/web/EditorClientImpl.cpp:79: return webFrame->client()
&& webFrame->client()->handleCurrentKeyboardEvent();
On 2016/09/02 17:20:02, lfg wrote:
> I think the WebLocalFrame client is always non-null. Can you try that?

I thought it can be null in blink unit tests.  There's an example just above in
respondToChangedSelection, and in general the other uses of
WebLocalFrameImpl::client() seem null-checked:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/web/WebLocalFr...

[alexmos, 2016-09-07 00:05:12]

[email protected] changed reviewers:
+ [email protected], [email protected]

[alexmos, 2016-09-07 00:05:13]

Charlie, can you please review content/ for OWNERS?  And Daniel, can you please
review the Blink bits?

[commit-bot: I haz the power, 2016-09-07 01:38:45]

The CQ bit was unchecked by [email protected]

[commit-bot: I haz the power, 2016-09-07 01:38:46]

Dry run: This issue passed the CQ dry run.

[Charlie Reis, 2016-09-07 20:41:42]

content/ and test LGTM with nits.

https://codereview.chromium.org/2287803002/diff/60001/chrome/browser/site_per...
File chrome/browser/site_per_process_interactive_browsertest.cc (right):

https://codereview.chromium.org/2287803002/diff/60001/chrome/browser/site_per...
chrome/browser/site_per_process_interactive_browsertest.cc:185:
SubframeKeyboardEditCommands) {
I think this might belong more in site_per_process_text_input_browsertest.cc
(which Ehsan has been using for IME tests)?

No problem leaving it here if that's not an easy move.

https://codereview.chromium.org/2287803002/diff/60001/chrome/browser/site_per...
chrome/browser/site_per_process_interactive_browsertest.cc:250: // commands
logic that's's tested here.
nit: that's

[alexmos, 2016-09-08 20:57:46]

The CQ bit was checked by [email protected] to run a CQ dry run

[commit-bot: I haz the power, 2016-09-08 20:58:29]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[alexmos, 2016-09-08 21:00:07]

Daniel: friendly ping for the Blink-side review :)
Charlie: thanks - nits fixed.

https://codereview.chromium.org/2287803002/diff/60001/chrome/browser/site_per...
File chrome/browser/site_per_process_interactive_browsertest.cc (right):

https://codereview.chromium.org/2287803002/diff/60001/chrome/browser/site_per...
chrome/browser/site_per_process_interactive_browsertest.cc:185:
SubframeKeyboardEditCommands) {
On 2016/09/07 20:41:42, Charlie Reis (slow) wrote:
> I think this might belong more in site_per_process_text_input_browsertest.cc
> (which Ehsan has been using for IME tests)?
> 
> No problem leaving it here if that's not an easy move.

Done.  It was straightforward to move. :)

https://codereview.chromium.org/2287803002/diff/60001/chrome/browser/site_per...
chrome/browser/site_per_process_interactive_browsertest.cc:250: // commands
logic that's's tested here.
On 2016/09/07 20:41:42, Charlie Reis (slow) wrote:
> nit: that's

Done.

[commit-bot: I haz the power, 2016-09-09 00:18:34]

The CQ bit was unchecked by [email protected]

[commit-bot: I haz the power, 2016-09-09 00:18:35]

Dry run: This issue passed the CQ dry run.

[dcheng, 2016-09-09 06:28:28]

blink bits seem fine, but I'm not sure the null checks are necessary: they were
necessary for WebView because we allow people to pass a null WebViewClient, but
that's (mostly) not allowed with WebFrameClient. In addition, we clear
document's pointer back to the LocalFrame when we detach the frame, and all this
code is getting to the frame via the Document. So maybe we can just DCHECK
instead?

[alexmos, 2016-09-12 23:03:00]

The CQ bit was checked by [email protected] to run a CQ dry run

[commit-bot: I haz the power, 2016-09-12 23:03:42]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-13 00:23:44]

The CQ bit was unchecked by [email protected]

[commit-bot: I haz the power, 2016-09-13 00:23:45]

Dry run: This issue passed the CQ dry run.

[alexmos, 2016-09-13 00:35:33]

Daniel, PTAL.

On 2016/09/09 06:28:28, dcheng wrote:
> blink bits seem fine, but I'm not sure the null checks are necessary: they
were
> necessary for WebView because we allow people to pass a null WebViewClient,
but
> that's (mostly) not allowed with WebFrameClient. In addition, we clear
> document's pointer back to the LocalFrame when we detach the frame, and all
this
> code is getting to the frame via the Document. So maybe we can just DCHECK
> instead?

Done.  Thanks for the explanation; I removed the two null checks and nothing
exploded. :)  A DCHECK seemed redundant, since we'd just crash on the next line,
so I just removed the checks.  Any explanation for why we have so many other
webFrame->client() null checks?  Did we allow a null WebFrameClient at some
point in the past, or are they there for the detach case?

[dcheng, 2016-09-13 00:45:43]

lgtm

[alexmos, 2016-09-13 00:48:26]

The CQ bit was checked by [email protected]

[alexmos, 2016-09-13 00:48:26]

The patchset sent to the CQ was uploaded after l-g-t-m from [email protected],
[email protected]
Link to the patchset: https://codereview.chromium.org/2287803002/#ps100001
(title: "Remove WebFrameClient null checks")

[commit-bot: I haz the power, 2016-09-13 00:48:51]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-13 00:53:10]

Description was changed from

==========
Add support for edit commands in OOPIFs.

Previously, edit commands from the browser were sent via
InputMsg_SetEditCommandsForNextKeyEvent to focused RenderWidgets, but
for OOPIFs the IPC was dropped since it was only handled in
RenderViews.  To fix this, this CL moves the IPC handling and
associated edit command bookkeeping to RenderWidget.

BUG=640706
==========

to

==========
Add support for edit commands in OOPIFs.

Previously, edit commands from the browser were sent via
InputMsg_SetEditCommandsForNextKeyEvent to focused RenderWidgets, but
for OOPIFs the IPC was dropped since it was only handled in
RenderViews.  To fix this, this CL moves the IPC handling and
associated edit command bookkeeping to RenderWidget.

BUG=640706
==========

[commit-bot: I haz the power, 2016-09-13 00:53:12]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2016-09-13 00:54:48]

Description was changed from

==========
Add support for edit commands in OOPIFs.

Previously, edit commands from the browser were sent via
InputMsg_SetEditCommandsForNextKeyEvent to focused RenderWidgets, but
for OOPIFs the IPC was dropped since it was only handled in
RenderViews.  To fix this, this CL moves the IPC handling and
associated edit command bookkeeping to RenderWidget.

BUG=640706
==========

to

==========
Add support for edit commands in OOPIFs.

Previously, edit commands from the browser were sent via
InputMsg_SetEditCommandsForNextKeyEvent to focused RenderWidgets, but
for OOPIFs the IPC was dropped since it was only handled in
RenderViews.  To fix this, this CL moves the IPC handling and
associated edit command bookkeeping to RenderWidget.

BUG=640706

Committed: https://crrev.com/5656749d827dc6af03caed97958bd1ff035d1e61
Cr-Commit-Position: refs/heads/master@{#418126}
==========

[commit-bot: I haz the power, 2016-09-13 00:54:50]

Patchset 6 (id:??) landed as
https://crrev.com/5656749d827dc6af03caed97958bd1ff035d1e61
Cr-Commit-Position: refs/heads/master@{#418126}