As someone who's not really familiar with both, would it make sense to use CompositorViewHolder everywhere and retire ContentViewRenderView?

For using CompositorViewHolder, we need Chrome to be part of the build. But as a replica of ContentShell, content module alone can be used for rendering the content, without using Chrome features. So in that case CVRV is the reference for end developers.

@Yaron - Could you please share your opinion on #3 ?

So this is because the embedder needs some knowledge of where/how to merge the content provided by the renderer with its own UI? Given  the nature of the fix you're describing though, there may be possible for greater re-use - that's all I'm saying.

I'm really not familiar with the specifics of this so can't comment furter

So this is because the embedder needs some knowledge of where/how to merge the content provided by the renderer with its own UI ? -> Yes. For a customized user experience than rich UX of Chrome.

I also understands your valuable suggestion of coupling CompositorViewHolder, with defined embedder instead of CVRV.

If we apply those patches to CVRV, then those issues related to SurfaceView will gets resolved in ContentShell as well. That's the only benefit we are going to get finally. If that is not so important, we can stop applying those patches to CVRV. What do you suggest ?

There is little value in making ContentShell perfect from an end user's POV. It is meant as a reference example and for developers to work with. If these don't impede developers then I don't think it's worth fixing

Ok I agree with you. We shall close this issue, without applying those patches. Thank you.