Re: [whatwg] Notifications: reviving Notification objects
On Sat, May 10, 2014 at 12:00 AM, Edward O'Connor eocon...@apple.com wrote:
Anne wrote, last year:
A) User navigates to chat site. Chat site creates a notification
from a chat with P while the user does something else. User closes
chat site and then navigates to chat site at a later point.
On OS X, when the user closes the chat site in Safari, its notifications
are removed from Notification Center.
What if you navigate same-origin? Notifications are origin-bound per
the specification.
The idea to address A is:
Notification.get({tag})
which returns a Promise which is fulfilled with an array of
Notification objects for which tag is tag or all Notification objects
if no tag is defined.
OK. On platforms which do not persist notifications beyond the lifetime
of the originator, the Promise returned from Notification.getClones()
can always resolve immediately with an Array of length 0.
No, if you have two tabs open that would not return an empty array. Or
if you have a worker open, etc.
--
http://annevankesteren.nl/
Re: [whatwg] Notifications: reviving Notification objects
Hi,
Anne wrote, last year:
There are a couple of scenarios
http://notifications.spec.whatwg.org/ does not address at the
moment.
A) User navigates to chat site. Chat site creates a notification
from a chat with P while the user does something else. User closes
chat site and then navigates to chat site at a later point.
On OS X, when the user closes the chat site in Safari, its notifications
are removed from Notification Center.
B) Instead of navigating to the chat site at a later point, the user
opens the notification center and clicks the notification.
This scenario doesn't arise on OS X for the above reason.
C) User navigates to chat site at a later point, but with a view
that does not show the chat with P. User then opens the notification
center and clicks the notification.
Same here.
A requires being able to get the notifications associated with a
certain site.
Only on platforms where notifications persist beyond the lifetime of the
originator.
The idea to address A is:
Notification.get({tag})
which returns a Promise which is fulfilled with an array of
Notification objects for which tag is tag or all Notification objects
if no tag is defined.
OK. On platforms which do not persist notifications beyond the lifetime
of the originator, the Promise returned from Notification.getClones()
can always resolve immediately with an Array of length 0.
WFM.
Ted
Re: [whatwg] Notifications: reviving Notification objects
On Tue, Jul 9, 2013 at 8:32 AM, Anne van Kesteren ann...@annevk.nl wrote:
A requires being able to get the notifications associated with a
certain site. That can also be useful in case multiple windows are
open of the same site and can help workers and pages coordinate once
we enable notifications in workers.
The idea to address A is:
Notification.get({tag})
which returns a Promise which is fulfilled with an array of
Notification objects for which tag is tag or all Notification objects
if no tag is defined. The objects are origin-scoped. The reason a
promise is used is because getting notifications may be a
cross-process operation.
I've added this. The idea for notifying other globals that you created
a notification is to let developers communicate that themselves via
this proposed API:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22628
--
http://annevankesteren.nl/
Re: [whatwg] Notifications: reviving Notification objects
On Sun, Mar 31, 2013 at 10:33 AM, Anne van Kesteren ann...@annevk.nl wrote:
There are a couple of scenarios http://notifications.spec.whatwg.org/
does not address at the moment.
A) User navigates to chat site. Chat site creates a notification from
a chat with P while the user does something else. User closes chat
site and then navigates to chat site at a later point.
B) Instead of navigating to the chat site at a later point, the user
opens the notification center and clicks the notification.
C) User navigates to chat site at a later point, but with a view that
does not show the chat with P. User then opens the notification center
and clicks the notification.
B and C both require some deeper architectural changes. Some kind of
event page/worker that can be notified as we've been discussing. Once
that is in place we can address those use cases.
A requires being able to get the notifications associated with a
certain site. That can also be useful in case multiple windows are
open of the same site and can help workers and pages coordinate once
we enable notifications in workers.
The idea to address A is:
Notification.get({tag})
which returns a Promise which is fulfilled with an array of
Notification objects for which tag is tag or all Notification objects
if no tag is defined. The objects are origin-scoped. The reason a
promise is used is because getting notifications may be a
cross-process operation.
--
http://annevankesteren.nl/
Re: [whatwg] Notifications: reviving Notification objects
On Sun, Mar 31, 2013 at 7:33 AM, Anne van Kesteren ann...@annevk.nl wrote: 2) Define a method on Navigator, getNotifications(), that returns a Future which is resolved with an array of Notification objects. Once the Future is resolved, a task is queued to fire a click event on the appropriate Notification object in case of B) and C). I guess if we're getting system messages (as suggested on public-script-coord), that could also be used here and less likely to create timing issues. There are some further gotchas here. One is how Notifications objects should be scoped (and thus what exactly getNotifications()'s Future is resolved with). Origin-scoped would be extremely convenient, but it seems we still have efforts that support further scoping for applications based on the URL path. I think we should go with origin-scoped until documents get some way to associate themselves with an app concept. Maybe the manifest idea that is floating around? The other is how much we need to expose on the Navigation object itself so sites can identify it after reviving it. Currently almost nothing is exposed, but maybe we should simply expose dir/lang/title/body/tag/icon on it. Opinions? -- http://annevankesteren.nl/
Re: [whatwg] Notifications: reviving Notification objects
On Apr 4, 2013 12:53 PM, Mounir Lamouri mou...@lamouri.fr wrote: On 31/03/13 15:33, Anne van Kesteren wrote: There are a couple of scenarios http://notifications.spec.whatwg.org/ does not address at the moment. A) User navigates to chat site. Chat site creates a notification from a chat with P while the user does something else. User closes chat site and then navigates to chat site at a later point. I guess a better example would be that the website is unloaded on memory pressure but the tab is kept. Otherwise, an explicit user action could be considered as enough to remove all currently opened notifications. I don't think that we want to impose the requirement that UAs have to close all notifications when the user closes the webpage that opened them. Or that UAs have to do that in order to not have dangling notifications. It seems like a reasonable UI to leave notifications opened once the user has granted explicit permission for a website to create notifications, as is the case any time they use the notifications API. / Jonas
Re: [whatwg] Notifications: reviving Notification objects
On 31/03/13 15:33, Anne van Kesteren wrote: There are a couple of scenarios http://notifications.spec.whatwg.org/ does not address at the moment. A) User navigates to chat site. Chat site creates a notification from a chat with P while the user does something else. User closes chat site and then navigates to chat site at a later point. I guess a better example would be that the website is unloaded on memory pressure but the tab is kept. Otherwise, an explicit user action could be considered as enough to remove all currently opened notifications. 1) Tie the document's address of when a Notification is created to the Notification object to address B) and C). Maybe at some point allow sites to define a URL to open. What if I have to instance of the same website open? what if those two instances have different contexts like not logged in with the same user? 2) Define a method on Navigator, getNotifications(), that returns a Future which is resolved with an array of Notification objects. Once the Future is resolved, a task is queued to fire a click event on the appropriate Notification object in case of B) and C). This magic behaviour with the click event is a bit weird. Does that mean that the UA shouldn't do anything with the notification? What if the website never calls getNotifications()? We could expect the UA to close the notification by default when the website is re-opened but if it has to wait for a possible .getNotifications() call, what should be done? Timing out seems a bit racy. -- Mounir
