Understanding RenderWidgetHostView showing and hiding

[Michael Thiessen]

(x-post from #halp)

Hi all,

I'm trying to simplify RenderWidgetHostView visibility if possible - right now we control it largely through the WebContents (this is how the RWHV gets hidden when tabs get hidden, etc.), but also through RenderFrameHostManager which hides the view when a navigation starts and shows it when it commits. I would love to get to a place where we have one source of truth for whether the RWHV would like to be visible (the RWHV still may not actually be visible for platform-specific reasons), as Hide/Show calls are supposed to be symmetric (they are not today).

My main motivation here is that we now have kHiddenButPainting, which when set causes the RWHV to report that it's visible (when it isn't) and some security checks to ensure that the RenderFrameHost is actually visible break when we have a hidden capturer on the WebContents (eg. screenshotting for the tab switcher). I'd like to separate out the notions of visible and painting, but first I need to get a handle on visibility.

Specific questions:
Is this a dumb idea? Should we not rely on RWHV visibility to reflect actual visibility? Should we just do something like rename RenderFrameHost::GetVisibilityState to RenderFrameHost::IsRendering?
Why does the WebContents not always control the visibility (at least for non-guest RWHVs)? Is there a good reason for the WebContents to believe it's visible but the RWHV is hidden (could the WebContents itself not ensure consistency, rather than the RenderFrameHostManager?)?

Thanks for the help,
Michael

[Charlie Reis]

Dave, do you know about RenderWidgetHostView or who might be able to help at this point?  I'm not sure navigation-dev@ is the right list for it since it's less about navigation than input and compositing, although there's a bit of overlap in RFHM.  I wouldn't be able to help with the various ways that hidden/shown state is tracked, though.

Charlie

--
You received this message because you are subscribed to the Google Groups "navigation-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to navigation-de...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/navigation-dev/d017f263-6fd7-4dce-b5cb-2a0373a2ba15n%40chromium.org.

[Dave Tapuska]

My understanding is that:

RenderFrameHost::GetVisibilityState will report what is available to the WebAPI. From an API point of view the name make sense.

Before a document is committed, it will not be visible. The WebContents will have multiple RenderWidgetHostView associated with it (the ones in the BFCache, pending commit ones, etc, that aren't visible, yet the WebContents is visible).

This is different than the View is actually presented to the user (which is the state of the RenderWidgetHostView).

Again, this is a complicated system and many people have worked on it so I just look at the code and try to reason about it.

dave.

[Michael Thiessen]

Thanks Dave, I think I'll continue on my quest, and possibly rename RenderFrameHost::GetVisibilityState to RenderFrameHost::GetWebVisibilityState and introduce IsUserVisible or something.