Closed Bug 737646 Opened 8 years ago Closed 8 years ago

no biff notification if notification-daemon not running

Categories

(Toolkit :: General, defect)

All
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla14

People

(Reporter: wolfiR, Assigned: wolfiR)

Details

Attachments

(1 file, 1 obsolete file)

This seems to be an old bug but I usually do not notice that stuff.

When mail notifications are enabled in Thunderbird (tested 12 here) I still don't see them in my environment. It works under Gnome where notification-daemon is running and libnotify is used.
It does not work under my window manager (no notification-daemon running).

I think there should be a fallback to the XUL notifications instead. (Firefox doing that for example for download completed notifications)

So I checked the code a bit and found:
http://hg.mozilla.org/releases/comm-beta/annotate/be8909bb020b/mailnews/base/src/nsMessengerUnixIntegration.cpp#l386

The fallback is apparently meant to be ShowNewAlertNotification()?

In that case I think this is not sufficient because in my environment libnotify is likely happily accepting the notification request but is actually not displaying anything because of the not running notification-daemon. Therefore the fallback never is reached.
https://mxr.mozilla.org/comm-beta/source/mozilla/toolkit/system/gnome/nsAlertsIconListener.cpp#249
indeed returns success even if no notification-server is running and no notifications are displayed.

As I understand the code (I might miss something) the fallback only works
- if no NS_SYSTEMALERTSERVICE_CONTRACTID is available
  (the mozgnome component is not available or cannot be loaded)
- imgILoader->LoadImage() fails

I'm wondering why the fallback works in Firefox. I'll check what happens there to spot a difference.
I have a candidate fix but still testing it. Will attach when I can confirm it works as expected.
Component: OS Integration → General
Product: Thunderbird → Toolkit
QA Contact: os-integration → general
Version: 12 → Trunk
Attached patch patch (obsolete) — Splinter Review
AFAICS notify_get_server_caps() is supposed to return at least one item. If no notification-daemon is running it throws an error message on stderr and returns NULL.
Therefore it makes no sense to proceed trying to use libnotify.
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
Attachment #608299 - Flags: review?(dtownsend+bugmail)
Comment on attachment 608299 [details] [diff] [review]
patch

Cancel review request.

While I think the approach is correct this alone does not fix the issue.
The reason is that a second call to notify_get_server_caps() does not return NULL while there still is no notification-daemon running.
Need to investigate first what libnotify is doing here exactly.
Attachment #608299 - Flags: review?(dtownsend+bugmail)
Attached patch patch #2Splinter Review
I was blind before. libnotify is not to blame but me don't recognizing an if statement.
(There would be another option to uninit libnotify and therefore try again with every alert request in case a notification-daemon becomes available but I think it's fine to record the initial non-working state.)
Attachment #608299 - Attachment is obsolete: true
Attachment #609232 - Flags: review?(karlt)
Comment on attachment 609232 [details] [diff] [review]
patch #2

notify_get_server_caps doesn't distinguish between no server and a server with no optional capabilities, but I guess such a server is rare these days.
This approach looks more appealing than making another synchronous DBus call.
Attachment #609232 - Flags: review?(karlt) → review+
https://hg.mozilla.org/mozilla-central/rev/9d156f164c8e
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.