I noticed this while poking at EditCommands interactive test (which is disabled for Mac). This will be a regression so I figured pri-1 should be appropriate.

It appears as if the embedder is consuming the editing commands. I tried it in browser sample by just navigating webview to 'webview.html' in the zip file above. Pressing Cmd+A and Cmd+C and Cmd+V ends up selecting the URL box, copying its text, and pasting it there again.

Here is the problem:

(render_widget_host_view_mac.mm:3359)
- (void)copy:(id)sender {
  content::RenderWidgetHostDelegate* render_widget_host_delegate =
      renderWidgetHostView_->render_widget_host_->delegate();
  if (render_widget_host_delegate)
    render_widget_host_delegate->Copy();
}

and in web_contents_impl.cc:2936
void WebContentsImpl::Copy() {
  RenderFrameHost* focused_frame = GetFocusedFrame();
  if (!focused_frame)
    return;

  focused_frame->Send(new InputMsg_Copy(focused_frame->GetRoutingID()));
  RecordAction(base::UserMetricsAction("Copy"));
}

This is InputMsg_Copy which is being sent from RenderFrameHost and I personally find this confusing. For starters, those InputMsg going through the RWH always use GetFocusedRenderWidgetHost() which returns the RWH corresponding to the focused RFH in the focused WCImpl. But merely sending input to focused frame seems incorrect (Except in android where we don't have nested WebContents).

Also, another caller of WebContentsImpl::Copy seems to be 'TouchSelectionControllerClientAura' but I cannot test how this might work or fail on the platform. Looking at the code I believe it must be broken for similar reasons.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7b9e08e23f6e26b385619215fc80ac93d374a604

commit 7b9e08e23f6e26b385619215fc80ac93d374a604
Author: ekaramad <ekaramad@chromium.org>
Date: Tue May 16 16:58:35 2017

Fixed some edit commands for OOPIF-<webivew> (Mac)

OS edit commands for Mac are sent through WebContentsImpl which sends them to the
focused RenderFrame. This however does not play well with nested (inner)
WebContentses as GetFocusedFrame() returns the focused frame within the frame
tree of the WebContents only.

This CL fixes the issue with OOPIF-webviews by calling the corresponding edit
commands on the focused RenderWidgetHostDelegate (WebContentsImpl).

The CL also enables the WebViewInteractiveTest.EditCommands which was failing
on OOPIF-<webview>.

BUG= 721984 , 582562

Review-Url: https://codereview.chromium.org/2878153002
Cr-Commit-Position: refs/heads/master@{#472131}

[modify] https://crrev.com/7b9e08e23f6e26b385619215fc80ac93d374a604/chrome/browser/apps/guest_view/web_view_interactive_browsertest.cc
[modify] https://crrev.com/7b9e08e23f6e26b385619215fc80ac93d374a604/content/browser/renderer_host/render_widget_host_view_mac.h
[modify] https://crrev.com/7b9e08e23f6e26b385619215fc80ac93d374a604/content/browser/renderer_host/render_widget_host_view_mac.mm

Corrected "webview" to facilitate keyword search in issues.

Marking as fixed (verifiable on Canary 60.0.3102.0).

Also no need for merging I believe since we are targeting M60 for OOPIF <webview>.