Fix InputConnection.deleteSurroundingText()

third_party/WebKit/public/web/WebFrame.h

Index: third_party/WebKit/public/web/WebFrame.h
diff --git a/third_party/WebKit/public/web/WebFrame.h b/third_party/WebKit/public/web/WebFrame.h
index 5b3d907d5ffb46b048a7d4a041613c2bdcd56260..65bd0fa8b1b41b0596b87b51d5f433904ac9ee30 100644
--- a/third_party/WebKit/public/web/WebFrame.h
+++ b/third_party/WebKit/public/web/WebFrame.h
@@ -459,6 +459,7 @@ public:
     virtual bool setEditableSelectionOffsets(int start, int end) = 0;
     virtual bool setCompositionFromExistingText(int compositionStart, int compositionEnd, const WebVector<WebCompositionUnderline>& underlines) = 0;
     virtual void extendSelectionAndDelete(int before, int after) = 0;
+    virtual void deleteSurroundingText(int before, int after) = 0;

[dcheng, 2016/04/16 03:37:07]

This doesn't look relevant to remote frames: can we add this to WebLocalFrame
instead?

[aelias_OOO_until_Jul13, 2016/04/16 03:43:29]

Why do you say that?  Remote frames can have textboxes just like local ones I
thought.  And this is just another IME method similar to the ones right above
it, so if you have a concern it's more general than this patch.

[dcheng, 2016/04/16 03:53:39]

In that case, the request should have been routed to the renderer hosting that
frame.

Consider the followup setup:

┌───────────── PROCESS 1 ─────────────┐
│┌───────────────────────────────────┐│
││    a.com (local)                  ││
││                                   ││
││   ┌───────────────────┐           ││
││   │  b.com (remote)   │           ││
││   │                   │           ││
││   └───────────────────┘           ││
│└───────────────────────────────────┘│
└─────────────────────────────────────┘

┌───────────── PROCESS 2 ─────────────┐
│┌───────────────────────────────────┐│
││    a.com (remote)                 ││
││                                   ││
││   ┌───────────────────┐           ││
││   │  b.com (local)    │           ││
││   │                   │           ││
││   └───────────────────┘           ││
│└───────────────────────────────────┘│
└─────────────────────────────────────┘

If the b.com frame has focus but the IME request is routed to [PROCESS 1],
there's nothing we can do with it: the DOM, etc is all in [PROCESS 2]. In order
for this to work correctly, the IME routing should have been talking to [PROCESS
2] to begin with.

This is reflected in the WebRemoteFrame methods for IME: they're all stubbed out
with NOTREACHED(). The only reason still on WebFrame is because we didn't use to
have the split between WebLocalFrame and WebRemoteFrame: most new methods should
only be on WebLocalFrame.

We have a longstanding cleanup task to move APIs that don't really belong on
WebFrame to WebLocalFrame, so eventually that will fix this inconsistency as
well.

 
     virtual void setCaretVisible(bool) = 0;