On Mon, Jan 28, 2013 at 11:19 PM, Elliott Sprehn <espr...@chromium.org>wrote:
> 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. > In the new API, there's also no close() method... -jochen > > > On Mon, Jan 28, 2013 at 4:35 AM, Andrew Wilson <atwil...@google.com>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 >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo/webkit-dev >> >> > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev