Added flag simplified-fullscreen-ui.

chrome/browser/ui/exclusive_access/fullscreen_controller.cc

Index: chrome/browser/ui/exclusive_access/fullscreen_controller.cc
diff --git a/chrome/browser/ui/exclusive_access/fullscreen_controller.cc b/chrome/browser/ui/exclusive_access/fullscreen_controller.cc
index fd2b2b89822ebb81e355a39e3b171fc429636da7..62df9c1357bca78d18c3ede81a78ab56868c1358 100644
--- a/chrome/browser/ui/exclusive_access/fullscreen_controller.cc
+++ b/chrome/browser/ui/exclusive_access/fullscreen_controller.cc
@@ -509,6 +509,10 @@ void FullscreenController::ExitFullscreenModeInternal() {
 ContentSetting FullscreenController::GetFullscreenSetting() const {
   DCHECK(exclusive_access_tab());
 
+  // If simplified UI is enabled, never ask the user, just auto-allow.

[scheib, 2015/07/30 18:32:27]

I must be rusty on this, but, woah, why doesn't fullscreen have BLOCK permission
in content settings? For now it seems that it doesn't, so this would be OK. But
if Block were possible then this could would need to check first for BLOCK.

So.... I suppose no action to take here unless you also find it unnerving that
content settings doesn't allow this to be blocked, in which case we should bring
it up in design discussion.

[Matt Giuca, 2015/07/31 03:12:50]

Interesting. Well I just filed http://crbug.com/515747 for discussion and
linking.

I think with the current design, we should allow the user to block this. But if
we are going forward to auto-allowing, then we probably don't want to allow
that. Discuss on the bug.

+  if (ExclusiveAccessManager::IsSimplifiedFullscreenUIEnabled())
+    return CONTENT_SETTING_ALLOW;
+
   GURL url = GetRequestingOrigin();
 
   // Always ask on file:// URLs, since we can't meaningfully make the