Support Audio for Desktop Capture

components/content_settings/core/browser/content_settings_registry.cc

 // Copyright 2015 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.
 
 #include "components/content_settings/core/browser/content_settings_registry.h"
 
 #include <utility>
 
 #include "base/macros.h"
 #include "base/memory/scoped_ptr.h"
@@ skipping 244 matching lines @@
            WebsiteSettingsInfo::REQUESTING_ORIGIN_ONLY_SCOPE,
            ContentSettingsInfo::INHERIT_IN_INCOGNITO);
 
   Register(CONTENT_SETTINGS_TYPE_KEYGEN, "keygen",
            CONTENT_SETTING_BLOCK, WebsiteSettingsInfo::SYNCABLE,
            WhitelistedSchemes(),
            ValidSettings(CONTENT_SETTING_ALLOW, CONTENT_SETTING_BLOCK),
            WebsiteSettingsInfo::REQUESTING_ORIGIN_ONLY_SCOPE,
            ContentSettingsInfo::INHERIT_IN_INCOGNITO);
 
+  Register(CONTENT_SETTINGS_TYPE_DESKTOP_AUDIO_SHARE, "desktop-audio-share",

[raymes, 2016/01/17 23:27:34]

Could you please explain why the content setting is needed? Will there be UI
around this? 

[qiangchen, 2016/01/19 17:33:22]

Sure. We are going to attach the audio stream when doing desktop share. Namely,
attach the system audio when doing screen share, and in the future attach the
tab audio when doing tab share. We also notice that sharing audio may not be
noticeable by the end user. Due to privacy issue, we decide to ask user
permission if the website wants to share audio when doing desktop share. I just
think the permission is similar to the permission for microphone access, and
thus add a CONTENT_SETTING_TYPE. 

There is a UI about this. Currently, I add a checkbox on Desktop Share Window
Picker say "Allow audio sharing". Using permission bubble can be an alternative
way to do so, but there is some UI difficulty: when sharing a tab, we will
activate the target tab to be shared, but the permission bubble is associated
with the original tab  that initiates the sharing. Or we may come up with other
ideas on how to ask for user permission. Anyway, the UI is not the point of this
CL. According to the project plan, we will have separate CLs focusing on the UI
design. This CL is mainly doing the backend support for audio sharing with
desktop share.

[msramek, 2016/01/19 18:02:20]

Drive by! Disclaimer: I'm not generally opposed to adding this setting, just
playing Devil's advocate.

Content settings like microphone are "sticky permissions" that generally express
my trust to a website. For example, I absolutely don't want any website to
listen to my microphone, except Hangouts, because I use that one often. So I'll
create a mic content setting exception for Hangouts.

"Share sound when screen sharing" sounds like something I would want to decide
on a per-session basis rather than per-website. Especially if you go with the
checkbox on the picker, content setting wouldn't be needed, right?

If it's not a website-related setting that is exposed through the
chrome://settings/content UI nor as an administration policy, it might not be a
good fit for content setting.

If this is going to be a user- (not just administrator-) settable content
setting that will not be exposed in chrome://settings/content UI, I think it's
going to be the very first case. Content settings are a form of history, so if
there is no UI entrypoint to inspect which URLs are recorded and delete them,
please make sure to clear the setting when the user deletes their history.

[qiangchen, 2016/01/20 18:00:18]

Thanks for your comment. Several options in my mind:
1. Use checkbox on picker window VS Use permission bubble.
    Personally, I think permission bubble is more consistent with
    camera/mircophone access request. But one issue is for standalone
    extensions, the main UI is not a web page, and thus no place to 
    show permission bubble. (Maybe this is not the big issue, 
    because the main use of desktop share is still within a webpage)

2. Memorize user's selection VS Ask for permission every time.
    Personally, I think memorizing user selection will have better 
    experience. Then the technical question is whether it is 
    appropriate to use content settings. And as you mentioned, I will
    need to add a section in chrome://settings/content for the user
    to manage the white list. Asking every time is relative easier
    to implement, but may annoy the user to do the selection on the
    same website every time.

WDYT? Or do you have an idea where can I store the user selection, if content
setting is inappropriate place? I think I'll pend this CL and throw out a design
doc to listen to more voices.

+           CONTENT_SETTING_BLOCK, WebsiteSettingsInfo::SYNCABLE,
+           WhitelistedSchemes(),
+           ValidSettings(CONTENT_SETTING_ALLOW, CONTENT_SETTING_BLOCK),
+           WebsiteSettingsInfo::REQUESTING_ORIGIN_ONLY_SCOPE,
+           ContentSettingsInfo::INHERIT_IN_INCOGNITO);
+
   // Content settings that aren't used to store any data. TODO(raymes): use a
   // different mechanism rather than content settings to represent these.
   // Since nothing is stored in them, there is no real point in them being a
   // content setting.
   Register(CONTENT_SETTINGS_TYPE_PROTOCOL_HANDLERS, "protocol-handler",
            CONTENT_SETTING_DEFAULT, WebsiteSettingsInfo::UNSYNCABLE,
            WhitelistedSchemes(), ValidSettings(),
            WebsiteSettingsInfo::TOP_LEVEL_DOMAIN_ONLY_SCOPE,
            ContentSettingsInfo::INHERIT_IN_INCOGNITO);
 
@@ skipping 26 matching lines @@
       website_settings_registry_->Register(
           type, name, std::move(default_value), sync_status,
           WebsiteSettingsInfo::NOT_LOSSY, scoping_type);
   DCHECK(!ContainsKey(content_settings_info_, type));
   content_settings_info_[type] = make_scoped_ptr(
       new ContentSettingsInfo(website_settings_info, whitelisted_schemes,
                               valid_settings, incognito_behavior));
 }
 
 }  // namespace content_settings