Nixpkgs: Firefox can't find libnotify.so.4, falls back to XUL popups

[drdaeman]

Issue description

Firefox uses XUL-based notification OSD, because it seems to be unable to dlopen("libnotify.so.4"). The result is somewhat non-native look-and-feel (YMMV), as the OS integration's lacking. This seems to be a bug — rather than intentional omission — because libnotify is mentioned in the expression.

When started as env LD_LIBRARY_PATH=$LD_LIBRARY_PATH${LD_LIBRARY_PATH:+:}/nix/store/67kcj066h5djf8g3j1566lrlm60a9p0s-libnotify-0.7.6/lib firefox notifications _mostly_ work, so the derivation may possibly benefit from a small makeWrapper update.

I wrote "mostly" because there's an independent issue — notifications that have icon/image URL specified usually fail silently. This is caused by this Firefox bug, which seems to be fixed only in Firefox 50.

If desirable (I'm new to Nix), I think I can try to make a pull request for this, but not sure how it's best to approach things and what are the policies regarding Firefox packaging.
One idea I have is making a derivation for 50a2 Developer Edition (firefox-devedition?), with a wrapper including libnotify path. Or maybe even 50b1, which should be released tomorrow.
Another idea is to stick with the stable version but backport all the relevant patches to 48.0.2.
All of this if it's desirable to have libnotify support, of course (which, given that it haven't seen much use, could be somewhat unstable).

Steps to reproduce

• With a DE that supports XDG Desktop Notifications via libnotify (I'm using KDE5), install firefox (not firefox-bin)
• Make the browser emit some notification. One option is https://jsfiddle.net/yoshi6jp/Umc9A/
• Notice the notification is non-native - just a window created by Firefox itself, completely alien to the desktop environment.
• Run with LD_LIBRARY_PATH including ${libpng}/lib

• Repeat the test above (keep the "icon" field empty), observe that now the notifications are native.

  Technical details

• System: 16.03.1299.a8e0739 (Emu)

• Nix version: nix-env (Nix) 1.11.2
• Nixpkgs version: 16.03.1299.a8e0739

Thanks!

[drdaeman]

I was able to backport the patches from v50 to v48 in my branch here: https://github.com/drdaeman/nixpkgs/commit/4fbdf15de47955c939c077f74189d0220def106e

Haven't tested it much yet, but seem to work for me.

[vcunat]

The wrapper is a possible place to fix it, but I'm just testing a patch that should fix firefox-unwrapped already as I think that's better.

[vcunat]

Works, but I'll re-test with ESR and thunderbird notifications before pushing.

As for the patch, I don't feel like reviewing such nontrivial stuff, leaving that to upstream 8-)

[drdaeman]

Great!

Yes, I totally understand the patch is absolutely non-trivial. While all I did was taking the 3 (out of 4 - I've ignored the OS X one) patches from the upstream's linked bug, applying them to the vanilla sources (resolving trivial merge conflicts and ignoring images as patch doesn't handle binaries), then replacing newer-style imgLoader::NormalLoader back to do_GetService("@mozilla.org/image/loader;1") and running diff on the result, it's still a complicated mess.

For ≤49, I guess it would make sense to make libnotify support optional (like it's with enableGTK3 etc) and opt-in, though — because of the bug, not everyone would appreciate silent loss of notifications to the OS integration. (Any chance of v50 inclusion in unstable? What's the policy on this?)

Thanks a lot!

[vcunat]

Normally we don't add unstable or testing versions to nixpkgs – unless there's some specific reason. Firefox is quite a popular package, I believe, so I personally think we could have some firefox-unstable, especially if many people would want to use it...

[vcunat]

@drdaeman: thanks a lot for finding a solution!

Do you have any idea why the same approach wouldn't work for thunderbird? (It's easiest to try $LD_LIBRARY_PATH, as that doesn't require a costly rebuild.)

[drdaeman]

Unfortunately, no, haven't checked Thunderbird yet. I'll try to take a look when the time'll permit (unfortunately, for me, this week's going to be a busy with other matters, so maybe on another weekend) and write here if I'll find something.

As for the Firefox - a "Developer Edition" derivation may be a good middle grounds. Technically, it's of beta-stability (currently 50a2, but personally I haven't ever had any issues for year), but Mozilla themselves market it to web developers, so it may be worthy of inclusion.