Should this prompt?

[marcoscaceres]

Current implementations haven't found a need to show a permission prompt for screen wake lock (or give a way for a user to "deny" the permission).

In particular, I wonder if we should remove:

The [PERMISSIONS] API provides a uniform way for websites to request permissions from users and query which permissions they have.

That's just a "statement of fact".

My suggestion is that we keep the "screen-wake-lock" permission (which is used with Permission Policy - i.e., the HTTP header and allow=), but we then drop "screen-wake-lock" from the Permission spec itself.

We can always add it back later?

@reillyeon @kenchris @rakuco @anssiko - interested in your thoughts on this.

[rakuco]

In particular, I wonder if we should remove:

The [PERMISSIONS] API provides a uniform way for websites to request permissions from users and query which permissions they have.

That's just a "statement of fact".

This plan sounds OK to me at least.

My suggestion is that we keep the "screen-wake-lock" permission (which is used with Permission Policy - i.e., the HTTP header and allow=), but we then drop "screen-wake-lock" from the Permission spec itself.

We can always add it back later?

Hmm, given the discussions in w3c/permissions#247 and that Chromium does implement this integration with the Permissions API, is there a specific reason for changing course here?

[marcoscaceres]

Hmm, given the discussions in w3c/permissions#247 and that Chromium does implement this integration with the Permissions API, is there a specific reason for changing course here?

My concern is that we have a permission that’s not tied to a permission UI, so it doesn’t fit the purpose of the Permission spec. So, query()ing it is kinda meaningless as it always returns “granted”.

[reillyeon]

Hmm, given the discussions in w3c/permissions#247 and that Chromium does implement this integration with the Permissions API, is there a specific reason for changing course here?

My concern is that we have a permission that’s not tied to a permission UI, so it doesn’t fit the purpose of the Permission spec. So, query()ing it is kinda meaningless as it always returns “granted”.

In w3c/permissions#247 @martinthomson agreed that there's no substantial harm if query("screen-wake-lock") always returns true. As discussed there, this is about making sure the API design is flexible enough to support adding scenarios where permission may not be granted in the future. If we update the permission text I think we should acknowledge this as an area of future development based on additional implementation experience and that the "screen-wake-lock" permission identifier is a placeholder for that future work.

[marcoscaceres]

After gaining some more implementation experience and delving a little deeper into this topic, I have to disagree with @martinthomson on this one - as:

1. it puts an undue burden on implementers to support a query type. It may due "no harm", but It doesn't come with zero cost (it's not a big cost, but it's still a fair chunk of work to support in a browser engine).
2. It sets a not-so-great precedence: it standardizes something that we are not sure yet should be standardized.
3. It's confusing for developers (what actually brought me here): in that I can .query() the permission, but there is no actual corresponding Permission UI in any user agent.

I'd prefer we "unhook" screen wake lock from the Permission spec for now, until such time that we are 100% sure that there will be an actual permission UI.

So, I'm not saying we shouldn't have this eventually - I'm saying it's premature right now to have Permission API integration right now.

[martinthomson]

I find that argument convincing. If no UA is going to implement this as a permission, then that makes sense. If we can standardize behaviour that has no permissions, that is best for all involved.

If we have to add permissions in the future, I don't think that would prevent us from doing so. I am merely willing to accept that Chrome might want to manage this as a permission.

One thing to add though: Are we not considering using Permissions Policy to control this? That is, might sites want to prevent nested browsing contexts accessing the feature? That might suggest that there is still some value in the integration.

[marcoscaceres]

One thing to add though: Are we not considering using Permissions Policy to control this? That is, might sites want to prevent nested browsing contexts accessing the feature? That might suggest that there is still some value in the integration.

Yes, it's a policy controlled feature.

But even in that case, the Permissions Policy's API is the appropriate way to query this:

document.permissionsPolicy.allowsFeature("screen-wake-lock");

For policy controlled features, navigator.permission.query() only comes into play for UI-based features, whereby .query() always returns "denied". It doesn't do anything else that is helpful or meaningful.

[marcoscaceres]

Ping on this one also. Be nice if the Editors would address this bug as it's been over a year now.

[reillyeon]

@rakuco, please update the specification to remove the integration with the Permissions API since no implementation supports denying permission to use this feature.

[vinhill]

Screen Wake Lock lands in Firefox 124 without a permission prompt.

But we are thinking about having a setting so that a user can disable the API, see Bug 1877413. We haven't reached consensus yet but are interested in relying on the permissions API integration with Screen Wake Lock to implement these settings.

[reillyeon]

Thank you for sharing your implementation experience here. While I'm not particularly proud of the inaction here it seems like there is some desire for this option in the API.

[reillyeon]

As discussed at TPAC 2024:

• We will leave the Permissions API integration in place to support implementations that wish to provide user settings.
• Language implying a user prompt, which isn't implemented anywhere, will be removed.