Define return value for cancelled/missing session for startSession/joinSession

[markafoltz]

avayvod@google.com writes:
"Also, what do the function(s) return if the session is not established (e.g. user exits the selection UI by dismissing the popup menu or there's no existing session to join) ? An uninitialized useless session object? Or should we change the return type to a Promise that passes a session to the caller if it succeeds?"

[markafoltz]

The current spec reads

If the user cancels screen selection, the Promise returned by startSession(url, presentationId) remains unresolved.

Is this the behavior we want?

[anssiko]

An unresolved promise would protect the user's privacy, as it does not disclose the fact the user actively dismisses the screen picker UI.

As a drawback, that'd make it impossible for the script to know startSession() invocation failed without resorting to hacks such as an expiring timer that checks for the existence of a session (and this given no reason, obviously).

A use case that would benefit from an explicit rejection, and optionally its reason:

1. A site, say FooTube, uses the Presentation API to show some of its content on a second screen.
2. The user clicks "Show on my big screen" button.
3. The user disallows the request or an error occurs in establishing the session.
4. The site provides a fallback UX tailored for the site that provides the user instructions on how to resolve the issue, optionally with a reason why the request failed.

Alternative approach is to leave all the fallback UX to the UA to address, let the UA inform the user of errors, provide instructs on how to resolve if an error occurs, and not inform the script of rejection (leave the promise unresolved).

With that, I'm wondering if the spec should leave some room for UAs to innovate, to be able to provide a UI from which the user can:

• Allow - promise resolved with a session
• Block - promise rejected with a reason
• Dismiss - promise unresolved

"Dismiss" might map to e.g. clicking [x] or "Cancel" button to close the dialog, while "Allow" and "Block" would be more explicit actions, such as buttons. Naturally, the spec will not mandate any specific UI style, and as long as the requests are asynchronous to not block the main thread we'd be good.

@avayvod - is there something to be learned from your implementation experiences since the issue was opened?

All - WDYT?

[schien]

I would prefer to reject this Promise while user dismiss the selection dialog. An unresolved Promise is "leaked" until page is closed and web developer cannot destroy it. I'll suggest using following UI behavior:

• Allow - promise resolved with a session
• Cancel - promise reject with a reason
• optionally this dialog can provide an option "block forever" which prevents a malicious page requesting session automatically.

[markafoltz]

I think the proposal by @schien can be implemented with the current spec; it allows the UA to reject the Promise with a DOMException of type AbortError if the user denies permission, either one time or permanently.

And I believe that always resolving allows the controlling page to implement the fallback behavior that @anssiko outlines above.

As far as the implementation in Chrome - currently we allow the user to initiate presentation, or close the dialog without selecting a display. We don't have a block option, but I wouldn't rule that out in the future.

[obeletski]

I also support proposal of @schien.
Double checked "Writing Promise-Using Specifications" document. It lists the case of permission denial as a good reason for rejecting the promise [1].
[1] http://www.w3.org/2001/tag/doc/promises-guide#rejections-should-be-exceptional

[anssiko]

The Privacy Interest Group (PING) should be asked for feedback with regard to this issue, so I'm tagging this with the newly minted "PING" label. We'll initiate the review after we've published the updated Working Draft.

@schien's proposal would be conformant with the current spec, since in 6.4.1 Starting a presentation session:

If T completes with the user denying permission, run the following steps:
Reject P with a DOMException named "AbortError".

I expect no changes to the spec on this detail prior to consulting PING on the matter.

[anssiko]

Oh the typo. I obviously meant "published the updated Working Draft". Fixed.

We appear to be on track to publish tomorrow, so we can initiate the PING review soon after.

[mounirlamouri]

Closing. Let's wait for PING feedback.