[whatwg] Notifications: usage feedback

[Jonas Sicking]

On Tue, Oct 29, 2013 at 8:26 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
> On Fri, Sep 27, 2013 at 2:15 AM, James Burke <jrburke at gmail.com> wrote:
>> 2) General notification callback entry point
>>
>> We are avoiding use of notification.onclick/onclose and would prefer
>> to have a generic entry point to receive notification events. Right
>> now we use navigator.mozSetMessageHandler('notification',
>> function(){}).
>>
>> but I would prefer to see a more official entry point in the spec. I
>> would go so far as to want to deprecate the .onclick and .onclose as
>> in practice they are not reliable, given that the app may be closed
>> down after firing the Notification but before it is clicked.
>
> We currently do not have a way to have events out-of-band for the web.

We should integrate this with ServiceWorker. Though I agree it might
be early to do that still.

>> 3) onclick fires onclose too?
>>
>> It seemed a bit unclear in the spec, but right now FirefoxOS fires
>> onclose too for onclick actions, as the onclick pathway removes the
>> notification from the list of notifications.
>>
>> This seems counterintuitive to me, I would have only expected one
>> event. Perhaps clarifying the onclick behavior would be good.
>>
>> I would prefer to just see one event fired in this case, if
>> onclick/onclose are kept around. If the general notification callback
>> entry point is established, then just firing it once with the
>> event.clicked property set to true for the clicked route.
>
> That seems like an implementation detail. Activation could mean
> dismissal, but e.g. on Mac OS X activation does not mean dismissal.
> It's up to the site/app to dismiss after activation and sometimes they
> decide to keep the notification around for a bit.

That sounds unlikely to work in practice. I.e. I would expect pages to
break if some implementations fire onclose and others do not. Is there
a reason not to forbid firing onclose if onclick has been fired. Keep
in mind that the implementation can always hide the notification or
not independently of if it has fired onclose or not.

>> 4) onclick does not bring web app to front
>>
>> This may be part of just further defining the steps for the "click"
>> pathway in the spec, but at least in FirefoxOS right now, the
>> notification onclick pathway does not bring the app to the visible
>> front in all cases. The email app has to do some extra document.hidden
>> checking and try to bring itself to the front.
>
> That seems like a UI detail we cannot really say anything about in the
> specification.

Again, this seems unlikely to work in practice. I.e. I would expect
that authors would expect one behavior (likely the behavior of
whatever platform they are developing on) and that things would break
when the website is used on platforms that has the other behavior.

I suspect allowing the author to choose behavior here is going to work
more reliably.

/ Jonas