Use the same codepath for NOTIFICATIONS and PUSH_MESSAGING permissions

Use the same codepath for NOTIFICATIONS and PUSH_MESSAGING permissions

We used to have a complicated dependency between the notifications and push
messaging permissions and content settings. The push messaging content setting
will no longer be used (the setting will be deleted in a follow up CL). Since
the permissions are essentially the same now, we reuse the same
PermissionContext class for both, with some very slight behavioral differences
for push messaging.

Behaviorally, this change will mean that if a user happened to have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set to block for a particular origin,
they will fall back to their CONTENT_SETTINGS_TYPE_NOTIFICATIONS setting for
that origin. Note that it's very unlikely that any users do have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set, as it seems like this setting
was never actually exposed to users on stable. More details can be found here:
https://docs.google.com/document/d/1-Vny4paBx6gFZuCeLX2Gq9ztkF-JhNYM_uqvrQDj-6M/edit#heading=h.h99sppup43dn

BUG=628058
Committed: https://crrev.com/4f82b403f397fbad2e44fe287c05956fcb7cf282
Committed: https://crrev.com/d54345e651e054756b3c00fc80db05170f6cc129
Cr-Original-Commit-Position: refs/heads/master@{#406225}
Cr-Commit-Position: refs/heads/master@{#406768}

[raymes, 2016-07-14 01:44:49]

Description was changed from

==========
Use the same codepaths for NOTIFICATIONS and PUSH_MESSAGING permissions

We used to have a complicated dependency between the notifications and push
messaging permissions and content settings. The push messaging content setting
will no longer be used (the setting will be deleted in a follow up CL). Since
the permissions are essentially the same now, we reuse the same
PermissionContext class for both, with some very slight behavioral differences
for push messaging.

BUG=628058
==========

to

==========
Use the same codepaths for NOTIFICATIONS and PUSH_MESSAGING permissions

We used to have a complicated dependency between the notifications and push
messaging permissions and content settings. The push messaging content setting
will no longer be used (the setting will be deleted in a follow up CL). Since
the permissions are essentially the same now, we reuse the same
PermissionContext class for both, with some very slight behavioral differences
for push messaging.

Behaviorally, this change will mean that if a user happened to have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set to block for a particular origin,
they will fall back to their CONTENT_SETTINGS_TYPE_NOTIFICATIONS setting for
that origin. Note that it's very unlikely that any users do have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set, as it seems like this setting
was never actually exposed to users on stable. More details can be found here:
https://docs.google.com/document/d/1-Vny4paBx6gFZuCeLX2Gq9ztkF-JhNYM_uqvrQDj-...

BUG=628058
==========

[raymes, 2016-07-14 01:47:56]

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

[raymes, 2016-07-14 01:47:57]

Hey Peter,

Let me know if this approach seems reasonable to you. If it looks ok, I'll
update the tests to add back some test coverage which is currently being
removed.

Thanks!
Raymes

[raymes, 2016-07-14 01:48:07]

Description was changed from

==========
Use the same codepaths for NOTIFICATIONS and PUSH_MESSAGING permissions

We used to have a complicated dependency between the notifications and push
messaging permissions and content settings. The push messaging content setting
will no longer be used (the setting will be deleted in a follow up CL). Since
the permissions are essentially the same now, we reuse the same
PermissionContext class for both, with some very slight behavioral differences
for push messaging.

Behaviorally, this change will mean that if a user happened to have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set to block for a particular origin,
they will fall back to their CONTENT_SETTINGS_TYPE_NOTIFICATIONS setting for
that origin. Note that it's very unlikely that any users do have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set, as it seems like this setting
was never actually exposed to users on stable. More details can be found here:
https://docs.google.com/document/d/1-Vny4paBx6gFZuCeLX2Gq9ztkF-JhNYM_uqvrQDj-...

BUG=628058
==========

to

==========
Use the same codepath for NOTIFICATIONS and PUSH_MESSAGING permissions

We used to have a complicated dependency between the notifications and push
messaging permissions and content settings. The push messaging content setting
will no longer be used (the setting will be deleted in a follow up CL). Since
the permissions are essentially the same now, we reuse the same
PermissionContext class for both, with some very slight behavioral differences
for push messaging.

Behaviorally, this change will mean that if a user happened to have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set to block for a particular origin,
they will fall back to their CONTENT_SETTINGS_TYPE_NOTIFICATIONS setting for
that origin. Note that it's very unlikely that any users do have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set, as it seems like this setting
was never actually exposed to users on stable. More details can be found here:
https://docs.google.com/document/d/1-Vny4paBx6gFZuCeLX2Gq9ztkF-JhNYM_uqvrQDj-...

BUG=628058
==========

[Peter Beverloo, 2016-07-14 17:15:18]

peter@chromium.org changed reviewers:
+ miguelg@chromium.org

[Peter Beverloo, 2016-07-14 17:15:19]

lgtm, thank you! +miguelg in case he wants to have a look

https://codereview.chromium.org/2149883002/diff/20001/chrome/browser/notifica...
File chrome/browser/notifications/notification_permission_context.cc (right):

https://codereview.chromium.org/2149883002/diff/20001/chrome/browser/notifica...
chrome/browser/notifications/notification_permission_context.cc:180: return
CONTENT_SETTING_BLOCK;
Is GetPermissionStatus() always checked before DecidePermission()? The
different-origin check has been removed from there.

https://codereview.chromium.org/2149883002/diff/20001/chrome/browser/notifica...
chrome/browser/notifications/notification_permission_context.cc:261: return
false;
nit:

  return permission_type() == content::PermissionType::PUSH_MESSAGING;

https://codereview.chromium.org/2149883002/diff/20001/chrome/browser/notifica...
File chrome/browser/notifications/notification_permission_context_unittest.cc
(right):

https://codereview.chromium.org/2149883002/diff/20001/chrome/browser/notifica...
chrome/browser/notifications/notification_permission_context_unittest.cc:304: }
Would you mind adding some very simple tests for the
PermissionType::PUSH_MESSAGING differences? (Effectively change-detector tests,
I guess.)

[johnme, 2016-07-14 17:26:35]

FWIW this changes the API semantics slightly: previously
PushManager.permissionState would only resolve to "granted" if the website had
previously called PushManager.subscribe. Now it will return "granted" even if
you have only called Notification.requestPermission(), but never actually
subscribed for push. But I've discussed this with Peter, and it's probably ok.

[Miguel Garcia, 2016-07-14 18:02:04]

lgtm

https://codereview.chromium.org/2149883002/diff/20001/chrome/browser/notifica...
File chrome/browser/notifications/notification_permission_context.cc (right):

https://codereview.chromium.org/2149883002/diff/20001/chrome/browser/notifica...
chrome/browser/notifications/notification_permission_context.cc:178: if
(permission_type() == content::PermissionType::PUSH_MESSAGING &&
perhaps it's worth adding a comment on why?

https://codereview.chromium.org/2149883002/diff/20001/chrome/browser/notifica...
chrome/browser/notifications/notification_permission_context.cc:180: return
CONTENT_SETTING_BLOCK;
On 2016/07/14 17:15:19, Peter Beverloo wrote:
> Is GetPermissionStatus() always checked before DecidePermission()? The
> different-origin check has been removed from there.

Yes, this is enforced by the base class. The different origin check cannot be
ported to DecidePermission because GetPermissionStatus by default returns ALLOW
if the content setting says allow which in this case would be wrong.

https://codereview.chromium.org/2149883002/diff/20001/chrome/browser/push_mes...
File chrome/browser/push_messaging/push_messaging_permission_context.h (left):

https://codereview.chromium.org/2149883002/diff/20001/chrome/browser/push_mes...
chrome/browser/push_messaging/push_messaging_permission_context.h:1: //
Copyright 2015 The Chromium Authors. All rights reserved.
Can you change the comment mentioning this file in
https://cs.chromium.org/chromium/src/chrome/browser/permissions/permission_co...
?

https://codereview.chromium.org/2149883002/diff/20001/chrome/browser/push_mes...
File chrome/browser/push_messaging/push_messaging_permission_context_unittest.cc
(left):

https://codereview.chromium.org/2149883002/diff/20001/chrome/browser/push_mes...
chrome/browser/push_messaging/push_messaging_permission_context_unittest.cc:141:
TEST_F(PushMessagingPermissionContextTest, HasPermissionDenyDifferentOrigins) {
Can we add this test case to the notification test now?

[raymes, 2016-07-18 07:04:51]

Thanks all!

https://codereview.chromium.org/2149883002/diff/20001/chrome/browser/notifica...
File chrome/browser/notifications/notification_permission_context.cc (right):

https://codereview.chromium.org/2149883002/diff/20001/chrome/browser/notifica...
chrome/browser/notifications/notification_permission_context.cc:178: if
(permission_type() == content::PermissionType::PUSH_MESSAGING &&
On 2016/07/14 18:02:03, Miguel Garcia wrote:
> perhaps it's worth adding a comment on why?

Done.

https://codereview.chromium.org/2149883002/diff/20001/chrome/browser/notifica...
chrome/browser/notifications/notification_permission_context.cc:261: return
false;
On 2016/07/14 17:15:19, Peter Beverloo wrote:
> nit:
> 
>   return permission_type() == content::PermissionType::PUSH_MESSAGING;

Done.

https://codereview.chromium.org/2149883002/diff/20001/chrome/browser/notifica...
File chrome/browser/notifications/notification_permission_context_unittest.cc
(right):

https://codereview.chromium.org/2149883002/diff/20001/chrome/browser/notifica...
chrome/browser/notifications/notification_permission_context_unittest.cc:304: }
On 2016/07/14 17:15:19, Peter Beverloo wrote:
> Would you mind adding some very simple tests for the
> PermissionType::PUSH_MESSAGING differences? (Effectively change-detector
tests,
> I guess.)
> 

Done.

https://codereview.chromium.org/2149883002/diff/20001/chrome/browser/push_mes...
File chrome/browser/push_messaging/push_messaging_permission_context_unittest.cc
(left):

https://codereview.chromium.org/2149883002/diff/20001/chrome/browser/push_mes...
chrome/browser/push_messaging/push_messaging_permission_context_unittest.cc:141:
TEST_F(PushMessagingPermissionContextTest, HasPermissionDenyDifferentOrigins) {
On 2016/07/14 18:02:03, Miguel Garcia wrote:
> Can we add this test case to the notification test now?

Done.

[raymes, 2016-07-18 07:05:31]

On 2016/07/14 17:26:35, johnme wrote:
> FWIW this changes the API semantics slightly: previously
> PushManager.permissionState would only resolve to "granted" if the website had
> previously called PushManager.subscribe. Now it will return "granted" even if
> you have only called Notification.requestPermission(), but never actually
> subscribed for push. But I've discussed this with Peter, and it's probably ok.

Thanks - I didn't think about that but I agree that it should be ok.

[raymes, 2016-07-18 07:05:36]

The CQ bit was checked by raymes@chromium.org

[raymes, 2016-07-18 07:05:37]

The patchset sent to the CQ was uploaded after l-g-t-m from peter@chromium.org,
miguelg@chromium.org
Link to the patchset: https://codereview.chromium.org/2149883002/#ps30001
(title: "")

[commit-bot: I haz the power, 2016-07-18 07:05:49]

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, 2016-07-18 07:34:45]

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

[commit-bot: I haz the power, 2016-07-18 07:34:46]

Try jobs failed on following builders:
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[raymes, 2016-07-19 01:09:07]

The CQ bit was checked by raymes@chromium.org

[raymes, 2016-07-19 01:09:08]

The patchset sent to the CQ was uploaded after l-g-t-m from peter@chromium.org,
miguelg@chromium.org
Link to the patchset: https://codereview.chromium.org/2149883002/#ps50001
(title: "")

[commit-bot: I haz the power, 2016-07-19 01:10:08]

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, 2016-07-19 01:55:57]

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

[commit-bot: I haz the power, 2016-07-19 01:55:59]

Try jobs failed on following builders:
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[raymes, 2016-07-19 05:18:09]

The CQ bit was checked by raymes@chromium.org

[raymes, 2016-07-19 05:18:10]

The patchset sent to the CQ was uploaded after l-g-t-m from peter@chromium.org,
miguelg@chromium.org
Link to the patchset: https://codereview.chromium.org/2149883002/#ps70001
(title: ".")

[commit-bot: I haz the power, 2016-07-19 05:18:22]

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, 2016-07-19 07:04:50]

Description was changed from

==========
Use the same codepath for NOTIFICATIONS and PUSH_MESSAGING permissions

We used to have a complicated dependency between the notifications and push
messaging permissions and content settings. The push messaging content setting
will no longer be used (the setting will be deleted in a follow up CL). Since
the permissions are essentially the same now, we reuse the same
PermissionContext class for both, with some very slight behavioral differences
for push messaging.

Behaviorally, this change will mean that if a user happened to have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set to block for a particular origin,
they will fall back to their CONTENT_SETTINGS_TYPE_NOTIFICATIONS setting for
that origin. Note that it's very unlikely that any users do have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set, as it seems like this setting
was never actually exposed to users on stable. More details can be found here:
https://docs.google.com/document/d/1-Vny4paBx6gFZuCeLX2Gq9ztkF-JhNYM_uqvrQDj-...

BUG=628058
==========

to

==========
Use the same codepath for NOTIFICATIONS and PUSH_MESSAGING permissions

We used to have a complicated dependency between the notifications and push
messaging permissions and content settings. The push messaging content setting
will no longer be used (the setting will be deleted in a follow up CL). Since
the permissions are essentially the same now, we reuse the same
PermissionContext class for both, with some very slight behavioral differences
for push messaging.

Behaviorally, this change will mean that if a user happened to have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set to block for a particular origin,
they will fall back to their CONTENT_SETTINGS_TYPE_NOTIFICATIONS setting for
that origin. Note that it's very unlikely that any users do have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set, as it seems like this setting
was never actually exposed to users on stable. More details can be found here:
https://docs.google.com/document/d/1-Vny4paBx6gFZuCeLX2Gq9ztkF-JhNYM_uqvrQDj-...

BUG=628058
==========

[commit-bot: I haz the power, 2016-07-19 07:04:52]

Committed patchset #5 (id:70001)

[commit-bot: I haz the power, 2016-07-19 07:06:00]

Description was changed from

==========
Use the same codepath for NOTIFICATIONS and PUSH_MESSAGING permissions

We used to have a complicated dependency between the notifications and push
messaging permissions and content settings. The push messaging content setting
will no longer be used (the setting will be deleted in a follow up CL). Since
the permissions are essentially the same now, we reuse the same
PermissionContext class for both, with some very slight behavioral differences
for push messaging.

Behaviorally, this change will mean that if a user happened to have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set to block for a particular origin,
they will fall back to their CONTENT_SETTINGS_TYPE_NOTIFICATIONS setting for
that origin. Note that it's very unlikely that any users do have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set, as it seems like this setting
was never actually exposed to users on stable. More details can be found here:
https://docs.google.com/document/d/1-Vny4paBx6gFZuCeLX2Gq9ztkF-JhNYM_uqvrQDj-...

BUG=628058
==========

to

==========
Use the same codepath for NOTIFICATIONS and PUSH_MESSAGING permissions

We used to have a complicated dependency between the notifications and push
messaging permissions and content settings. The push messaging content setting
will no longer be used (the setting will be deleted in a follow up CL). Since
the permissions are essentially the same now, we reuse the same
PermissionContext class for both, with some very slight behavioral differences
for push messaging.

Behaviorally, this change will mean that if a user happened to have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set to block for a particular origin,
they will fall back to their CONTENT_SETTINGS_TYPE_NOTIFICATIONS setting for
that origin. Note that it's very unlikely that any users do have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set, as it seems like this setting
was never actually exposed to users on stable. More details can be found here:
https://docs.google.com/document/d/1-Vny4paBx6gFZuCeLX2Gq9ztkF-JhNYM_uqvrQDj-...

BUG=628058

Committed: https://crrev.com/4f82b403f397fbad2e44fe287c05956fcb7cf282
Cr-Commit-Position: refs/heads/master@{#406225}
==========

[commit-bot: I haz the power, 2016-07-19 07:06:01]

Patchset 5 (id:??) landed as
https://crrev.com/4f82b403f397fbad2e44fe287c05956fcb7cf282
Cr-Commit-Position: refs/heads/master@{#406225}

[raymes, 2016-07-20 00:25:59]

Description was changed from

==========
Use the same codepath for NOTIFICATIONS and PUSH_MESSAGING permissions

We used to have a complicated dependency between the notifications and push
messaging permissions and content settings. The push messaging content setting
will no longer be used (the setting will be deleted in a follow up CL). Since
the permissions are essentially the same now, we reuse the same
PermissionContext class for both, with some very slight behavioral differences
for push messaging.

Behaviorally, this change will mean that if a user happened to have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set to block for a particular origin,
they will fall back to their CONTENT_SETTINGS_TYPE_NOTIFICATIONS setting for
that origin. Note that it's very unlikely that any users do have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set, as it seems like this setting
was never actually exposed to users on stable. More details can be found here:
https://docs.google.com/document/d/1-Vny4paBx6gFZuCeLX2Gq9ztkF-JhNYM_uqvrQDj-...

BUG=628058

Committed: https://crrev.com/4f82b403f397fbad2e44fe287c05956fcb7cf282
Cr-Commit-Position: refs/heads/master@{#406225}
==========

to

==========
Use the same codepath for NOTIFICATIONS and PUSH_MESSAGING permissions

We used to have a complicated dependency between the notifications and push
messaging permissions and content settings. The push messaging content setting
will no longer be used (the setting will be deleted in a follow up CL). Since
the permissions are essentially the same now, we reuse the same
PermissionContext class for both, with some very slight behavioral differences
for push messaging.

Behaviorally, this change will mean that if a user happened to have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set to block for a particular origin,
they will fall back to their CONTENT_SETTINGS_TYPE_NOTIFICATIONS setting for
that origin. Note that it's very unlikely that any users do have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set, as it seems like this setting
was never actually exposed to users on stable. More details can be found here:
https://docs.google.com/document/d/1-Vny4paBx6gFZuCeLX2Gq9ztkF-JhNYM_uqvrQDj-...

BUG=628058

Committed: https://crrev.com/4f82b403f397fbad2e44fe287c05956fcb7cf282
Cr-Commit-Position: refs/heads/master@{#406225}
==========

[raymes, 2016-07-21 01:17:49]

The CQ bit was checked by raymes@chromium.org

[raymes, 2016-07-21 01:17:49]

The patchset sent to the CQ was uploaded after l-g-t-m from peter@chromium.org,
miguelg@chromium.org
Link to the patchset: https://codereview.chromium.org/2149883002/#ps90001
(title: ".")

[commit-bot: I haz the power, 2016-07-21 01:18:26]

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, 2016-07-21 02:47:24]

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

[commit-bot: I haz the power, 2016-07-21 02:47:26]

Try jobs failed on following builders:
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[raymes, 2016-07-21 04:16:29]

The CQ bit was checked by raymes@chromium.org

[commit-bot: I haz the power, 2016-07-21 04:16:38]

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, 2016-07-21 04:58:28]

Description was changed from

==========
Use the same codepath for NOTIFICATIONS and PUSH_MESSAGING permissions

We used to have a complicated dependency between the notifications and push
messaging permissions and content settings. The push messaging content setting
will no longer be used (the setting will be deleted in a follow up CL). Since
the permissions are essentially the same now, we reuse the same
PermissionContext class for both, with some very slight behavioral differences
for push messaging.

Behaviorally, this change will mean that if a user happened to have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set to block for a particular origin,
they will fall back to their CONTENT_SETTINGS_TYPE_NOTIFICATIONS setting for
that origin. Note that it's very unlikely that any users do have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set, as it seems like this setting
was never actually exposed to users on stable. More details can be found here:
https://docs.google.com/document/d/1-Vny4paBx6gFZuCeLX2Gq9ztkF-JhNYM_uqvrQDj-...

BUG=628058

Committed: https://crrev.com/4f82b403f397fbad2e44fe287c05956fcb7cf282
Cr-Commit-Position: refs/heads/master@{#406225}
==========

to

==========
Use the same codepath for NOTIFICATIONS and PUSH_MESSAGING permissions

We used to have a complicated dependency between the notifications and push
messaging permissions and content settings. The push messaging content setting
will no longer be used (the setting will be deleted in a follow up CL). Since
the permissions are essentially the same now, we reuse the same
PermissionContext class for both, with some very slight behavioral differences
for push messaging.

Behaviorally, this change will mean that if a user happened to have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set to block for a particular origin,
they will fall back to their CONTENT_SETTINGS_TYPE_NOTIFICATIONS setting for
that origin. Note that it's very unlikely that any users do have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set, as it seems like this setting
was never actually exposed to users on stable. More details can be found here:
https://docs.google.com/document/d/1-Vny4paBx6gFZuCeLX2Gq9ztkF-JhNYM_uqvrQDj-...

BUG=628058

Committed: https://crrev.com/4f82b403f397fbad2e44fe287c05956fcb7cf282
Cr-Commit-Position: refs/heads/master@{#406225}
==========

[commit-bot: I haz the power, 2016-07-21 04:58:29]

Committed patchset #6 (id:90001)

[commit-bot: I haz the power, 2016-07-21 05:00:43]

Description was changed from

==========
Use the same codepath for NOTIFICATIONS and PUSH_MESSAGING permissions

We used to have a complicated dependency between the notifications and push
messaging permissions and content settings. The push messaging content setting
will no longer be used (the setting will be deleted in a follow up CL). Since
the permissions are essentially the same now, we reuse the same
PermissionContext class for both, with some very slight behavioral differences
for push messaging.

Behaviorally, this change will mean that if a user happened to have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set to block for a particular origin,
they will fall back to their CONTENT_SETTINGS_TYPE_NOTIFICATIONS setting for
that origin. Note that it's very unlikely that any users do have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set, as it seems like this setting
was never actually exposed to users on stable. More details can be found here:
https://docs.google.com/document/d/1-Vny4paBx6gFZuCeLX2Gq9ztkF-JhNYM_uqvrQDj-...

BUG=628058

Committed: https://crrev.com/4f82b403f397fbad2e44fe287c05956fcb7cf282
Cr-Commit-Position: refs/heads/master@{#406225}
==========

to

==========
Use the same codepath for NOTIFICATIONS and PUSH_MESSAGING permissions

We used to have a complicated dependency between the notifications and push
messaging permissions and content settings. The push messaging content setting
will no longer be used (the setting will be deleted in a follow up CL). Since
the permissions are essentially the same now, we reuse the same
PermissionContext class for both, with some very slight behavioral differences
for push messaging.

Behaviorally, this change will mean that if a user happened to have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set to block for a particular origin,
they will fall back to their CONTENT_SETTINGS_TYPE_NOTIFICATIONS setting for
that origin. Note that it's very unlikely that any users do have
CONTENT_SETTINGS_TYPE_PUSH_MESSAGING set, as it seems like this setting
was never actually exposed to users on stable. More details can be found here:
https://docs.google.com/document/d/1-Vny4paBx6gFZuCeLX2Gq9ztkF-JhNYM_uqvrQDj-...

BUG=628058

Committed: https://crrev.com/4f82b403f397fbad2e44fe287c05956fcb7cf282
Committed: https://crrev.com/d54345e651e054756b3c00fc80db05170f6cc129
Cr-Original-Commit-Position: refs/heads/master@{#406225}
Cr-Commit-Position: refs/heads/master@{#406768}
==========

[commit-bot: I haz the power, 2016-07-21 05:00:45]

Patchset 6 (id:??) landed as
https://crrev.com/d54345e651e054756b3c00fc80db05170f6cc129
Cr-Commit-Position: refs/heads/master@{#406768}