Re: [webkit-dev] Can we remove Notification.show()?
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 master, though I am implementing web notifications support in the GTK+ port so I'm probably overlooking something in there, my bad. > What's the status of this? Apparently it is still necessary to > call Notification.show() after a notification is created. Are > you tracking this in a bug report? Just noticed https://bugs.webkit.org/show_bug.cgi?id=108066 . Claudio ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Can we remove Notification.show()?
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 displayed a notification, so it doesn't seem
like show() is necessary in more recent versions of WebKit.
On Thu, Feb 7, 2013 at 1:51 PM, Claudio Saavedra wrote:
> 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 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?
>
> What's the status of this? Apparently it is still necessary to call
> Notification.show() after a notification is created. Are you tracking
> this in a bug report?
>
> Claudio
>
> ___
> 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
Re: [webkit-dev] Can we remove Notification.show()?
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 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? What's the status of this? Apparently it is still necessary to call Notification.show() after a notification is created. Are you tracking this in a bug report? Claudio ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Can we remove Notification.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::constructorForTypeSlowCase. -- erik ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Can we remove Notification.show()?
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() 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 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 >> >> > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Can we remove Notification.show()?
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 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. > > 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 > > -jochen > > >> >> >> On Mon, Jan 28, 2013 at 4: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 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 > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Can we remove Notification.show()?
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... -jochen > > > On Mon, Jan 28, 2013 at 4: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 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
Re: [webkit-dev] Can we remove Notification.show()?
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 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
Re: [webkit-dev] Can we remove Notification.show()?
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, 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)? > > > I expect most people look for tutorials on the web, or read the spec, > rather than feel their way through a new API by inspecting the JS object. I > also believe there are hardly any cases of people using the old API with > the new Notification object. Once the evangelism sites have updated their > code samples, it should clarify any confusion. > Yeah, that probably makes sense. I guess the only concern would be future unexpected interactions between the new Notifications code and the (unintentionally) exposed APIs (ala the issue addressed by r140927). But looking at the interface I don't really see anything that seems particularly troublesome. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Can we remove Notification.show()?
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 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? Sounds good. > 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)? I expect most people look for tutorials on the web, or read the spec, rather than feel their way through a new API by inspecting the JS object. I also believe there are hardly any cases of people using the old API with the new Notification object. Once the evangelism sites have updated their code samples, it should clarify any confusion. Jon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Can we remove Notification.show()?
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
