Confirming this issue. We should bring this up in the spec and figure out how to deal with this one. Leaving this in the Blink component as we don't have a dedicated component for the notification API (and this is not about the notifications UI, for which we have a component).

I have an open pull request on the notifications spec partially covering this at https://github.com/whatwg/notifications/pull/121.

I don't really see why we need to expose this through any web-facing APIs. The spec should simply move to saying that notifications are not allowed in non-top-level, non-secure contexts.

#c1 - UI>Notifications captures both.

If all other browsers agree with restricting the permission requests to top-level, secure-context pages, then it should be fairly straightforward to land the spec change. AFAIK Mozilla doesn't, though, at least in their implementation.

Let me assign this to myself.

I take it you miss spoke and are referring to notification permission requests and not notifications themselves to be disallowed at non-top-level.

We shouldn't mix up this situation with the dis-allowance of notifications from non-secure contexts. Because those are never allowed through Blink.
https://www.chromestatus.com/feature/5759967025954816

Embedded pages are still allowed to create notifications, they are just required to get the permission as a top level page.

So `denied` might reflect the state for non-secure contexts, but it doesn't for embedded ones.

Btw, could you point me to the whatwg discussion on the topic.

Is your concern that the initial state for Notification.permission is "denied" for non-top-level pages, where "default" would be returned for a top-level page?

We'd like the result of querying permission state (e.g. Notification.permission & permissions.query()) to be "denied" when requesting the permission is going to be automatically denied too. The reason for automatically denying the permission can by due to various browser-level heuristics, which can't all be captured by the standard.

What is the specific use-case you're looking to address with this knowledge? Requesting any permission in a top-level frame is always going to be more clear to your users, because it gives them significantly more context on what they're agreeing to.

> Is your concern that the initial state for Notification.permission is "denied" for non-top-level pages, where "default" would be returned for a top-level page?

Yes.
The proposed way of handling a permission request from an iframe is to spawn a new top window page. But there might be situations where you don't want to bother the user in this way if the user has already denied notifications. But currently you need to always spawn the window to derive the actual state.

> Requesting any permission in a top-level frame is always going to be more clear to your users, because it gives them significantly more context on what they're agreeing to.

This is a bit besides the point, I'm not sure I agree. I would say that there are plenty other UI/UX techniques for making the origin clear that rival a popup. Also, I think it makes revoking permissions for an embedded page more problematic for the user.