Implement a modal permission dialog on Android gated by a feature.

chrome/browser/permissions/permission_dialog_delegate.cc

+// Copyright 2016 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 "chrome/browser/permissions/permission_dialog_delegate.h"
+
+#include <utility>
+
+#include "base/android/jni_android.h"
+#include "base/android/jni_string.h"
+#include "base/feature_list.h"
+#include "build/build_config.h"
+#include "chrome/browser/android/resource_mapper.h"
+#include "chrome/browser/geolocation/geolocation_infobar_delegate_android.h"
+#include "chrome/browser/media/midi_permission_infobar_delegate_android.h"
+#include "chrome/browser/media/protected_media_identifier_infobar_delegate_android.h"
+#include "chrome/browser/notifications/notification_permission_infobar_delegate.h"
+#include "chrome/common/chrome_features.h"
+#include "components/variations/variations_associated_data.h"
+#include "content/public/browser/android/content_view_core.h"
+#include "content/public/browser/web_contents.h"
+#include "jni/PermissionDialogController_jni.h"
+#include "jni/PermissionDialogDelegate_jni.h"
+#include "ui/android/window_android.h"
+#include "ui/base/window_open_disposition.h"
+
+using base::android::ConvertUTF16ToJavaString;
+
+namespace {
+
+// Key for querying variations for whether a modal should require a gesture.
+const char kModalParamsUserGestureKey[] = "require_gesture";
+
+}
+
+// static
+void PermissionDialogDelegate::Create(
+    content::PermissionType type,
+    content::WebContents* web_contents,
+    const GURL& requesting_frame,
+    bool user_gesture,
+    Profile* profile,
+    const PermissionSetCallback& callback) {
+  DCHECK(web_contents);
+
+  std::unique_ptr<PermissionInfoBarDelegate> infobar_delegate = nullptr;
+  switch (type) {
+    case content::PermissionType::GEOLOCATION:
+      infobar_delegate.reset(new GeolocationInfoBarDelegateAndroid(
+          requesting_frame, user_gesture, profile, callback));
+      break;
+#if defined(ENABLE_NOTIFICATIONS)
+    case content::PermissionType::NOTIFICATIONS:
+    case content::PermissionType::PUSH_MESSAGING:
+      infobar_delegate.reset(new NotificationPermissionInfoBarDelegate(
+          requesting_frame, user_gesture, profile, callback));
+      break;
+#endif  // ENABLE_NOTIFICATIONS
+    case content::PermissionType::MIDI_SYSEX:
+      infobar_delegate.reset(new MidiPermissionInfoBarDelegateAndroid(
+          requesting_frame, user_gesture, profile, callback));
+      break;
+    case content::PermissionType::PROTECTED_MEDIA_IDENTIFIER:
+      infobar_delegate.reset(new ProtectedMediaIdentifierInfoBarDelegateAndroid(
+          requesting_frame, user_gesture, profile, callback));
+      break;

[raymes, 2016/11/01 02:56:46]

Could we factor this switch statement out as out as common code with
PermissionInfoBarDelegate::Create ?

[dominickn, 2016/11/01 03:30:58]

I thought about it when I was implementing it, and it wasn't pretty.
PermissionInfoBarDelegate::Create returns an infobar pointer, which we don't
want to do here (the InfoBarService may return a nullptr, so that's a signal
that something went wrong in the infobar case).

Another option is to someone combine the two Create methods into one, e.g.
moving PermissionInfoBarDelegate's construction inside
PermissionDialogDelegate::Create. That seems premature at this stage - it may be
something we do in the future when we have a definitive decision on whether or
not we keep the modals.

For now, I kept it separate because it felt safer to keep the two prompt types
as separate as possible for now. When we figure out what we go with, that seems
like a safer time to determine what we should do. WDYT?

[raymes, 2016/11/01 03:50:46]

Could we just have this switch statement as the common code? What I mean is
adding a 
std::unique_ptr<PermissionInfoBarDelegate>
PermissionInfoBarDelegate::CreateDelegate(...) which is called from here and
inside PermissionInfoBarDelegate::Create ?

[dominickn, 2016/11/01 04:44:00]

Ah, I see. That makes sense, thanks!

+    default:
+      NOTREACHED();
+  }
+
+  PermissionDialogDelegate* dialog_delegate =
+      new PermissionDialogDelegate(web_contents, std::move(infobar_delegate));
+
+  // Create the dialog delegate's Java counterpart, which manages its lifetime.
+  JNIEnv* env = base::android::AttachCurrentThread();
+  base::android::ScopedJavaLocalRef<jobject> j_delegate =
+      dialog_delegate->CreateJavaDelegate(env);
+
+  // Send the Java delegate to the Java PermissionDialogController for display.
+  // The controller takes over lifetime management; when the Java delegate is no
+  // longer needed it will in turn free the native delegate.
+  Java_PermissionDialogController_createDialog(env, j_delegate.obj());
+}
+
+// static
+bool PermissionDialogDelegate::PromptUser(bool has_user_gesture) {

[raymes, 2016/11/01 02:56:46]

As discussed, this might be better as ShouldUseModalDialog (or something like
that) so it's clear it returns a bool.

[dominickn, 2016/11/01 03:30:58]

Done.

+  if (!base::FeatureList::IsEnabled(features::kModalPermissionPrompts))
+    return false;
+
+  // Enforce a user gesture requirement by default. Only relax this if

[raymes, 2016/11/01 02:56:46]

"Enforce a user gesture requirement by default" is a little confusing. Perhaps
something like
"Only use modals when the prompt is triggered by a user gesture, unless the
kModalParamsUserGestureKey param is set to "false" ?

[dominickn, 2016/11/01 04:44:00]

Done.

+  // variations has a require_gesture key, and that key is one of 0 or false.
+  std::string require_gesture = variations::GetVariationParamValueByFeature(
+      features::kModalPermissionPrompts, kModalParamsUserGestureKey);
+  if (require_gesture == "0" || require_gesture == "false")

[raymes, 2016/11/01 02:56:46]

How come "0" and "false" are both special? Could we just test for one of those?

[dominickn, 2016/11/01 03:30:58]

Done.

+    return true;
+  return has_user_gesture;

[raymes, 2016/11/01 02:56:46]

Hmm, this means that you could get an infobar or a modal prompt at the same
time. That seems quite weird and like we would probably never ship that? What's
the danger in always having modals?

[dominickn, 2016/11/01 03:30:58]

The UI team actually told us that the original intention for permission prompts
on Android was to use a modal for "good" prompts (i.e. with user gesture) and an
infobar for "bad" prompts. The latter was implemented, but the former never was.
This is implemented to match that original spec, with the Finch control to let
us roll out the universal version.

The danger of always having modals is onload prompts - your page fires a
permission request and the first thing you see is a modal when you load it. That
would be pretty annoying.

[raymes, 2016/11/01 03:50:46]

I see - that still doesn't seem like a great experience to me, but that can be
discussed more later :)

+}
+
+// static
+bool PermissionDialogDelegate::RegisterPermissionDialogDelegate(JNIEnv* env) {
+  return RegisterNativesImpl(env);
+}
+
+ScopedJavaLocalRef<jobject> PermissionDialogDelegate::CreateJavaDelegate(
+    JNIEnv* env) {
+  content::ContentViewCore* cvc =
+      content::ContentViewCore::FromWebContents(web_contents());
+  DCHECK(cvc);
+
+  return Java_PermissionDialogDelegate_create(
+      env, reinterpret_cast<uintptr_t>(this),
+      cvc->GetWindowAndroid()->GetJavaObject(),
+      ResourceMapper::MapFromChromiumId(infobar_delegate_->GetIconId()),
+      ConvertUTF16ToJavaString(env, infobar_delegate_->GetMessageText()),
+      ConvertUTF16ToJavaString(env, infobar_delegate_->GetLinkText()),
+      ConvertUTF16ToJavaString(env, infobar_delegate_->GetButtonLabel(
+                                        PermissionInfoBarDelegate::BUTTON_OK)),
+      ConvertUTF16ToJavaString(env,
+                               infobar_delegate_->GetButtonLabel(
+                                   PermissionInfoBarDelegate::BUTTON_CANCEL)),
+      infobar_delegate_->ShouldShowPersistenceToggle());
+}
+
+void PermissionDialogDelegate::Accept(JNIEnv* env,
+                                      const JavaParamRef<jobject>& obj,
+                                      jboolean persist) {
+  if (infobar_delegate_->ShouldShowPersistenceToggle())
+    infobar_delegate_->set_persist(persist);
+  infobar_delegate_->Accept();
+}
+
+void PermissionDialogDelegate::Cancel(JNIEnv* env,
+                                      const JavaParamRef<jobject>& obj,
+                                      jboolean persist) {
+  if (infobar_delegate_->ShouldShowPersistenceToggle())
+    infobar_delegate_->set_persist(persist);
+  infobar_delegate_->Cancel();
+}
+
+void PermissionDialogDelegate::Dismissed(JNIEnv* env,
+                                         const JavaParamRef<jobject>& obj) {
+  infobar_delegate_->InfoBarDismissed();
+}
+
+void PermissionDialogDelegate::LinkClicked(JNIEnv* env,
+                                           const JavaParamRef<jobject>& obj) {
+  // Don't call delegate_->LinkClicked() because that relies on having an
+  // InfoBarService as an owner() to open the link. That will fail since the
+  // wrapped delegate has no owner (it hasn't been added as an infobar).
+  if (web_contents()) {
+    web_contents()->OpenURL(content::OpenURLParams(
+        infobar_delegate_->GetLinkURL(), content::Referrer(),
+        WindowOpenDisposition::NEW_FOREGROUND_TAB, ui::PAGE_TRANSITION_LINK,
+        false));
+  }
+}
+
+void PermissionDialogDelegate::Destroy(JNIEnv* env,
+                                       const JavaParamRef<jobject>& obj) {
+  delete this;
+}
+
+PermissionDialogDelegate::PermissionDialogDelegate(
+    content::WebContents* web_contents,
+    std::unique_ptr<PermissionInfoBarDelegate> infobar_delegate)
+    : content::WebContentsObserver(web_contents),
+      infobar_delegate_(std::move(infobar_delegate)) {
+  DCHECK(infobar_delegate_);
+}
+
+PermissionDialogDelegate::~PermissionDialogDelegate() {}