[webkit-dev] Can we remove Notification.show()?

[Jochen Eisinger]

On Mon, Jan 28, 2013 at 11:33 PM, John Gregg <johnnyg at google.com> wrote:

>
>
>
>
>
> On Mon, Jan 28, 2013 at 2:24 PM, Jochen Eisinger <jochen at chromium.org>wrote:
>
>>
>>
>> On Mon, Jan 28, 2013 at 11:19 PM, Elliott Sprehn <esprehn at 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.
>>>
>>
> There was a discussion a while ago which resulted in removing the show
> method and making show implicit in construction.
> http://lists.w3.org/Archives/Public/public-web-notification/2011Jun/0005.html.
>  The reasoning was that there typically isn't much value in reusing a
> notification.
>

A side-effect of that decision is that "permission" is a static attribute,
which we can't currently implement in V8 :-/

Instead, you'll need to use new Notification().permission in Chrome. Since
that API is unfortunately already part of the stable chrome release website
authors started to use this syntax which will inevitably lead to breakage
when we fix the implementation.



>
>
>>
>> In the new API, there's also no close() method...
>>
>
> There is still a close() method in the latest spec:
> http://notifications.spec.whatwg.org/#api
>

ah, true.. my fault. Sorry.


>
>
>>
>> -jochen
>>
>>
>>>
>>>
>>> On Mon, Jan 28, 2013 at 4:35 AM, Andrew Wilson <atwilson at 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 at lists.webkit.org
>>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130128/4d726b2b/attachment.html>