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.wha
On Jan 28, 2013, at 1:35 AM, Andrew Wilson 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 automati
On Mon, Jan 28, 2013 at 11:53 AM, Jon Lee wrote:
> 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, be
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 wrote:
> So, we've recently landed some fixes to address permissions
On Mon, Jan 28, 2013 at 11:19 PM, Elliott Sprehn 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...
-j
On Mon, Jan 28, 2013 at 2:24 PM, Jochen Eisinger wrote:
>
>
> On Mon, Jan 28, 2013 at 11:19 PM, Elliott Sprehn 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
On Mon, Jan 28, 2013 at 11:33 PM, John Gregg wrote:
>
>
>
>
>
> On Mon, Jan 28, 2013 at 2:24 PM, Jochen Eisinger wrote:
>
>>
>>
>> On Mon, Jan 28, 2013 at 11:19 PM, Elliott Sprehn wrote:
>>
>>> This seems like a badly designed API, constructors shouldn't have side
>>> effects and not having show(
On Mon, Jan 28, 2013 at 5:41 PM, Jochen Eisinger wrote:
> A side-effect of that decision is that "permission" is a static attribute,
> which we can't currently implement in V8 :-/
Not entirely true. We cannot use FunctionTemplate to do this but we
can add the V8 accessor in
V8PerContextData::cons
On Mon, 2013-01-28 at 10:35 +0100, Andrew Wilson 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 automati
It should definitely not be necessary to call Notification.show(), although
I have not removed that API since I am busy with some other tasks
currently. What browser/WebKit revision are you using?
In Chrome 26, I just opened the javascript console and typed "new
Notification('blah')" and it displa
On Thu, 2013-02-07 at 13:55 +0100, Andrew Wilson wrote:
> It should definitely not be necessary to call Notification.show(),
> although I have not removed that API since I am busy with some other
> tasks currently. What browser/WebKit revision are you using?
You're right. It's a fairly recent mast
11 matches
Mail list logo
