User prompts to show an active screen-lock should have an associated domain

[jumde]

From the spec:

It is RECOMMENDED that a user agent show some form of unobtrusive notification that informs the user when a wake lock is active, as well as provides the user with the means to block the ongoing operation, or simply dismiss the notification.

To be transparent to the user the prompt should also highlight the domain(s) that have an active screen lock. This will help in cases where a third-party script is enabling screen-wake-lock, the user can choose to release the lock.

[tomayac]

I've written about this aspect in the past.

[reillyeon]

This seems like a browser UX choice that is out-of-scope for standardization beyond the recommendation quoted above.

[rakuco]

Is there anything we need to act upon here given Reilly's comment?

[jumde]

@reillyeon @rakuco - This can also be added as a recommendation in the spec. Without this, general users wouldn't be able to figure out which domain is requesting a screen-wake-lock

[rakuco]

By "this" do you mean the original suggestion of making the spec also recommend showing a domain name? If so, that's what Reilly considered out of scope, so it'd be good if you could elaborate.

[jumde]

@rakuco - That is correct. Without the domain, there is no way for the user to distinguish if the top-level document is requesting the lock or a compromised/malicious iframe is requesting the lock.

[reillyeon]

@jumde, the ability to use this feature in iframes is controlled by Permissions Policy. By default a cross-origin iframe cannot use this feature at all.

Speaking for Chrome it is unlikely that we would display origin of an iframe rather than that of the top-level document when notifying the user that a page is using this feature as that would go against the direction we've taken for Permission Delegation. The distinction between the top-level site abusing this capability and a cross-origin iframe it has delegate permission to doing so (intentionally or unintentionally) is irrelevant for users.

[marcoscaceres]

I agree with @reillyeon... more generally, I'm looking at, for example, how finding which tab is making noise is handled:

I.e., showing the origin is not as helpful as allowing a user to get to a particular tab that is using a resource (irrespective of origin... or even without showing any origin at all).

[marcoscaceres]

@jumde, for the purpose of record keeping and to allow the spec to progress along the W3C Rec track, are you satisfied with @reillyeon and my responses above? (i.e., we leave it browser UX engineers to figure out the best way for user to find these tabs, rather than explicitly mandating showing the origin.)

[marcoscaceres]

Thanks again @jumde! We appreciate the feedback and discussion.

@xfq, do we need to update the wide review tracker?

[xfq]

I've updated the wide review tracker.