Reject the getScreens() Promise with permission denial

[michaelwasserman]

The explainer currently lists some possible ways of Handling blocked permissions, without a clear recommendation:

It could be reasonable for getScreens() to handle a blocked permission or similar failure modes in one of several ways:

• Reject the promise and throw an exception
• Fulfill the promise with an empty array or dictionary
• Fulfill the promise with an array only containing the existing window.screen

According to feedback from several folks, getScreens() should just reject the Promise if the user denies permission:

"Rejecting the promise seems correct to me and matches other APIs. Ideally don't mix promises and events. " - @domenic

"Reject the promise and throw an exception" - only one of those. If a method returns a Promise, it should never throw. But yeah, rejecting seems correct. This may allow the site to signal to the user that permission was denied, giving the user the opportunity to diagnose a problem (i.e. "why can't I present on the second screen?") - @inexorabletash

[michaelwasserman]

I removed this section and made a note in the main proposal, which already stated that the promise should reject on failure, it now mentions permission denial as an example reason for failure. Current language:

The centerpiece of this proposal is to introduce a getScreens() method, which resolves to an array of Screen objects on success, and rejects otherwise (eg. if permission is denied).

[michaelwasserman]

I'm closing this issue, but feel free to reopen as needed!

[dbaron]

We discussed briefly in today's TAG meeting (coming here from https://github.com/w3ctag/design-reviews/issues/413#issuecomment-644546613).

I think rejecting the promise in the case of permission denial is an entirely reasonable thing to spec, and probably makes more sense than throwing an exception or returning an empty array of screens for that case.

However, I think some (maybe most?) cases of denial of permission to get this information might be for privacy reasons, and in those cases it seems more likely that a UA would want to instead expose something that looks like a common configuration (e.g., one screen of a standard size) rather than exposing an unusual behavior.

It also seems like the "permission" here might not be through a user prompt to ask for permission for this specific thing, but more of a general UA setting (e.g., a general privacy or anti-fingerprinting setting).

So it might make sense to also specify that implementations should be able to lie about the screens and report a common configuration if they think that's appropriate, perhaps in response to settings that the user has chosen.

[kenchris]

If we end up deprecating navigator.screen, there should still be a way to get at least one screen (on non headless browsers) without a rejected promise, IMHO. Otherwise it will be hard to deprecate. Maybe that could be done as a kind of filtering.

[michaelwasserman]

@dbaron If getScreens() returned fake information, it should be compatible with existing synchronously-accessible info from the window.screen interface. Fake screen bounds would add complexity for handling window placement requests. I'm not aware of other device APIs returning fake (e.g. Bluetooth) devices when permissions are denied. Returning limited information or rejecting the promise altogether seem like much better protections with sensible behavior for web developers.

@kenchris It seems reasonable for users or agents to expose limited information via getScreens() for privacy/security or other reasons; matching what window.screen exposes (or would have exposed) seems like a good way to help deprecate that API.

Overall, I believe that rejecting getScreens() promises (or furnishing limited, but accurate, information), blocking cross-screen (or all) window-placement requests, and exploring un-permissioned API deprecation or privacy-minded behavior (e.g. window.screen or its [unstandardized] properties yield undefined, window.outerWidth === window.innerWidth) are the most coherent protections for users that do not wish to offer screen information and window placement capabilities. My latest commit attempts to clarify language about exposing limited information. I also touch on how browsers could further limit unpermissioned access to existing information and capabilities.

Thanks for your consideration. I'm going to keep this issue closed, but please feel free to share additional feedback on the updated Window Placement repo.