Enabling page visibility api in the chrome browser.

content/browser/tab_contents/tab_contents_delegate.h

 // Copyright (c) 2011 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef CONTENT_BROWSER_TAB_CONTENTS_TAB_CONTENTS_DELEGATE_H_
 #define CONTENT_BROWSER_TAB_CONTENTS_TAB_CONTENTS_DELEGATE_H_
 #pragma once
 
 #include <string>
 
@@ skipping 270 matching lines @@
   // Notifies the delegate that the content restrictions for this tab has
   // changed.
   virtual void ContentRestrictionsChanged(TabContents* source);
 
   // Returns true if the hung renderer dialog should be shown. Default is true.
   virtual bool ShouldShowHungRendererDialog();
 
   // Notification that a worker associated with this tab has crashed.
   virtual void WorkerCrashed();
 
+  // Returns true iff the tab contents is not showing.

[brettw, 2011/05/18 22:11:38]

iff -> if

+  virtual bool IsHidden(const TabContents* source) const;

[brettw, 2011/05/18 22:11:38]

Sorry if I led you astray earlier, but it looks like it will be cleaner to ask
the view for its visibility rather than the browser. This will also allow the
delegate to be implemented more cleanly in more places (it should come for free
for things like HTML dialogs that would otherwise need to implement this).

In this case, you can add it to TabContentDelegate::View and even skip the
entire TabContents layer.

I'd probably call the function IsVisible which is a little bit more natural than
"is hidden."

[Shishir, 2011/05/19 02:51:25]

By TabContentDelegate::View, do you mean RenderWidgetHostDelegate::View? I tried
doing it using the RenderWidgetHostDelegate::View, but it suffers from the
problem that when a tab is created hidden (say using a middle click) the
WasHidden() call from the browser::Navigate() to the the TabContents happens
when the view has not yet been created and so the initial value of the
visibility is incorrect.

[brettw, 2011/05/19 04:45:09]

Is there the opposite problem? i.e. what if we say when there's no view it's
invisible? This is certainly the behavior I'd expect if there was no view. Are
there problems creating a foreground tab in this case?

[Shishir, 2011/05/19 18:46:23]

The forground tab likely  works because we always start off with the is_hidden_
value set to false in all the RenderViewHostDelegate::View implementations, so
the default value works out.

Even for a hidden tab, the view does get created before the Navigate call to the
renderer but its gets created late enough that it does not trap the WasHidden
call from the browser::Navigate().

On 2011/05/19 04:45:09, brettw wrote:

+
  protected:
   virtual ~TabContentsDelegate();
 };
 
 #endif  // CONTENT_BROWSER_TAB_CONTENTS_TAB_CONTENTS_DELEGATE_H_