We don't freeze tabs if WebContents::GetVisibility() == Visibility::VISIBLE, but this is not necessarily in sync with page visibility in Blink.

Problem:
In the renderer process, there are 2 IPC messages corresponding to RenderWidgetHostImpl::Was[Shown|Hidden] and WebContents::Was[Shown|Hidden] that set the page visibility. If RenderWidgetHostImpl::Was[Shown|Hidden] is called without the WebContents updating its visibility state, then the visibility states of WebContents and page scheduler will be out-of-sync. Freezing a tab in this state will result in an attempt to freeze a visible page, which is not allowed.

Example:
This can happen during WebContents capture. In WebContentsImpl::IncrementCapturerCount(), RenderWidgetHostView::WasUnOccluded() gets called, which changes the page to visible on the Blink side. However, WebContents::GetVisibility() does not return Visibility::VISIBLE and the page is still eligible for freezing. See https://bugs.chromium.org/p/chromium/issues/detail?id=873214#c4 for repro steps.

Possible solution:
Change WebContents::GetVisibility() so it returns VISIBLE if !GetMainFrame()->GetRenderWidgetHost()->is_hidden(). This is in sync with RenderWidgetHostImpl::Was[Shown|Hidden] and handles the example above, as well as other cases where the render widget host show/hide methods are called without updating WebContents visibility.

Other solutions (capture case only):
  1. Change WebContents::GetVisibility() so it returns VISIBLE for a captured WebContents
  2. Check if the WebContents is being captured in TabManager and not freeze it.

It is not clear if there are cases where this happens besides the capture case above, but it is possible and there could be cases in the future.