Re: [whatwg] Notification's click event should be cancelable
On 08/26/2014 12:53 PM, Jonas Sicking wrote: On Tue, Aug 26, 2014 at 2:18 AM, Anne van Kesteren wrote: On Tue, Aug 26, 2014 at 11:06 AM, Jonas Sicking wrote: I don't see a problem with firing events on all Notification instances, and only changing focus if none of the events were cancelled. It's a somewhat complex design compared to what we probably need long term, if long term is service workers. I'm not convinced that even with SW, the proper design is to tell websites to always funnel click notifications through a SW. Alternatively we don't use events here at all. Instead we could use a .clicked property which returns a promise. This is a typical "one shot" notification where Promises are better suited than DOM Events. Unless you want the cancellability. However I don't actually think that firing events on multiple EventTargets is that complex. It can be complex if we have several processes firing those events. Some process might be really slow and the parent process would need to wait for all the child processes to reply before doing some default handling (like focus the initiator tab). -Olli / Jonas
Re: [whatwg] Notification's click event should be cancelable
On Tue, Aug 26, 2014 at 11:53 AM, Jonas Sicking wrote: > On Tue, Aug 26, 2014 at 2:18 AM, Anne van Kesteren wrote: >> It's a somewhat complex design compared to what we probably need long >> term, if long term is service workers. > > I'm not convinced that even with SW, the proper design is to tell > websites to always funnel click notifications through a SW. That's the standing proposal. Do you think we should fire them both in service workers and on Notification objects? > Alternatively we don't use events here at all. Instead we could use a > .clicked property which returns a promise. This is a typical "one > shot" notification where Promises are better suited than DOM Events. Seems somewhat sensible. Same for closed, error, etc? Not sure how we'd reconcile that with the existing design. > However I don't actually think that firing events on multiple > EventTargets is that complex. -- http://annevankesteren.nl/
Re: [whatwg] Notification's click event should be cancelable
On Tue, Aug 26, 2014 at 2:18 AM, Anne van Kesteren wrote: > On Tue, Aug 26, 2014 at 11:06 AM, Jonas Sicking wrote: >> I don't see a problem with firing events on all Notification >> instances, and only changing focus if none of the events were >> cancelled. > > It's a somewhat complex design compared to what we probably need long > term, if long term is service workers. I'm not convinced that even with SW, the proper design is to tell websites to always funnel click notifications through a SW. Alternatively we don't use events here at all. Instead we could use a .clicked property which returns a promise. This is a typical "one shot" notification where Promises are better suited than DOM Events. However I don't actually think that firing events on multiple EventTargets is that complex. / Jonas
Re: [whatwg] Notification's click event should be cancelable
On Tue, Aug 26, 2014 at 11:06 AM, Jonas Sicking wrote: > I don't see a problem with firing events on all Notification > instances, and only changing focus if none of the events were > cancelled. It's a somewhat complex design compared to what we probably need long term, if long term is service workers. >> We could >> make a division between notification records and notification objects. >> And we could even go as far as only offer notification records for >> notifications associated with a service worker. > > I don't really understand this. The proposal for service workers is that all events go to the service worker and not to the notification. As such I thought we could maybe make a distinction between notifications associated with a service worker and without one. For those notifications asssociated with a service worker, all we need to expose from the notification is a record of its various properties, but that does not need to support event handling. For notifications without a service worker (the model we have cross-browser today) we could continue to support it as an event target, but perhaps not support the whole multiple Notification objects per notification model as at that point you should probably start using service workers anyway. -- http://annevankesteren.nl/
Re: [whatwg] Notification's click event should be cancelable
On Tue, Aug 26, 2014 at 12:15 AM, Anne van Kesteren wrote: > On Mon, Aug 25, 2014 at 6:42 PM, Jonas Sicking wrote: >> I definitely think we need the ability for code running in Windows >> (i.e. code that handles UI) to be able to enumerate any notifications >> created by the website. > > Fair, but maybe those "copy objects" should not get events. I don't see a problem with firing events on all Notification instances, and only changing focus if none of the events were cancelled. After all, we do something very similar when firing events on a Node. Then too multiple EventTargets have their event handlers called, and only if none of the event handlers, on any of the EventTargets, cancel the event do we take the default action. Granted, in those cases we use the same Event instance, and it's part of a single event dispatch. But that difference is pretty small from the webpage point of view. The main difference is that .defaultPrevented reflect cancellation, but worst come to worst we could make that work here too. > We could > make a division between notification records and notification objects. > And we could even go as far as only offer notification records for > notifications associated with a service worker. I don't really understand this. / Jonas
Re: [whatwg] Notification's click event should be cancelable
On Mon, Aug 25, 2014 at 6:42 PM, Jonas Sicking wrote: > I definitely think we need the ability for code running in Windows > (i.e. code that handles UI) to be able to enumerate any notifications > created by the website. Fair, but maybe those "copy objects" should not get events. We could make a division between notification records and notification objects. And we could even go as far as only offer notification records for notifications associated with a service worker. So you have notifications that work per today and are only exposed to Window. And then you have notifications associated with a service worker. For the latter the events will go towards the service worker and everyone (same-origin) can get a hold of a notification record for them using Notification.get(). From a service worker, new Notification() will do the right thing, from anywhere else you need to associate it with one explicitly. (It could be even better if we had mixins, then only notification objects not associated with a service worker would have the event stuff. There's no need for that for notifications associated with a service worker or notification records.) -- http://annevankesteren.nl/
Re: [whatwg] Notification's click event should be cancelable
On Mon, Aug 25, 2014 at 1:29 AM, Anne van Kesteren wrote: > On Sun, Aug 24, 2014 at 11:18 AM, Olli Pettay wrote: >> Given the very odd Notification API, where the same user input may end up >> being >> represented by several click events in the browser... >> (I think we need to change that somehow, if possible) >> ...cancelling any of the events should cancel the default action. > > We could also make it so that each notification has exactly one > Notification object. And only service workers get a Notification.get() > API and multiple objects per notification, with the tradeoff that > those objects are not event targets as the events go to the service > worker directly. That might simplify things a bit. I definitely think we need the ability for code running in Windows (i.e. code that handles UI) to be able to enumerate any notifications created by the website. / Jonas
Re: [whatwg] Notification's click event should be cancelable
On Sun, Aug 24, 2014 at 11:18 AM, Olli Pettay wrote: > Given the very odd Notification API, where the same user input may end up > being > represented by several click events in the browser... > (I think we need to change that somehow, if possible) > ...cancelling any of the events should cancel the default action. We could also make it so that each notification has exactly one Notification object. And only service workers get a Notification.get() API and multiple objects per notification, with the tradeoff that those objects are not event targets as the events go to the service worker directly. That might simplify things a bit. -- http://annevankesteren.nl/
Re: [whatwg] Notification's click event should be cancelable
On 08/24/2014 09:53 AM, Anne van Kesteren wrote: On Fri, Aug 15, 2014 at 2:38 PM, Olli Pettay wrote: in order to prevent whatever default action Notification's click event has (for example focus the tab which initiated the Notification), the click event should be cancelable so that .preventDefault() can be called. Some background https://bugzilla.mozilla.org/show_bug.cgi?id=874050&mark=25-26#c25 https://bugzilla.mozilla.org/show_bug.cgi?id=1009190#c0 Given that a single notification can be represented by many Notification objects, what kind of semantics are you expecting? A single listener setting the canceled flag causing any action to not be done? Given the very odd Notification API, where the same user input may end up being represented by several click events in the browser... (I think we need to change that somehow, if possible) ...cancelling any of the events should cancel the default action. -Olli
Re: [whatwg] Notification's click event should be cancelable
On Fri, Aug 15, 2014 at 2:38 PM, Olli Pettay wrote: > in order to prevent whatever default action Notification's click event has > (for example focus the tab which initiated the Notification), the click > event > should be cancelable so that .preventDefault() can be called. > > Some background > https://bugzilla.mozilla.org/show_bug.cgi?id=874050&mark=25-26#c25 > https://bugzilla.mozilla.org/show_bug.cgi?id=1009190#c0 Given that a single notification can be represented by many Notification objects, what kind of semantics are you expecting? A single listener setting the canceled flag causing any action to not be done? -- http://annevankesteren.nl/
