Re: Push API change for permissions UX

Hi John,

I think it *might* make sense to ask for permission to display
notifications/UI at the same time as you ask for permission to "run in
the background".

Though someone would definitely need to check with mozilla's security
team to see how they feel since I know they've generally wanted to
keep dialogs separate.

However I don't think that it makes sense for apps to commit to
displaying UI when there's an incoming push. I'm not sure what problem
that would solve? It seems like in many cases you need to run client
side code in order to determine if UI should be displayed or not. For
example the user might be in a "don't disturb me mode" or have
configured a VoIP app to blocklist a certain caller from calling.

So it seems to me that keeping the two permissions separate is good
from an API point of view. But possibly we should have the ability to
ask for both things at once, and then leave it up to the UA to figure
out how to enable the user to answer "yes" to one, both, or either
capability.

/ Jonas

On Wed, Oct 22, 2014 at 11:02 AM, John Mellor <johnme@google.com> wrote:
> Hi folks,
>
> Based on our UX studies for Chrome, we've found the clearest way to do
> permissions UX for the Push API will be to have one prompt[1] that grants
> both full push messaging and background sync[2], and a separate prompt[3]
> that grants notifications plus a restricted form of push where each push
> event fired on the SW must trigger user-visible UI. This is because
> notifications without push are fairly useless on mobile.
>
> (The precise definition of a user-visible UI change would probably be
> something like: show a notification/popup, unless a notification/popup was
> already showing or the browser is the foreground app and a same-origin page
> is the foreground tab.)
>
> Obviously interop is crucial here: developers should be able to write code
> that works across browsers, whether or not those browsers use the same
> approach to permissions UX.
>
> Accordingly, we propose adding an optional dictionary to the Push API's
> register method:
>
> Promise<PushRegistration> register(optional PushRegisterOptions options);
> dictionary PushRegisterOptions { boolean userVisibleOnly = false; };
>
>
> If a developer passes {userVisibleOnly: true} they commit to triggering a
> user-visible UI change on every push.
>
> Browser vendors that don't want to distinguish between the two policies
> would presumably grant the full API anyway at this point. Hence we should
> probably also extend PushPermissionStatus with a new grantedUserVisibleOnly
> value so developers can use the hasPermission method to detect what state
> they are in:
>
> enum PushPermissionStatus { "granted", "grantedUserVisibleOnly", "denied",
> "default" };
>
>
> Since we're more confident about the permissions UI for user-visible push,
> and we think it's a useful standalone subset, we'd likely ship that part
> first (initially rejecting any registrations which didn't pass
> {userVisibleOnly: true}).
>
> But we're still very much committed to full push, and shipping that next
> would be our top priority.
>
> Thanks,
> John et al
>
> [1]: e.g. "origin.com wants to periodically update in the background so it
> works better offline"
> [2]: https://github.com/slightlyoff/BackgroundSync/blob/master/explainer.md
> [3]: e.g. "origin.com wants to send notifications after the page is closed"
> [4]: http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0008.html

Received on Wednesday, 22 October 2014 19:56:22 UTC