Re: Push API change for permissions UX

2014-10-27 Thread Jonas Sicking
On Sat, Oct 25, 2014 at 11:42 PM, Jake Archibald wrote: > This discussion is about how often push may be processed silently (without > showing a notification), not if a push notification may *only* show a > notification. Ok. I think this comes back to the old problem of that different UAs have d

Re: Push API change for permissions UX

2014-10-27 Thread Jake Archibald
Example https://www.youtube.com/watch?v=0i7YdSEQI1w - Twitter shows notifications without caching, creating a poor offline (or poor connectivity) experience. You can actually be left with less information after tapping the notification than before. On 26 October 2014 06:42, Jake Archibald wrote:

Re: Push API change for permissions UX

2014-10-25 Thread Jake Archibald
This discussion is about how often push may be processed silently (without showing a notification), not if a push notification may *only* show a notification. The latter was shown to be insufficient in the other thread. On Fri, Oct 24, 2014 at 9:39 AM, Owen Campbell-Moore wrote: >> I think it mig

Re: Push API change for permissions UX

2014-10-25 Thread Jonas Sicking
On Fri, Oct 24, 2014 at 9:39 AM, Owen Campbell-Moore wrote: >> 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". > > I hope the above explains why we believe that while some sites may want to >

Re: Push API change for permissions UX

2014-10-25 Thread Owen Campbell-Moore
Hi All - my name is Owen and I recently joined the Chrome team. Taking a step back, we believe users have control such that they can permit a site to send them notifications (or notify them of an event using other UI) without permitting it to run arbitrarily in the background without their knowled

Re: Push API change for permissions UX

2014-10-24 Thread Martin Thomson
On 24 October 2014 09:09, John Mellor wrote: > For background sync[1], such a throttling approach would be ideal, as there > is no expectation of timeliness. But push is different: users can come to > depend on timely delivery of push notifications, and sufficiently > heavy-handed throttling would

Re: Push API change for permissions UX

2014-10-24 Thread John Mellor
On 23 October 2014 23:29, Martin Thomson wrote: > It means that important features that provide > these measures (do not disturb, more contextual event filtering) are > not available to applications by default. > System-wide do-not-disturb would still work (for example in Android Lollipop

Re: Push API change for permissions UX

2014-10-23 Thread Martin Thomson
On 23 October 2014 04:10, John Mellor wrote: > Can you elaborate? This would attach no penalty to developers who don't opt > in (at the one time cost of an additional permission prompt); and as I > explained above, developers who do opt in would indeed be incentivized to > always show user-visible

Re: Push API change for permissions UX

2014-10-23 Thread John Mellor
On 22 October 2014 20:55, Jonas Sicking wrote: > 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 means the user is aware of incoming pushes, which alleviates two concerns: 1. Geoip t

Re: Push API change for permissions UX

2014-10-22 Thread Martin Thomson
On 22 October 2014 11:02, John Mellor wrote: > a restricted form of push where each push event fired on the SW must trigger > user-visible UI. How would that work? Is the idea that there would be a default notification that the SW could alter the contents of (perhaps), but not prevent or indefini

Re: Push API change for permissions UX

2014-10-22 Thread Jonas Sicking
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