Remove pointer from PermissionPromptAndroid to InfoBar

Remove pointer from PermissionPromptAndroid to InfoBar

This patch removes the pointer from PermissionPromptAndroid to InfoBar,
as preparation for supporting modal permission dialogs on android via
the PermissionRequestManager.

Currently, the pointer is only used for Hide() and IsVisible(). We can
use the PermissionRequest vector to see if a prompt is being shown, and
the calls to Hide() can no-op as they are already handled by the
InfoBarManager (e.g. page navigation, or after the user resolves the
prompt). If the PermissionServiceImpl receives a mojo connection error,
the PermissionRequestManager just dummies out its callback for active
prompts (on Android) as we return false in CanAcceptRequestUpdate().

We override EqualsDelegate() as the PermissionRequestManager will try to
Show() a queued bubble when it's called back after the user resolves a
prompt, but the callback happens before the active prompt is closed. The
parent's EqualsDelegate() would consider the new delegate the same as
the current one, and so it wouldn't show a new infobar.

This means we no longer have the following cycle of pointers:
  PermissionPromptAndroid ->
  GroupedPermissionInfoBar ->
  GroupedPermissionInfoBarDelegate ->
  PermissionPromptAndroid

When we later add modal permission dialogs, the PermissionPromptAndroid
will just need to check when it creates the actual UI what object to
make, but it won't need extra logic in Hide() or IsVisble().

BUG=606138
Review-Url: https://codereview.chromium.org/2755593002
Cr-Commit-Position: refs/heads/master@{#463551}
Committed: https://chromium.googlesource.com/chromium/src/+/897fa146046239d6384aab548a93045f12bd5711

[Timothy Loh, 2017-03-15 03:28:45]

The CQ bit was checked by timloh@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-15 03:29:20]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Timothy Loh, 2017-03-15 03:34:00]

Description was changed from

==========
Remove pointer from PermissionPromptAndroid to InfoBar

This patch removes the pointer from PermissionPromptAndroid to InfoBar,
as preparation for supporting modal permission dialogs on android via
the PermissionRequestManager.

Currently, the pointer is only used for Hide() and IsVisible(). We can
easily keep track of whether a prompt is shown with a bool. As far as I
can tell, the calls to Hide() can no-op as they are already handled by
the InfoBarManager (e.g. page navigation, or after the user resolves the
prompt). If the PermissionServiceImpl receives a mojo connection error,
the PermissionRequestManager just dummies out its callback for active
prompts (on Android) as we return false in CanAcceptRequestUpdate().

This means we no longer have the following cycle of pointers:
  PermissionPromptAndroid ->
  GroupedPermissionInfoBar ->
  GroupedPermissionInfoBarDelegate ->
  PermissionPromptAndroid

When we later add modal permission dialogs, the PermissionPromptAndroid
will just need to check when it creates the actual UI what object to
make, but it won't need extra logic in Hide() or IsVisble().

BUG=606138
==========

to

==========
Remove pointer from PermissionPromptAndroid to InfoBar

This patch removes the pointer from PermissionPromptAndroid to InfoBar,
as preparation for supporting modal permission dialogs on android via
the PermissionRequestManager.

Currently, the pointer is only used for Hide() and IsVisible(). We can
easily keep track of whether a prompt is shown with a bool. As far as I
can tell, the calls to Hide() can no-op as they are already handled by
the InfoBarManager (e.g. page navigation, or after the user resolves the
prompt). If the PermissionServiceImpl receives a mojo connection error,
the PermissionRequestManager just dummies out its callback for active
prompts (on Android) as we return false in CanAcceptRequestUpdate().

We override EqualsDelegate() as the PermissionRequestManager will try to
Show() a queued bubble when it's called back after the user resolves a
prompt, but the callback happens before the active prompt is closed. The
parent's EqualsDelegate() would consider the new delegate the same as
the current one, and so it wouldn't show a new infobar.

This means we no longer have the following cycle of pointers:
  PermissionPromptAndroid ->
  GroupedPermissionInfoBar ->
  GroupedPermissionInfoBarDelegate ->
  PermissionPromptAndroid

When we later add modal permission dialogs, the PermissionPromptAndroid
will just need to check when it creates the actual UI what object to
make, but it won't need extra logic in Hide() or IsVisble().

BUG=606138
==========

[Timothy Loh, 2017-03-15 03:34:00]

timloh@chromium.org changed reviewers:
+ raymes@chromium.org

[commit-bot: I haz the power, 2017-03-15 04:32:46]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-15 04:32:48]

Dry run: This issue passed the CQ dry run.

[Timothy Loh, 2017-03-16 00:40:02]

The CQ bit was checked by timloh@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-16 00:40:58]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Timothy Loh, 2017-03-16 00:41:01]

Description was changed from

==========
Remove pointer from PermissionPromptAndroid to InfoBar

This patch removes the pointer from PermissionPromptAndroid to InfoBar,
as preparation for supporting modal permission dialogs on android via
the PermissionRequestManager.

Currently, the pointer is only used for Hide() and IsVisible(). We can
easily keep track of whether a prompt is shown with a bool. As far as I
can tell, the calls to Hide() can no-op as they are already handled by
the InfoBarManager (e.g. page navigation, or after the user resolves the
prompt). If the PermissionServiceImpl receives a mojo connection error,
the PermissionRequestManager just dummies out its callback for active
prompts (on Android) as we return false in CanAcceptRequestUpdate().

We override EqualsDelegate() as the PermissionRequestManager will try to
Show() a queued bubble when it's called back after the user resolves a
prompt, but the callback happens before the active prompt is closed. The
parent's EqualsDelegate() would consider the new delegate the same as
the current one, and so it wouldn't show a new infobar.

This means we no longer have the following cycle of pointers:
  PermissionPromptAndroid ->
  GroupedPermissionInfoBar ->
  GroupedPermissionInfoBarDelegate ->
  PermissionPromptAndroid

When we later add modal permission dialogs, the PermissionPromptAndroid
will just need to check when it creates the actual UI what object to
make, but it won't need extra logic in Hide() or IsVisble().

BUG=606138
==========

to

==========
Remove pointer from PermissionPromptAndroid to InfoBar

This patch removes the pointer from PermissionPromptAndroid to InfoBar,
as preparation for supporting modal permission dialogs on android via
the PermissionRequestManager.

Currently, the pointer is only used for Hide() and IsVisible(). We can
use the PermissionRequest vector to see if a prompt is being shown, and
the calls to Hide() can no-op as they are already handled by the
InfoBarManager (e.g. page navigation, or after the user resolves the
prompt). If the PermissionServiceImpl receives a mojo connection error,
the PermissionRequestManager just dummies out its callback for active
prompts (on Android) as we return false in CanAcceptRequestUpdate().

We override EqualsDelegate() as the PermissionRequestManager will try to
Show() a queued bubble when it's called back after the user resolves a
prompt, but the callback happens before the active prompt is closed. The
parent's EqualsDelegate() would consider the new delegate the same as
the current one, and so it wouldn't show a new infobar.

This means we no longer have the following cycle of pointers:
  PermissionPromptAndroid ->
  GroupedPermissionInfoBar ->
  GroupedPermissionInfoBarDelegate ->
  PermissionPromptAndroid

When we later add modal permission dialogs, the PermissionPromptAndroid
will just need to check when it creates the actual UI what object to
make, but it won't need extra logic in Hide() or IsVisble().

BUG=606138
==========

[Timothy Loh, 2017-03-16 00:42:27]

timloh@chromium.org changed reviewers:
+ dominickn@chromium.org

[Timothy Loh, 2017-03-16 00:42:28]

+dominickn

This depends on https://codereview.chromium.org/2757483002/ as otherwise I need
to introduce an extra bool temporarily to check visibility.

[commit-bot: I haz the power, 2017-03-16 01:50:37]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-16 01:50:38]

Dry run: This issue passed the CQ dry run.

[dominickn, 2017-03-16 03:58:23]

Thanks!

https://codereview.chromium.org/2755593002/diff/20001/chrome/browser/permissi...
File chrome/browser/permissions/permission_prompt_android.cc (left):

https://codereview.chromium.org/2755593002/diff/20001/chrome/browser/permissi...
chrome/browser/permissions/permission_prompt_android.cc:26:
infobar_delegate->PermissionPromptDestroyed();
Since this is the only method that calls PermissionPromptDestroyed(), can you
remove that method in GroupedPermissionInfoBar too?

Also can you put the braces on one line. :)

[Timothy Loh, 2017-03-17 00:50:24]

The CQ bit was checked by timloh@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-17 00:51:07]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Timothy Loh, 2017-03-17 00:52:13]

The CQ bit was checked by timloh@chromium.org to run a CQ dry run

[Timothy Loh, 2017-03-17 00:52:47]

https://codereview.chromium.org/2755593002/diff/20001/chrome/browser/permissi...
File chrome/browser/permissions/permission_prompt_android.cc (left):

https://codereview.chromium.org/2755593002/diff/20001/chrome/browser/permissi...
chrome/browser/permissions/permission_prompt_android.cc:26:
infobar_delegate->PermissionPromptDestroyed();
On 2017/03/16 03:58:23, dominickn wrote:
> Since this is the only method that calls PermissionPromptDestroyed(), can you
> remove that method in GroupedPermissionInfoBar too?
> 
> Also can you put the braces on one line. :)

Done.

[commit-bot: I haz the power, 2017-03-17 00:52:51]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[dominickn, 2017-03-17 01:45:26]

lgtm % nits

https://codereview.chromium.org/2755593002/diff/60001/chrome/browser/permissi...
File chrome/browser/permissions/permission_prompt_android.cc (right):

https://codereview.chromium.org/2755593002/diff/60001/chrome/browser/permissi...
chrome/browser/permissions/permission_prompt_android.cc:8: #include
"chrome/browser/infobars/infobar_service.h"
This is now unused.

https://codereview.chromium.org/2755593002/diff/60001/chrome/browser/permissi...
chrome/browser/permissions/permission_prompt_android.cc:9: #include
"chrome/browser/media/webrtc/media_stream_devices_controller.h"
I don't think this header is used?

https://codereview.chromium.org/2755593002/diff/60001/chrome/browser/permissi...
chrome/browser/permissions/permission_prompt_android.cc:13: #include
"components/infobars/core/infobar.h"
Not used?

https://codereview.chromium.org/2755593002/diff/60001/chrome/browser/permissi...
chrome/browser/permissions/permission_prompt_android.cc:14: #include
"content/public/browser/web_contents.h"
We don't actually call any methods on WebContents now so the forward declaration
in the header file is fine. Remove this.

[commit-bot: I haz the power, 2017-03-17 01:58:59]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-17 01:59:00]

Dry run: This issue passed the CQ dry run.

[Timothy Loh, 2017-03-17 02:34:10]

The CQ bit was checked by timloh@chromium.org to run a CQ dry run

[Timothy Loh, 2017-03-17 02:34:21]

https://codereview.chromium.org/2755593002/diff/60001/chrome/browser/permissi...
File chrome/browser/permissions/permission_prompt_android.cc (right):

https://codereview.chromium.org/2755593002/diff/60001/chrome/browser/permissi...
chrome/browser/permissions/permission_prompt_android.cc:8: #include
"chrome/browser/infobars/infobar_service.h"
On 2017/03/17 01:45:25, dominickn wrote:
> This is now unused.

This is used in Show(). Removed the other unused ones.

[commit-bot: I haz the power, 2017-03-17 02:34:41]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Timothy Loh, 2017-03-17 02:49:27]

timloh@chromium.org changed reviewers:
+ benwells@chromium.org
- raymes@chromium.org

[Timothy Loh, 2017-03-17 02:49:28]

benwells@ for OWNERS, thanks!

[commit-bot: I haz the power, 2017-03-17 03:24:50]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-17 03:24:51]

Dry run: This issue passed the CQ dry run.

[benwells, 2017-03-20 03:00:43]

https://codereview.chromium.org/2755593002/diff/80001/chrome/browser/permissi...
File chrome/browser/permissions/permission_prompt_android.cc (right):

https://codereview.chromium.org/2755593002/diff/80001/chrome/browser/permissi...
chrome/browser/permissions/permission_prompt_android.cc:47: // false, it doesn't
call into here and instead dummies out the callbacks.
This feels brittle - e.g. someone might add a new call to Hide and things won't
work.

Can you think of a better solution that doesn't rely on callers of Hide all
being unnecessary for infobars?

[Timothy Loh, 2017-03-20 04:00:41]

https://codereview.chromium.org/2755593002/diff/80001/chrome/browser/permissi...
File chrome/browser/permissions/permission_prompt_android.cc (right):

https://codereview.chromium.org/2755593002/diff/80001/chrome/browser/permissi...
chrome/browser/permissions/permission_prompt_android.cc:47: // false, it doesn't
call into here and instead dummies out the callbacks.
On 2017/03/20 03:00:43, benwells wrote:
> This feels brittle - e.g. someone might add a new call to Hide and things
won't
> work.
>
> Can you think of a better solution that doesn't rely on callers of Hide all
> being unnecessary for infobars?

If we don't remove this pointer, then we'd need to add more logic to correctly
maintain the state of the pointer (of note is we'd need to add an
InfoBarManager::Observer so we can know when it's removed due to navigation).
And we'd probably want to add a flag to Hide() since it's weird for the
PermissionRequestManager to also try and remove infobars when the InfoBarManager
should really be in charge of it.

It seems to me that it's simpler to remove this pointer than to try and make it
actually hide the infobar for future potential usages (YAGNI).

[benwells, 2017-03-20 04:11:59]

On 2017/03/20 04:00:41, Timothy Loh wrote:
>
https://codereview.chromium.org/2755593002/diff/80001/chrome/browser/permissi...
> File chrome/browser/permissions/permission_prompt_android.cc (right):
> 
>
https://codereview.chromium.org/2755593002/diff/80001/chrome/browser/permissi...
> chrome/browser/permissions/permission_prompt_android.cc:47: // false, it
doesn't
> call into here and instead dummies out the callbacks.
> On 2017/03/20 03:00:43, benwells wrote:
> > This feels brittle - e.g. someone might add a new call to Hide and things
> won't
> > work.
> >
> > Can you think of a better solution that doesn't rely on callers of Hide all
> > being unnecessary for infobars?
> 
> If we don't remove this pointer, then we'd need to add more logic to correctly
> maintain the state of the pointer (of note is we'd need to add an
> InfoBarManager::Observer so we can know when it's removed due to navigation).
> And we'd probably want to add a flag to Hide() since it's weird for the
> PermissionRequestManager to also try and remove infobars when the
InfoBarManager
> should really be in charge of it.
> 
> It seems to me that it's simpler to remove this pointer than to try and make
it
> actually hide the infobar for future potential usages (YAGNI).

I'm not suggesting you keep the pointer / make Hide actually work. But there is
a problem here - there is a function called Hide, which does nothing. The
contract of this class is broken.

Off the cuff suggestion:
- Add a function HidesAutomatically. If this is true, calling Hide is not
supported.
- Check that in the three call sites
- Make Hide NOTREACHED on Android.

Or something like that.

[Timothy Loh, 2017-03-20 04:18:02]

On 2017/03/20 04:11:59, benwells wrote:
> I'm not suggesting you keep the pointer / make Hide actually work. But there
is
> a problem here - there is a function called Hide, which does nothing. The
> contract of this class is broken.
> 
> Off the cuff suggestion:
> - Add a function HidesAutomatically. If this is true, calling Hide is not
> supported.
> - Check that in the three call sites
> - Make Hide NOTREACHED on Android.
> 
> Or something like that.

Seems reasonable, will try doing something like that...

[Timothy Loh, 2017-03-28 00:48:35]

Status update:

I noticed that due to https://codereview.chromium.org/2522373002 the permissions
system is still trying to explicitly manage the infobar ui on tab switching. I'm
looking into making things work with that reverted, so that we'd not destroy the
PermissionPromptAndroid on tab switching.

[Timothy Loh, 2017-03-29 03:32:35]

The CQ bit was checked by timloh@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-29 03:33:06]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Timothy Loh, 2017-03-29 03:45:27]

Patchset #6 (id:100001) has been deleted

[commit-bot: I haz the power, 2017-03-29 05:34:29]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-29 05:34:30]

Dry run: Try jobs failed on following builders:
  ios-simulator on master.tryserver.chromium.mac (JOB_TIMED_OUT, build hasn't
started yet, builder probably lacks capacity)

[Timothy Loh, 2017-04-06 04:05:11]

The CQ bit was checked by timloh@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-06 04:05:24]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Timothy Loh, 2017-04-06 04:15:44]

The CQ bit was checked by timloh@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-06 04:15:55]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-06 05:28:32]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-06 05:28:33]

Dry run: This issue passed the CQ dry run.

[Timothy Loh, 2017-04-10 03:58:17]

The CQ bit was checked by timloh@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-10 03:58:31]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Timothy Loh, 2017-04-10 04:23:48]

Added a HidesAutomatically() as suggested, PTAL.

https://codereview.chromium.org/2755593002/diff/180001/chrome/browser/permiss...
File chrome/browser/permissions/permission_prompt_android.cc (right):

https://codereview.chromium.org/2755593002/diff/180001/chrome/browser/permiss...
chrome/browser/permissions/permission_prompt_android.cc:47: //
CanAcceptRequestUpdate() return true.
I'm thinking of changing (in a separate patch of course)
CanAcceptRequestUpdate() and all the parent calls of CancelPermissionRequest(),
etc., into something like onMojoConnectionError(). So then Hide() would only be
called externally in cases guarded by HidesAutomatically().

https://codereview.chromium.org/2755593002/diff/180001/chrome/browser/permiss...
File chrome/browser/permissions/permission_request_manager.cc (left):

https://codereview.chromium.org/2755593002/diff/180001/chrome/browser/permiss...
chrome/browser/permissions/permission_request_manager.cc:235: NOTREACHED();
Not sure if it's nicer to leave this here or change it to check
HidesAutomatically()?

[commit-bot: I haz the power, 2017-04-10 04:37:16]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-10 04:37:17]

Dry run: This issue passed the CQ dry run.

[benwells, 2017-04-10 07:00:58]

lgtm

https://codereview.chromium.org/2755593002/diff/180001/chrome/browser/permiss...
File chrome/browser/permissions/permission_prompt_android.cc (right):

https://codereview.chromium.org/2755593002/diff/180001/chrome/browser/permiss...
chrome/browser/permissions/permission_prompt_android.cc:47: //
CanAcceptRequestUpdate() return true.
On 2017/04/10 04:23:48, Timothy Loh wrote:
> I'm thinking of changing (in a separate patch of course)
> CanAcceptRequestUpdate() and all the parent calls of
CancelPermissionRequest(),
> etc., into something like onMojoConnectionError(). So then Hide() would only
be
> called externally in cases guarded by HidesAutomatically().

Acknowledged.

https://codereview.chromium.org/2755593002/diff/180001/chrome/browser/permiss...
File chrome/browser/permissions/permission_request_manager.cc (left):

https://codereview.chromium.org/2755593002/diff/180001/chrome/browser/permiss...
chrome/browser/permissions/permission_request_manager.cc:235: NOTREACHED();
On 2017/04/10 04:23:48, Timothy Loh wrote:
> Not sure if it's nicer to leave this here or change it to check
> HidesAutomatically()?

I don't have a strong opinion :)

[Timothy Loh, 2017-04-11 03:34:54]

timloh@chromium.org changed reviewers:
+ tapted@chromium.org

[Timothy Loh, 2017-04-11 03:34:54]

+tapted for small change in 
chrome/browser/ui/cocoa/permission_bubble/permission_bubble_cocoa.*

[tapted, 2017-04-11 05:21:26]

lgtm

https://codereview.chromium.org/2755593002/diff/180001/chrome/browser/ui/perm...
File chrome/browser/ui/permission_bubble/permission_prompt.h (right):

https://codereview.chromium.org/2755593002/diff/180001/chrome/browser/ui/perm...
chrome/browser/ui/permission_bubble/permission_prompt.h:65: // Returns true the
prompt UI will manage hiding itself when the user resolves
nit: true the -> true if the

[Timothy Loh, 2017-04-11 05:31:44]

Patchset #10 (id:200001) has been deleted

[Timothy Loh, 2017-04-11 05:34:53]

https://codereview.chromium.org/2755593002/diff/180001/chrome/browser/ui/perm...
File chrome/browser/ui/permission_bubble/permission_prompt.h (right):

https://codereview.chromium.org/2755593002/diff/180001/chrome/browser/ui/perm...
chrome/browser/ui/permission_bubble/permission_prompt.h:65: // Returns true the
prompt UI will manage hiding itself when the user resolves
On 2017/04/11 05:21:25, tapted wrote:
> nit: true the -> true if the

Done.

[Timothy Loh, 2017-04-11 05:35:00]

The CQ bit was checked by timloh@chromium.org

[Timothy Loh, 2017-04-11 05:35:00]

The patchset sent to the CQ was uploaded after l-g-t-m from
dominickn@chromium.org, tapted@chromium.org, benwells@chromium.org
Link to the patchset: https://codereview.chromium.org/2755593002/#ps220001
(title: "fix comment")

[commit-bot: I haz the power, 2017-04-11 05:35:28]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-11 06:24:50]

CQ is committing da patch.

Bot data: {"patchset_id": 220001, "attempt_start_ts": 1491888900246170,
"parent_rev": "2538f82823749761782a157ff3503834ee3262cc", "commit_rev":
"897fa146046239d6384aab548a93045f12bd5711"}

[commit-bot: I haz the power, 2017-04-11 06:26:02]

Description was changed from

==========
Remove pointer from PermissionPromptAndroid to InfoBar

This patch removes the pointer from PermissionPromptAndroid to InfoBar,
as preparation for supporting modal permission dialogs on android via
the PermissionRequestManager.

Currently, the pointer is only used for Hide() and IsVisible(). We can
use the PermissionRequest vector to see if a prompt is being shown, and
the calls to Hide() can no-op as they are already handled by the
InfoBarManager (e.g. page navigation, or after the user resolves the
prompt). If the PermissionServiceImpl receives a mojo connection error,
the PermissionRequestManager just dummies out its callback for active
prompts (on Android) as we return false in CanAcceptRequestUpdate().

We override EqualsDelegate() as the PermissionRequestManager will try to
Show() a queued bubble when it's called back after the user resolves a
prompt, but the callback happens before the active prompt is closed. The
parent's EqualsDelegate() would consider the new delegate the same as
the current one, and so it wouldn't show a new infobar.

This means we no longer have the following cycle of pointers:
  PermissionPromptAndroid ->
  GroupedPermissionInfoBar ->
  GroupedPermissionInfoBarDelegate ->
  PermissionPromptAndroid

When we later add modal permission dialogs, the PermissionPromptAndroid
will just need to check when it creates the actual UI what object to
make, but it won't need extra logic in Hide() or IsVisble().

BUG=606138
==========

to

==========
Remove pointer from PermissionPromptAndroid to InfoBar

This patch removes the pointer from PermissionPromptAndroid to InfoBar,
as preparation for supporting modal permission dialogs on android via
the PermissionRequestManager.

Currently, the pointer is only used for Hide() and IsVisible(). We can
use the PermissionRequest vector to see if a prompt is being shown, and
the calls to Hide() can no-op as they are already handled by the
InfoBarManager (e.g. page navigation, or after the user resolves the
prompt). If the PermissionServiceImpl receives a mojo connection error,
the PermissionRequestManager just dummies out its callback for active
prompts (on Android) as we return false in CanAcceptRequestUpdate().

We override EqualsDelegate() as the PermissionRequestManager will try to
Show() a queued bubble when it's called back after the user resolves a
prompt, but the callback happens before the active prompt is closed. The
parent's EqualsDelegate() would consider the new delegate the same as
the current one, and so it wouldn't show a new infobar.

This means we no longer have the following cycle of pointers:
  PermissionPromptAndroid ->
  GroupedPermissionInfoBar ->
  GroupedPermissionInfoBarDelegate ->
  PermissionPromptAndroid

When we later add modal permission dialogs, the PermissionPromptAndroid
will just need to check when it creates the actual UI what object to
make, but it won't need extra logic in Hide() or IsVisble().

BUG=606138

Review-Url: https://codereview.chromium.org/2755593002
Cr-Commit-Position: refs/heads/master@{#463551}
Committed:
https://chromium.googlesource.com/chromium/src/+/897fa146046239d6384aab548a93...
==========

[commit-bot: I haz the power, 2017-04-11 06:26:03]

Committed patchset #10 (id:220001) as
https://chromium.googlesource.com/chromium/src/+/897fa146046239d6384aab548a93...