Java class ContentView is instantiated per WebContent, and is used by Content shell and Chrome for following purposes:
1) receives view-related events from Android framework through its parent, and forwards it to content (or ui/ i.e. EventForwarder) layer
2) acts as an Android View which various popup views anchor themselves on (a.k.a 'container view')
3) handles |onScrollChanged| from content layer, in response to |scrollBy| or |scrollTo| given before. Similar processing for a few other events by implementing interface |InternalAccessDelegate|
4) implements interface |SmartClipProvider|
5) Manages its own size info in case it's different from that of the parent view.
What content layer cares about is what it receives at ContentViewCore/EventForwarder. That makes ContentView arguably an embedder-specific implementation for handling all the actions above (note that WebView doesn't use it). This bug is to discuss how to replace what it has been doing in alternative approaches, and eventually delete the class (or move it out of content/). My initial thought for each use case is:
1) ContentView's parent (CompositorViewHolder) in Chrome should be able to choose the right CVC/EventForwarder from |WebContents| object, call their methods directly.
2) Ditto. Popups for a certain content set CompositorViewHolder for their container view. A caveat then is whenever active content changes, the popups for the old contents should be detached (not just hidden) from the parent view since the parent will be shared by all the contents - not clear if this is already handled.
3) From content layer's pov, it can still interact with whatever is passed to it as InternalAccessDelegate. Maybe CompositorViewHolder here again?
4) SmartClipProvider, from the comment ("Please make sure implementation of them is somewhere in the view hierarchy."), can be anywhere in the view hierarchy for the active content. The implementation may not be shared among multiple contents, so this rules out |CompositorViewHolder|. It may call for another view between content and embedder..?
5) Only required for contextual search. CompositorViewHolder is adjusting the physical backing size with the size info for contextual search (overlay panel). https://bugs.chromium.org/p/chromium/issues/detail?id=609332#c7 hints that the size difference (narrow width overlay panel) may be gone. Needs to keep track of the discussion. If it stays, the entire logic should be able to move to Chrome.
Comment 1 by boliu@chromium.org
, Jan 30 2018