rsx11m wrote:As for disabling libnotify in .mozconfig, I'm not aware of that option (but it should be "--disable-libnotify" as a single argument in this way).
This was a typo in my post, I used the argument as you wrote it.
Just to note here, I decided to give SeaMonkey 2.33.1 a try in Ubuntu 12.04 32-bit VM to see if I want to upgrade or not... and I got one working download notification - which seemed to use the same style notification as 2.32.1 rather than the system notification. This was the first opportunity for download complete notification that occurred after the upgrade from 2.32.1, the only other notifications there would have been came from code like the sample code above and thus getting displayed as system notifications.
Probed it further, because of this bug report - couldn't get another download complete notification to happen at all.
Don't know if that's useful info or not. (If so, that was a disposable environment so if it's helpful I can start over from the same starting point, upgrade SeaMonkey all over again, and try to see how much of that was a fluke.)
Last edited by barbaz on April 8th, 2015, 11:08 pm, edited 1 time in total.
My guess is that it fails for some reason under certain circumstances but doesn't return the correct response that it did fail to trigger the fallback. Thus, to see the built-in notification, both libnotify has to fail and the return value has to correctly indicate that.
My patch for adding a preference whether or not libnotify should be used or the built-in notification is awaiting check-in, and I've posted a patch to disable libnotify usage for new-mail alerts by default, thus hopefully avoiding the problem of missing notifications at least for new messages in an upcoming release until the core issue is fixed.
Great, good to hear this! As someone who is not really familiar with the system, may I ask in which upcoming version this patch has a realistic chance to be included?
It depends. Thunderbird will hopefully want this workaround for their upcoming 38.0 release, which opens a new branch. This would correspond to 2.35 in the SeaMonkey version counting, but it depends on how quickly it's getting branch approval (otherwise it may be as late as 2.37 about 12 weeks later).
rsx11m, do I understand the replies to your bug reports correctly that a "mail.biff.use_system_alert" preference will be added as of SM 2.35, defaulting to "false"?
Yes, both the preference setting and it defaulting to "false" will happen with 2.35, provided that the build-system issues which prevented the 2.34 are resolved in the near future. Otherwise, a possible fallback would be the release of an interim 2.33.2 with selected security and stability patches. Since it's unclear at this point whether or not this will happen (i.e., further delays with 2.35), the patches haven't been approved yet to land on the release branches (but IanN should be in the loop for that).
Almost done - switching the default to the built-in alerts broke some automated tests in Thunderbird (bug 1165320), thus I'm fixing those now (they didn't catch the regression in the first place as those tests are using a mock service rather than the "real" libnotify functions, thus implicitly assume that those are always behaving nice and correct). Unless they decide to back out the original patches again (which I don't think will happen given that the fix is obvious), it shouldn't affect the upcoming release.
mozillaZine is an independent Mozilla community and advocacy site. We're not affiliated or endorsed by the Mozilla Corporation but we love them just the same.