Reland: Add RenderFrameHost as parameter to WebContentsDelegate::HandleContextMenu

This is a reland of the following change:
  commit 5705b913a577759d16b3eca7d5b0e7b5c79421f6

Reverted in 328cae2c82cb2e079658944f626883df74ed5c5a

Fix for reland:
In HandleContextMenuDelegate unittest, return true
to stop the tested WebContents instance to call

On some platforms (android) the WebContentsView
implementation assumes that the RenderWidgetHostView
is also a platform specific implementation. The test
for WebContents is using mocked versions.

Anyway, the point was not to test ShowContextMenu
but HandleContextMenu so better to limit the test.

Original description:
To be able to do anything more complicated than block all context
menu handling in HandleContextMenu you need the associated WebContents
object. Current implementation that do something more currently handles
that by either being a WebContentsObserver or keeping the WebContents
object some other way.

After WebContents checks WebContentsDelegate::HandleContextMenu the
next delegate to get a chance is WebContentsViewDelegate::ShowContextMenu
which takes a RenderFrameHost as additional parameter. This is all
you need to get the WebContents object and other related information.

So, to simplify writing WebContentsDelegate:s and override the
context menu handling by actually showing something, include
RenderFrameHost also in the HandleContextMenu call.

I selected RenderFrameHost instead of WebContents that many
other delegate methods use because it matches ShowContextMenu
signature and there are already other delegate methods that
also uses RenderFrameHost instead.

WebContentsDelegate is a very popular interface, so this
modifies a lot of files in different components but the
changes are mechanical.

Bug: 932520
Change-Id: I91ab29e5bbf20ca3743a9b1db7b2c391a573605d
Reviewed-by: Jochen Eisinger <>
Commit-Queue: Joel Klinghed <>
Cr-Commit-Position: refs/heads/master@{#633900}
41 files changed