Make Page Visibility API work when the browser window is visible or not

content/browser/renderer_host/render_widget_host_view_aura.cc

Index: content/browser/renderer_host/render_widget_host_view_aura.cc
diff --git a/content/browser/renderer_host/render_widget_host_view_aura.cc b/content/browser/renderer_host/render_widget_host_view_aura.cc
index 63c1609fa100e62bb3bdcdbd4d8c79807e5283ec..1e5acc19ac0eaeda043404fc45da2967108d8f0c 100644
--- a/content/browser/renderer_host/render_widget_host_view_aura.cc
+++ b/content/browser/renderer_host/render_widget_host_view_aura.cc
@@ -608,7 +608,13 @@ void RenderWidgetHostViewAura::Show() {
 }
 
 void RenderWidgetHostViewAura::Hide() {
-  window_->Hide();
+  Hide(false);
+}
+
+void RenderWidgetHostViewAura::Hide(bool content_visible) {
+  // We need to show content in a workspace view like Mac OSX Expose.
+  if (!content_visible)

[no sievers, 2015/03/03 21:12:53]

Can you explain why it makes sense to have |window_| visible while hiding the
contents of the tab (i.e. potentially freeing the delegated layer below, since
we are calling delegated_frame_host_->WasHidden() below)? How does that
guarantee that it renders a valid layer?

Can you also update the comment in what the problem is specifically, and how
this patch fixes it?

We are having a similar problem on Android where there are cases that are
similar to the one described in the bug here, and we'd like the renderer to be
hidden while the view itself might not necessarily be hidden (or at least it's
still the foreground view in the browser, and it will be the first to show once
the app is restored). It's sort of a visible-but-frozen-state maybe, not sure.
Either way, it would be nice if we can potentially align the semantics a bit so
that we don't have to add multiple and confusing APIs and states.

[joone, 2015/03/04 05:22:45]

I tried to call the Hide method when the browser window is out of view by
switching to another workspace, which allows to trigger visibilityChange events.
The problem is that content was not shown in the workspace view, so the
content_visible parameter was added not to call host_->wasHidden() in
RenderWidgetHostViewAura::Hide().

If this does not make sense, we could make a new path to deliver
visibilityChange events or out-of-view state to a render process.
Yes, sure.

[no sievers, 2015/03/04 19:21:25]

This is the code right here. You mean the 'content_visible parameter was added
not to call *window->Hide()* ...' correct?

I think you didn't answer my question though.
I'm wondering how it's guaranteed that the following state is valid and can
render contents (and what contents if the delegated frame host drops the layer):

window is visible && RenderView is hidden
I think it might make sense to have this state where we sort of pause a view.

[joone, 2015/03/04 22:05:04]

Yes, because if we calll window->Hide(), we only see the browser window without
content.
You need to take a look at Window::SetPageVisibility() method I added and how it
differs from Window::SetVisible. Window::SetPageVisibility() method finally
calls  RenderWidgetHostViewAura::Hide(), which doesn't set any visibility to the
compositor and layer and just set the page visibility state(visibiltyState
evens) to a render process. The only problem is that the browser window didn't
show content so I added the content_visible parameter in order to show content.
Ok, I will try to add out-of-view state message between the browser process and
render process.

+    window_->Hide();
 
   if (host_ && !host_->is_hidden()) {
     host_->WasHidden();