Add PermissionPromptAndroid skeleton

chrome/browser/permissions/permission_prompt_android.h

+// 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.
+
+#ifndef CHROME_BROWSER_PERMISSIONS_PERMISSION_PROMPT_ANDROID_H_
+#define CHROME_BROWSER_PERMISSIONS_PERMISSION_PROMPT_ANDROID_H_
+
+#include "chrome/browser/ui/website_settings/permission_prompt.h"
+
+class GroupedPermissionInfoBarDelegate;
+class InfoBarService;
+
+namespace content {
+class WebContents;
+}
+
+namespace infobars {
+class InfoBar;
+}
+
+class PermissionPromptAndroid : public PermissionPrompt {
+ public:
+  explicit PermissionPromptAndroid(content::WebContents* web_contents);
+  ~PermissionPromptAndroid() override;
+
+  // PermissionPrompt:
+  void SetDelegate(Delegate* delegate) override;
+  void Show(const std::vector<PermissionRequest*>& requests,
+            const std::vector<bool>& accept_state) override;
+  bool CanAcceptRequestUpdate() override;
+  void Hide() override;
+  bool IsVisible() override;
+  void UpdateAnchorPosition() override;
+  gfx::NativeWindow GetNativeWindow() override;
+
+  void Closing();
+
+ private:
+  content::WebContents* web_contents_;

[dominickn, 2016/10/24 23:22:38]

Holding a bare WebContents is dangerous, since you can get into lifetime
problems (I've fixed two use-after-frees due to bare WebContents pointers as
members in the last couple of months). If this really needs to have a
WebContents, it should be a WebContentsObserver so it can properly know when the
contents is destroyed.

That being said, I wonder whether it's possible to have some other class handle
the actual showing/hiding. PermissionRequestManager is already a
WebContentsUserData, so it always has a WebContents around. Could we define a
PermissionPromptAndroid::InfoBarManager classes, which PermissionRequestManager
implements? And then PermissionPromptAndroid just defers all of the infobar
related calls back up?

Thoughts? Happy to discuss this more.

[lshang, 2016/10/25 03:33:14]

PermissionRequestManager is a WebContentsObserver, so if WebContents gets
destroyed, it would not be able to call PermissionPrompt::Show()/Hide().

But I definitely agree with you that we shouldn't hold a bare WebContents here.
As I said, it's only used to get the InfoBarService, so what if we dynamically
get current WebContents from PermissionRequestID (like in
PermissionQueueController:
https://cs.chromium.org/chromium/src/chrome/browser/permissions/permission_qu...
That needs plumbing through PermissionRequestID in PermissionRequestManager and
PermissionPrompt.

Another approach is to pass through WebContents* in
PermissionPrompt::Show()/Hide(), cause we could get web_contents() in
PermissionRequestManager. This seems simpler.

Are you OK with any of these approaches?
I'm not sure if I get you, what will the PermissionPromptAndroid::InfoBarManager
used for?

Currently for PermissionPromptImpl, it has a
PermissionsBubbleDialogDelegateView* bubble_delegate_, which sounds like a
delegate but acturally is the view implementation of permission bubble. When
need to show/hide bubbles in PermissionRequestManager, it calls into
PermissionPromptImpl and create/close the UI. When buttons on the UI gets
clicked, it calls into PermissionPromptImpl first and PermissionPromptAndroid
defers it to PermissionRequestManager(PermissionRequestManager is already a
subclass of PermissionPrompt::Delegate).

Similar to that, we have the GroupedPermissionInfobar as Android permission
bubble UI, and add/remove infobars in PermissionPromptAndroid. I also have a
subsequent CL which makes ProcessButton() on GroupedPermissionInfoBar to go
through PermissionPromptAndroid, and then defer to PermissionRequestManager,
which is the same as on desktop.

+  Delegate* delegate_;
+  GroupedPermissionInfoBarDelegate* infobar_delegate_;
+  infobars::InfoBar* infobar_;
+
+  DISALLOW_COPY_AND_ASSIGN(PermissionPromptAndroid);
+};
+
+#endif  // CHROME_BROWSER_PERMISSIONS_PERMISSION_PROMPT_ANDROID_H_