[whatwg] Notifications: usage feedback

Anne van Kesteren annevk at annevk.nl
Mon Oct 14 07:09:58 PDT 2013


On Fri, Sep 27, 2013 at 2:15 AM, James Burke <jrburke at gmail.com> wrote:
> 1) Ability to pass data with the Notification
>
> Right now, we URL-encode some args to the iconURL to pass data to the
> handler function that is registered via
> navigator.mozSetMessageHandler('notification', function(){}) [1].
>
> It would be better if I could just pass a JSON-friendly data object to
> Notification instance and then have access to that data in the
> notification callbacks that are triggered.
>
> We cannot depend on notification.onclick to work since the app can be
> closed after the notification is fired. It also seemed very unreliable
> to depend on it, given garbage collection possibilities. So we cannot
> reliably capture state using a function closure.

I pointed this out in:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Aug/0337.html

It seems using a structured clone makes the most sense. Transfering
objects won't work here. It's not entirely clear to me what the best
is for Blob, File, etc. Effectively the page can shut down, but they
will still be kept alive through this Notification. I guess it's not
too different from what Indexed DB can do.

Is what what we want?

My proposal would be to add a data member to NotificationsOptions and
a data property to Notification objects. The constructor does a
structured clone so that the data property returns a fresh object and
its established the object can indeed be cloned. I guess we'd also
have to keep a copy alive somewhere in case we need to create a new
instance of the Notification object (e.g. when Notification.get() is
used).

Making this non-observable in a world where structured cloning might
become extensible seems tricky.


-- 
http://annevankesteren.nl/


More information about the whatwg mailing list