Blocking this on 622847 for forwarding interesting stuff from the container view in a shared codepath.

Some thoughts:

There are also gesture event ACKs coming back. Looking at what this is currently used for, it's possible that Blimp does either not care about these, or could leave this as an implementation detail in its own layer.

There is also  crbug.com/617750  which eventually will be the interface to delegate back to the embedding View, such as adding popups. Maybe this should be an implementation detail in the blimp layer (and between its own container view) and how it wants to do its custom UI.

Blocking on 620172: I think eliminating ContentViewClient and moving functionality elsewhere as proposed over there moves things out of your way a bit more, since most of this doesn't apply to Blimp (but is implemented for the content layer). 

Thanks Daniel!  This sounds good.  We can have the Tab depend on classes that are shared (like ViewAndroid or another delegate/generic ui/ class), but not on ContentViewCore directly.

Blocking on 626764, which is about removing content_view_core.h *public* interface.
Because as long as it's there then the application can/will have native dependencies on CVC (like in tab_android.cc), which Blimp doesn't have.

Obsolete, WontFix.