Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
mfoltzgoogle opened this issue Sep 10, 2014 · 8 comments

Comments

@mfoltzgoogle
Copy link
Contributor

commented Sep 10, 2014

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?"

@mfoltzgoogle

This comment has been minimized.

Copy link
Contributor Author

commented Feb 10, 2015

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

This comment has been minimized.

Copy link
Member

commented Feb 10, 2015

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

This comment has been minimized.

Copy link
Contributor

commented May 14, 2015

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.
@mfoltzgoogle

This comment has been minimized.

Copy link
Contributor Author

commented Jun 26, 2015

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

This comment has been minimized.

Copy link

commented Jun 29, 2015

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 anssiko added the PING label Jun 29, 2015
@anssiko

This comment has been minimized.

Copy link
Member

commented Jun 29, 2015

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

This comment has been minimized.

Copy link
Member

commented Jun 29, 2015

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

This comment has been minimized.

Copy link
Member

commented Aug 21, 2015

Closing. Let's wait for PING feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.