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
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
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
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 --
On Jan 28, 2013, at 1: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
On Mon, Jan 28, 2013 at 11:53 AM, Jon Lee jon...@apple.com 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
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 atwil...@google.com wrote:
So, we've recently landed some fixes to
On Mon, Jan 28, 2013 at 11:19 PM, Elliott Sprehn espr...@chromium.orgwrote:
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
On Mon, Jan 28, 2013 at 2:24 PM, Jochen Eisinger joc...@chromium.orgwrote:
On Mon, Jan 28, 2013 at 11:19 PM, Elliott Sprehn espr...@chromium.orgwrote:
This seems like a badly designed API, constructors shouldn't have side
effects and not having show() means after calling close() the
On Mon, Jan 28, 2013 at 11:33 PM, John Gregg john...@google.com wrote:
On Mon, Jan 28, 2013 at 2:24 PM, Jochen Eisinger joc...@chromium.orgwrote:
On Mon, Jan 28, 2013 at 11:19 PM, Elliott Sprehn espr...@chromium.orgwrote:
This seems like a badly designed API, constructors shouldn't
On Mon, Jan 28, 2013 at 5:41 PM, Jochen Eisinger joc...@chromium.org 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
11 matches
Mail list logo
