"Permissions show Notifications as [Allowed by you]"

is NOT the expected behavior. Policy takes precedence over user settings, so DefaultNotificationsSetting will override user-set exceptions. The fact that exceptions should override the default setting because they are more specific is only true within the same provider (i.e. policy default vs. policy exceptions, user default vs. user exceptions).

This means that if the policy is left unset, the user will be asked the first time, make a decision, and that decision will be stored and respected the next time.

If the policy is set to ASK, the user will be asked every time.

huangs@ is currently making changes to allow for "weaker" default policy settings that are overrideable by users, which can be applied to this issue.

I've been having issues with this in a GAS WebApp I'm developing to be used in a school environment. The user begins a task that takes a long time from the application and should be able to put that tab/window in the background. When the user begins the task they are prompted to allow notifications and, if signed in on a non-managed account, when it is done a notification is displayed so they can respond, which is only possible for a few minutes. Without notifications it's easy to miss the window of time in which they can respond.

When the permission is set to "Ask (by policy)" as it is for students there is no way to show notifications whatsoever, whether they click allow or not. As this is effectively equivalent to "Always block" with the exception of misleading popups requesting permissions that cannot be granted, I cannot imagine that this is the intended behavior.

Steps to reproduce, using an account with the policy set:
1. Request permissions to show a notification (Notification.requestPermission())
2. Press "Allow" to allow notifications
3. Trigger a notification (new Notification("..."))
4. Check the permission (Notification.permission)

Expected behavior:
A notification is shown, and the Notification permission is "granted" for at until the page is reloaded

Actual behavior:
No notification is shown; the Notification permission remains "default" even though the Notification.requestPermission() promise resolves as "granted"

I'm not worried about this permission being maintained between sessions or even page loads, but it seems like once a user clicks "allow" the page should be able to send notifications. "Asked every time" is ridiculous if the response is immediately thrown away.

Deleted: expected.png 80.2 KB

	expected.png 80.2 KB View Download

Deleted: actual.gif 587 KB

	actual.gif 587 KB View Download

case: 14316576
I've a customer that is asking about this bug.
It's possible to find a solution ?
I've followed the repro steps in #2
this issue is still happening also in canary (66.0.3353.2 )

what do you think of modify this policy to have only this two possible value:
1 = Allow sites to show desktop notifications
2 = Do not allow any site to show desktop notifications

If this policy is left not set, 'AskNotifications' will be used and the user will be able to change it.

there will be less confusion.

cross-link with  crbug.com/155519 , customer escalated

I agree the behaviour as described is confusing and undesirable - admins could easily mistakenly assume 'ask' means the same as 'not set', when in practice it's equivalent to 'always block' (as pointed out in comment #2), at least for notification permissions. Can anyone confirm whether this is also an issue for other types of permissions? (eg camera&microphone, location).

I'm unclear on what happens if policy admins set the policy to 'allow sites to show desktop notifications' - do all sites then get automatic permission until they are individually blocked? If so then we probably don't want to simply remove the 'ASK' option for notification policy, instead we should just make 'ASK' behave the same as 'unset'.

huangs@ - can you provide any updates or thoughts on this? I see from #1 that you were working on this over 2 years ago, so perhaps you're no longer the right owner for this ? (In which case please reassign/unassign so it gets picked up by triage).

> I'm unclear on what happens if policy admins set the policy to 'allow sites to show desktop notifications' - do all sites then get automatic permission until they are individually blocked?

No, the policy always takes precedence over user settings. Once the policy default setting is set, all user settings are ignored. Only policy exceptions can override the policy default setting.

In other words, the current precedence is:

policy exceptions > policy default > user exceptions > user default

The feature request in this bug, as I understand it, is:

policy exceptions > user exceptions > policy default > user default

In practice, both approaches might be desirable by admins, so we may want to have a switch to support both. huangs@ had a design doc for this back in 2016, but it was a low priority at that time, and I don't think he's working on this anymore.

Updating labels.

Flipping to "Untriaged" to put it back into the Enterprise team's queue.

+some people who might be able help triage this. Moving current owner to cc.

We had an offline discussion - next step was for fredrickjones@ to put together a one-page proposal on what the behavior should be, what platforms we need to support, etc.

 Issue 155519  has been merged into this issue.

Hello!
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time.
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Thursday, 01/17/19 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!

Due to lack of action this bug has been Archived. If work is still being done on this issue or you are still experiencing this issue please feel free to re-open with the appropriate information.