This seems like a badly designed API, constructors shouldn't have side effects and not having show() means after calling close() the notification object is useless which is silly.
On Mon, Jan 28, 2013 at 4:35 AM, Andrew Wilson <[email protected]> wrote: > So, we've recently landed some fixes to address permissions handling for > Notification.show(): http://trac.webkit.org/changeset/140927 > > Turns out, the notifications specification does not have a show() API (the > notification is automatically shown from the constructor -- > http://notifications.spec.whatwg.org/#api). Does anyone have any > objections to moving the show() API under the ENABLE_LEGACY_NOTIFICATIONS > flag to bring us under compliance with the spec? > > Also, it looks like if a platform enables ENABLE_LEGACY_NOTIFICATIONs, not > only do they get support for the old webkitNotifications API, but also some > of the old API (like show() and cancel()) is exposed on the new > Notifications objects, because we share the same interface for > webkitNotifications and Notifications. Do we care (will this make it harder > to eventually turn off ENABLE_LEGACY_NOTIFICATIONS since web apps may start > using those APIs on the new Notifications objects)? > > -atw > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo/webkit-dev > >
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
