Re: Removal of native notification systems on desktop platforms
OK, i have looked into this and found some connections. Specifically, all major OSs seem to have APIs providing the following: 1. download progress 2. native notifications. As older versions don't have those, and linux systems are pretty modular in any case, i propose that we use no fallback for download progress (the download button has a progress bar in any case), and we use XUL notifications as fallback for native notifications. the available implementations can be seen here (APIs are linked, so click on a node to get to the docs): https://cdn.mediacru.sh/ITsCgwM5JrUS.svg it seems that if we opt not to support growl on older macs or growl4windows or snarl on windows, the requirements to get everything are: OSX 10.9 or windows 8.0 or linux with KDE/unity (as there's no download progress API in GNOME 3). -- since the opinions seems to be against linking all kinds of libraries on linux, we'd need to create the following: 1. a service for DBUS. let's call it nsIDBUSService 2. a wrapper of the DBUS notification API using nsIDBUSService 3. a wrapper of the DBUS unity launcher API using nsIDBUSService 4. a wrapper of the KJob API using nsIDBUSService (if possible) 5. for each one of download progress and notifications: a switching mechanism that decides at compile time which native API to use (DBUS, Windows, or OSX), and at runtime if the API is available (respective DBUS service running? right version of Windows/OSX?) until then, we can just reactivate libnotify support like ubuntu does: https://bugzilla.mozilla.org/show_bug.cgi?id=853104#c18 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removal of native notification systems on desktop platforms
On Monday, October 28, 2013 6:38:07 AM UTC-5, Philip Chee wrote: On 28/10/2013 16:02, Florian Bender [:fbender] wrote: Mac OS X Mavericks has been released with improvements to NC. Safari uses NC to display Web/PushNotifications and seems to work quite well. I'd like you to revisit the decision to drop NC in favor of XUL Notifications, and have a second look at the new API and Nitpick. NC wasn't dropped. We never supported the OS X NC at all. There was some preliminary work but that was never checked-in to mozilla-central. capabilities. NC support could be limited to 10.9 to reduce maintenance cost (luckily, nearly everyone is eligible for the free update which means that earlier versions could fade into irrelevance sooner than later), and keep the XUL Notifications for 10.6-10.8 (as long as these versions are supported and have a meaningful market share). I believe that this is one of those patches welcome occasions. This is what I do not understand. If the Growl framework had simply been updated instead of removed, then you would have been able to support 10.6 - 10.9 without any more maintenance than updating the framework. There are references to why the framework was removed, but nothing specific. Now I have end users coming to us confused as to why Firefox and plugins for FF, along with Thunderbird are all not notifying through Growl. Which is really frustrating because I cannot for the life of me figure out from all of the tickets why exactly Growl support was removed. I asked on a bug but apparently that was the wrong place to ask, so I'll ask on this thread which was linked. I'll copy what i wrote over there: I would also like to find out why Growl was removed. We're getting user complaints because users don't understand why their firefox plugins are not notifying through Growl anymore. I'd like to explain it better than because someone at Mozilla arbitrarily decided to remove it instead of talking to us about what features they needed. Which so far is exactly how it looks. I just need a simple 1-3 sentence explanation that I can send to my end users as to why a feature they depended upon is no longer present. I would also like a much more technical explanation as to why Growl support was removed because obviously we'd like to address those kinds of issues going forward. What I do not understand is that the feature for this was developed in our repository. The framework was paired down to work with the very stringent requirements that Mozilla has in order to get Growl support to work. The framework we provide now supports native notifications on 10.8 and 10.9. On 10.6 and 10.7 there are no native notifications so Growl is the only game in town, but you do not need Growl in your application, just the framework, in order to fire a notification to the end user. We could have made the adjustments to our notification framework to give not only Mozilla what they wanted, but also provide those changes to the entire mac community that uses our framework. So if someone explains exactly what the problem is, we'd be happy to look at addressing those things. Hopefully you can see why this is frustrating to me, and more importantly to our mutual end users who are the ones who are affected by this (currently) seemingly arbitrary change. Chris Forsythe Project Lead - The Growl Project ch...@growl.info Phil -- Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removal of native notification systems on desktop platforms
Not mapping Web Notifications to native notifications seems very unfortunate, since it means Web apps can't use Web Notifications to get a native experience. Is there a summary of what exactly prevents the use of native notifications and why we shouldn't change the spec so that it can be mapped to native notifications? -- Henri Sivonen hsivo...@hsivonen.fi http://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removal of native notification systems on desktop platforms
Nothing. Just time. Patches accepted. On Oct 29, 2013, at 6:26 AM, Henri Sivonen hsivo...@hsivonen.fi wrote: Not mapping Web Notifications to native notifications seems very unfortunate, since it means Web apps can't use Web Notifications to get a native experience. Is there a summary of what exactly prevents the use of native notifications and why we shouldn't change the spec so that it can be mapped to native notifications? -- Henri Sivonen hsivo...@hsivonen.fi http://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removal of native notification systems on desktop platforms
On Oct 29, 2013, at 12:23 PM, Doug Turner doug.tur...@gmail.com wrote: Nothing. Just time. Patches accepted. Not really? Last time I looked into this one of the problems was that AlertsService exposes an alertfinished event (for when the notification goes away) that we can’t implement when using NC, since NC notifications go to the Notification Center when the user doesn't interact with them. That means we can’t implement alertclickcallback consistently either – alertclickcallback needs to fire before alertfinished. I don't know if 10.9 exposes a new API to detect when a notification was removed from the notification center. -- reuben smime.p7s Description: S/MIME cryptographic signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removal of native notification systems on desktop platforms
Mac OS X Mavericks has been released with improvements to NC. Safari uses NC to display Web/PushNotifications and seems to work quite well. I'd like you to revisit the decision to drop NC in favor of XUL Notifications, and have a second look at the new API and capabilities. NC support could be limited to 10.9 to reduce maintenance cost (luckily, nearly everyone is eligible for the free update which means that earlier versions could fade into irrelevance sooner than later), and keep the XUL Notifications for 10.6-10.8 (as long as these versions are supported and have a meaningful market share). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removal of native notification systems on desktop platforms
On 28/10/2013 16:02, Florian Bender [:fbender] wrote: Mac OS X Mavericks has been released with improvements to NC. Safari uses NC to display Web/PushNotifications and seems to work quite well. I'd like you to revisit the decision to drop NC in favor of XUL Notifications, and have a second look at the new API and Nitpick. NC wasn't dropped. We never supported the OS X NC at all. There was some preliminary work but that was never checked-in to mozilla-central. capabilities. NC support could be limited to 10.9 to reduce maintenance cost (luckily, nearly everyone is eligible for the free update which means that earlier versions could fade into irrelevance sooner than later), and keep the XUL Notifications for 10.6-10.8 (as long as these versions are supported and have a meaningful market share). I believe that this is one of those patches welcome occasions. Phil -- Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removal of native notification systems on desktop platforms
On 10/12/2013 5:50 AM, Philip Chee wrote: Um, what? libnotify was removed because the developer was too lazy to google for the docs? Phil, you've been in the community long enough to know that this isn't appropriate participation. Insulting other contributors like this is not acceptable and won't be tolerated. - A ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removal of native notification systems on desktop platforms
On 2013-10-12 12:39:37 +, Philip Chee said: There was no support for Mac native notifications. Mostly because there were no notifications native to the Mac (The OS X notification centre didn't exist then). But they added Notification Center support pretty recently. It makes things much better; removing it doesn't make much sense to me. -- Eric Shepherd Developer Documentation Lead Mozilla Blog: http://www.bitstampede.com/ Twitter: @sheppy ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removal of native notification systems on desktop platforms
On 09/10/2013 05:48, Marco wrote: In bug 782211, native notification systems support was removed. A lot of bugs have been filed to restore support for libnotify and Mac native There was no support for Mac native notifications. Mostly because there were no notifications native to the Mac (The OS X notification centre didn't exist then). notifications, because XUL notifications don't behave correctly on those systems (multi-monitor support is broken, etc.). Phil -- Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removal of native notification systems on desktop platforms
On 09/10/2013 09:14, Marco wrote: It's not entirely clear to me why libnotify support was removed, the author of the patch stated: I removed Growl support because it does not support features needed to implement the spec. I also removed libnotify support because I can't find documentation about all the capabilities, so it's possible that libnotify could work but I just can't find it in the documentation. Um, what? libnotify was removed because the developer was too lazy to google for the docs? Doesn't libnotify have a forum or mailing list? Couldn't he/she/it have asked there? Phil -- Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removal of native notification systems on desktop platforms
On Oct 12, 2013, at 2:50 PM, Philip Chee philip.c...@gmail.com wrote:
On 09/10/2013 09:14, Marco wrote:
It's not entirely clear to me why libnotify support was removed, the
author of the patch stated:
I removed Growl support because it does not support features needed to
implement the spec. I also removed libnotify support because I can't
find documentation about all the capabilities, so it's possible that
libnotify could work but I just can't find it in the documentation.
Um, what? libnotify was removed because the developer was too lazy to
google for the docs? Doesn't libnotify have a forum or mailing list?
Couldn't he/she/it have asked there?
Uhm, with my not-so-awesome-but-usually-sufficient Google skills I found the
docs[1] within five minutes. I don't know since when these docs are available,
though.
While reading through these docs, also the ones from Apple[2], I don't see
incompatibilities with the spec[3] that can not be dealt with with a unified
implementation ('tags' would have to be implemented at a higher level, for
example).
As this functionality was apparently needed for FirefoxOS certification[4], I
can see and understand why this was rushed to the tree. However, I hope that
William Chen has the time now to work on the follow-ups that need to happen
(insert IMHO if needed).
I hope we are able to fix these regressions soon!
Best,
Mike.
[1] https://developer.gnome.org/libnotify/0.7/
[2]
https://developer.apple.com/library/mac/documentation/Foundation/Reference/NSUserNotification_Class/Reference/Reference.html
and
https://developer.apple.com/library/mac/documentation/Foundation/Reference/NSUserNotificationCenter_Class/Reference/Reference.html
[3] http://notifications.spec.whatwg.org
Phil
--
Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
smime.p7s
Description: S/MIME cryptographic signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Removal of native notification systems on desktop platforms
In bug 782211, native notification systems support was removed. A lot of bugs have been filed to restore support for libnotify and Mac native notifications, because XUL notifications don't behave correctly on those systems (multi-monitor support is broken, etc.). The patch to remove this support was reviewed, but the reviewer said to ask to the dev-platform newsgroup before landing, because the change had some impact. I couldn't find any thread on this list where this was discussed... There are proposals of backout in the bug. What should we do? - Marco. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removal of native notification systems on desktop platforms
That's a pretty long bug to ask people to read over but... The original comment about posting to dev-platform seems to be simply asking that a thread be made to warn people that this change is coming, not for any discussion as such. It should have happened at the time but it's a bit late for it now. There is a comment towards the end of the bug asking whether backing out a single part of the patch instead of the whole feature would solve the problems, we probably need an answer to that before considering whether a full backout is appropriate. It's not totally clear to me what the new feature gives us (i.e. what we would lose from desktop Firefox if we backed it out but left it on the b2g branch) and what has regressed as a result because it is spread over too many bugs. Is it possible to summarise that? On Tue, Oct 8, 2013 at 2:48 PM, Marco mar.castelluc...@studenti.unina.itwrote: In bug 782211, native notification systems support was removed. A lot of bugs have been filed to restore support for libnotify and Mac native notifications, because XUL notifications don't behave correctly on those systems (multi-monitor support is broken, etc.). The patch to remove this support was reviewed, but the reviewer said to ask to the dev-platform newsgroup before landing, because the change had some impact. I couldn't find any thread on this list where this was discussed... There are proposals of backout in the bug. What should we do? - Marco. __**_ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/**listinfo/dev-platformhttps://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removal of native notification systems on desktop platforms
The bug has regressed a lot of things. To me it looks like the decision to land it was a bit rushed. For example, I think we shouldn't have removed the Mac notification system, if it supported the necessary features for the notifications API. Some people say also libnotify should support the necessary features, but I don't know if they're right. A quick summary of the regressions: 1) Thunderbird and other products that don't need web notifications, are now using XUL notifications. 2) On some Linux distributions, notifications are logged somewhere (in the status bar, for example) to allow people to see notifications that were triggered while they were away. With XUL notifications we don't support this anymore. 3) XUL notification may cover system notifications. 4) On Linux, XUL notifications always appear on the top right corner. System notifications may appear in other places according to the DE that you're using. 5) On Linux, XUL notifications have a different theme than system notifications. 6) XUL notifications are ugly compared to system notifications. 7) XUL notifications don't properly support multi-monitor configurations. It's extremely easy to miss a notification when you're using multiple monitors. 8) XUL notifications are just windows, so they may interfere with what the user is doing. For example, they cause dragdrop operations to fail. The options proposed in the bug were: 1) Use native notifications for Firefox notifications and XUL notifications for web notifications. 2) Backout the entire feature. 3) Backout the native notification removal. I don't know what we should do here, but I do think that this deserves a discussion. - Marco. On 10/08/2013 03:00 PM, Dave Townsend wrote: That's a pretty long bug to ask people to read over but... The original comment about posting to dev-platform seems to be simply asking that a thread be made to warn people that this change is coming, not for any discussion as such. It should have happened at the time but it's a bit late for it now. There is a comment towards the end of the bug asking whether backing out a single part of the patch instead of the whole feature would solve the problems, we probably need an answer to that before considering whether a full backout is appropriate. It's not totally clear to me what the new feature gives us (i.e. what we would lose from desktop Firefox if we backed it out but left it on the b2g branch) and what has regressed as a result because it is spread over too many bugs. Is it possible to summarise that? On Tue, Oct 8, 2013 at 2:48 PM, Marco mar.castelluc...@studenti.unina.it mailto:mar.castelluc...@studenti.unina.it wrote: In bug 782211, native notification systems support was removed. A lot of bugs have been filed to restore support for libnotify and Mac native notifications, because XUL notifications don't behave correctly on those systems (multi-monitor support is broken, etc.). The patch to remove this support was reviewed, but the reviewer said to ask to the dev-platform newsgroup before landing, because the change had some impact. I couldn't find any thread on this list where this was discussed... There are proposals of backout in the bug. What should we do? - Marco. ___ dev-platform mailing list dev-platform@lists.mozilla.org mailto:dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removal of native notification systems on desktop platforms
On Tue, Oct 8, 2013 at 3:30 PM, Marco mar.castelluc...@studenti.unina.itwrote: The bug has regressed a lot of things. To me it looks like the decision to land it was a bit rushed. For example, I think we shouldn't have removed the Mac notification system, if it supported the necessary features for the notifications API. Some people say also libnotify should support the necessary features, but I don't know if they're right. A quick summary of the regressions: 1) Thunderbird and other products that don't need web notifications, are now using XUL notifications. 2) On some Linux distributions, notifications are logged somewhere (in the status bar, for example) to allow people to see notifications that were triggered while they were away. With XUL notifications we don't support this anymore. 3) XUL notification may cover system notifications. 4) On Linux, XUL notifications always appear on the top right corner. System notifications may appear in other places according to the DE that you're using. 5) On Linux, XUL notifications have a different theme than system notifications. 6) XUL notifications are ugly compared to system notifications. 7) XUL notifications don't properly support multi-monitor configurations. It's extremely easy to miss a notification when you're using multiple monitors. 8) XUL notifications are just windows, so they may interfere with what the user is doing. For example, they cause dragdrop operations to fail. Awesome, thanks The options proposed in the bug were: 1) Use native notifications for Firefox notifications and XUL notifications for web notifications. 2) Backout the entire feature. 3) Backout the native notification removal. How is option 3 different to option 1? I don't know what we should do here, but I do think that this deserves a discussion. For sure. I assume there are reasons why we can't use native notifications for web notifications? That being the case to me option 1 seems like the best course, but I don't know the work involved in making that happen and that still leaves us with some regression around the interactions between the two. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removal of native notification systems on desktop platforms
Marco writes: The bug has regressed a lot of things. To me it looks like the decision to land it was a bit rushed. I can't help wondering whether the feature was needed urgently on b2g, and the people involved just didn't care enough if getting that done quickly also damaged desktop products. The issues were raised before the bug landed with a proposed solution (comment 14, comment 99), but there were no answers. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removal of native notification systems on desktop platforms
On 10/08/2013 04:37 PM, Dave Townsend wrote: On Tue, Oct 8, 2013 at 3:30 PM, Marco mar.castelluc...@studenti.unina.it mailto:mar.castelluc...@studenti.unina.it wrote: The bug has regressed a lot of things. To me it looks like the decision to land it was a bit rushed. For example, I think we shouldn't have removed the Mac notification system, if it supported the necessary features for the notifications API. Some people say also libnotify should support the necessary features, but I don't know if they're right. A quick summary of the regressions: 1) Thunderbird and other products that don't need web notifications, are now using XUL notifications. 2) On some Linux distributions, notifications are logged somewhere (in the status bar, for example) to allow people to see notifications that were triggered while they were away. With XUL notifications we don't support this anymore. 3) XUL notification may cover system notifications. 4) On Linux, XUL notifications always appear on the top right corner. System notifications may appear in other places according to the DE that you're using. 5) On Linux, XUL notifications have a different theme than system notifications. 6) XUL notifications are ugly compared to system notifications. 7) XUL notifications don't properly support multi-monitor configurations. It's extremely easy to miss a notification when you're using multiple monitors. 8) XUL notifications are just windows, so they may interfere with what the user is doing. For example, they cause dragdrop operations to fail. Awesome, thanks #2 is also for Mac. Chrome has native notifications and its notifications are shown in this bar on the right: http://tinypic.com/view.php?pic=fwucrks=6 The options proposed in the bug were: 1) Use native notifications for Firefox notifications and XUL notifications for web notifications. 2) Backout the entire feature. 3) Backout the native notification removal. How is option 3 different to option 1? I guess they're pretty similar. I'd say we have two options if we want to back out the native notification removal: 1) Use native notifications for Firefox notifications and XUL notifications for web notifications. 2) Try to always use native notifications. I don't know what we should do here, but I do think that this deserves a discussion. For sure. I assume there are reasons why we can't use native notifications for web notifications? That being the case to me option 1 seems like the best course, but I don't know the work involved in making that happen and that still leaves us with some regression around the interactions between the two. I'm not sure. Reading through the bug, looks like there are reasons we can't. At the same time in different bugs there are conflicting statements (see bug 858919 for Linux). The opinion from UX (comment 18 in bug 782211) was: When the system supplies a notification center we should use that. In cases where that isn't true we will need display our own custom notifications. This includes all versions of Windows before 8 and all versions of OSX before 10.8. It's not entirely clear to me why libnotify support was removed, the author of the patch stated: I removed Growl support because it does not support features needed to implement the spec. I also removed libnotify support because I can't find documentation about all the capabilities, so it's possible that libnotify could work but I just can't find it in the documentation. - Marco. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removal of native notification systems on desktop platforms
As for libnotify not being flexible enough for the w3c spec, it is base on a fd.o spec that could be updated to cover our needs. Native notifications will always work better.. - Original Message - From: Marco mar.castelluc...@studenti.unina.it To: Dave Townsend dtowns...@mozilla.com Cc: dev-platform dev-platform@lists.mozilla.org Sent: Tuesday, October 8, 2013 6:14:11 PM Subject: Re: Removal of native notification systems on desktop platforms On 10/08/2013 04:37 PM, Dave Townsend wrote: On Tue, Oct 8, 2013 at 3:30 PM, Marco mar.castelluc...@studenti.unina.it mailto:mar.castelluc...@studenti.unina.it wrote: The bug has regressed a lot of things. To me it looks like the decision to land it was a bit rushed. For example, I think we shouldn't have removed the Mac notification system, if it supported the necessary features for the notifications API. Some people say also libnotify should support the necessary features, but I don't know if they're right. A quick summary of the regressions: 1) Thunderbird and other products that don't need web notifications, are now using XUL notifications. 2) On some Linux distributions, notifications are logged somewhere (in the status bar, for example) to allow people to see notifications that were triggered while they were away. With XUL notifications we don't support this anymore. 3) XUL notification may cover system notifications. 4) On Linux, XUL notifications always appear on the top right corner. System notifications may appear in other places according to the DE that you're using. 5) On Linux, XUL notifications have a different theme than system notifications. 6) XUL notifications are ugly compared to system notifications. 7) XUL notifications don't properly support multi-monitor configurations. It's extremely easy to miss a notification when you're using multiple monitors. 8) XUL notifications are just windows, so they may interfere with what the user is doing. For example, they cause dragdrop operations to fail. Awesome, thanks #2 is also for Mac. Chrome has native notifications and its notifications are shown in this bar on the right: http://tinypic.com/view.php?pic=fwucrks=6 The options proposed in the bug were: 1) Use native notifications for Firefox notifications and XUL notifications for web notifications. 2) Backout the entire feature. 3) Backout the native notification removal. How is option 3 different to option 1? I guess they're pretty similar. I'd say we have two options if we want to back out the native notification removal: 1) Use native notifications for Firefox notifications and XUL notifications for web notifications. 2) Try to always use native notifications. I don't know what we should do here, but I do think that this deserves a discussion. For sure. I assume there are reasons why we can't use native notifications for web notifications? That being the case to me option 1 seems like the best course, but I don't know the work involved in making that happen and that still leaves us with some regression around the interactions between the two. I'm not sure. Reading through the bug, looks like there are reasons we can't. At the same time in different bugs there are conflicting statements (see bug 858919 for Linux). The opinion from UX (comment 18 in bug 782211) was: When the system supplies a notification center we should use that. In cases where that isn't true we will need display our own custom notifications. This includes all versions of Windows before 8 and all versions of OSX before 10.8. It's not entirely clear to me why libnotify support was removed, the author of the patch stated: I removed Growl support because it does not support features needed to implement the spec. I also removed libnotify support because I can't find documentation about all the capabilities, so it's possible that libnotify could work but I just can't find it in the documentation. - Marco. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
