Make tab audible and muted states and cause available for an extension API

chrome/browser/ui/cocoa/tabs/tab_strip_controller.mm

Index: chrome/browser/ui/cocoa/tabs/tab_strip_controller.mm
diff --git a/chrome/browser/ui/cocoa/tabs/tab_strip_controller.mm b/chrome/browser/ui/cocoa/tabs/tab_strip_controller.mm
index 1489c29da0204d1d1cd24454bbda8adeff1d555e..8e8395aeccb27913a7ea0237531694a3f2a3fafd 100644
--- a/chrome/browser/ui/cocoa/tabs/tab_strip_controller.mm
+++ b/chrome/browser/ui/cocoa/tabs/tab_strip_controller.mm
@@ -831,7 +831,7 @@ NSImage* Overlay(NSImage* ground, NSImage* overlay, CGFloat alpha) {
   if (!tabStripModel_->ContainsIndex(index))
     return;
   WebContents* contents = tabStripModel_->GetWebContentsAt(index);
-  chrome::SetTabAudioMuted(contents, !chrome::IsTabAudioMuted(contents));
+  chrome::SetTabAudioMuted(contents, !chrome::IsTabAudioMuted(contents), "user");

[miu, 2014/12/05 23:46:48]

Instead of passing "user" as a cause, it's best to have this string constant
declared/defined in one place and then used by all the call points.

Suggestion: Add a static constant to tab_utils.cc:

  const char kUserMuteToggleCause[] = "user";

[Jared Sohn, 2014/12/07 22:39:45]

I also need access to this constant from
chrome/browser/ui/views/tabs/browser_tab_strip_controller.cc.  

Would it be better to redundantly declare the same constant in that file or
define it once in a shared header file?  Since both classes make use of
tab_utils.h, I have considered moving the constant to there (and then placing it
within the chrome namespace since that is what the function that uses it uses.)

Is this okay, or is there a preference for not putting string constants in
header files (perhaps because it will get instantiated by any file that includes
it, even if it doesn't use it?  Although, since it is static it will only get
instantiated once, so its very small negative effect would be allocating space
when modules that don't call the function but use the header file get built.)

[miu, 2014/12/09 01:56:24]

The way you did it is the preferred way, with one minor thing.  See next comment
for clarification...

 }
 
 // Called when the user closes a tab. Asks the model to close the tab. |sender|