Enabling Wayland support by default prevents use of XWayland on Wayland
systems, while correctly falling back to X11 when Wayland is
unavailable in the current session.
With the current packaging many people unnecessarily rely on the
`firefox` attribute, which is suggested by nixos-generate-config, which
in turn makes their Firefox use XWayland, when it shouldn't, which
causes bugs with GNOME on Wayland:
https://discourse.nixos.org/t/firefox-all-black-when-first-launched-after-login/21143
Using the Wayland-enabled Firefox was tested on pure X11 systems by
contributors on the #nix-mozilla:nixos.org room and we are confident
this change will not cause severe regressions.
Even better, people can now toggle `MOZ_ENABLE_WAYLAND=<0|1>` in their
environment to override this decision, should they feel the need to do
so.
https://discourse.gnome.org/t/split-and-rename-of-chrome-gnome-shell/11075815ec9e1af...v42.0
- Renamed and split into a separate repo from the extensions.
- CMake build replaced with Meson (jq also not needed)
- requests Python module not needed since updates are now solely handled by GNOME Shell itself
Also
- Corrected license
- Cleaned up the module
- Replaced PYTHONPATH in a wrapper by Python environment
Changelog-Reviewed-By: Jan Tojnar <jtojnar@gmail.com>
The xdg-open utility is only ever a runtime dependency and its
dependents only expect that it accept a URI as a command line
argument and do something with it that the user would expect.
For such as a trivial relationship it should be possible for
users to override xdg-open with something else in their PATH.
Firefox 61 started to enforce signatures for add-ons and since
commit d031843a1e, we get an evaluation
error that recommends the user to switch to Firefox ESR.
This isn't an option for everyone and as I also pointed out in the pull
request[1] introducing the above commit, I've been building Firefox like
this:
let
firefoxNoSigning = firefox-unwrapped.overrideAttrs (lib.const {
MOZ_REQUIRE_SIGNING = false;
});
in wrapFirefox firefoxNoSigning {
nixExtensions = ...;
}
However, this only works after manually modifying nixpkgs (or copy &
paste wrapper.nix elsewhere) every time I want to have a new Firefox
version. Of course, this gets annoying and tedious after a while, so
this motivated me to properly fix this to not only check for an ESR
version but also check the value of MOZ_REQUIRE_SIGNING.
Note that I'm using toString here to check for the value because there
are several ways (false, null, "", ...) to set the environment variable
to an empty string and toString makes sure that it really is the desired
behaviour. I specifically checked the Firefox source and also tested
this with multiple values and only building with MOZ_REQUIRE_SIGNING
set to an empty string seems to work (no "0", "false" or other
variants).
Additionally, there is another method to allow unsigned add-ons, which
is by using the --with-unsigned-addon-scopes configure option[2].
Unfortunately, this does not work with nixExtensions because we don't
have (or want) a central directory where those add-ons reside.
Given that nixExtensions disallows manually installing add-ons, setting
MOZ_REQUIRE_SIGNING to false should be safe in this case.
[1]: https://github.com/NixOS/nixpkgs/pull/133504
[2]: https://bugs.archlinux.org/task/63075
Signed-off-by: aszlig <aszlig@nix.build>
`onepin-opensc-pkcs11.so` only enables PIN1, but PIN2 is also required.
`opensc-pkcs11.so` enables all slots.
I can successfully use PIN1 and PIN2 in Smart-ID cards with this.
A small shell script that can be used to extract a binary wrapper's
makeCWrapper call from its embedded docstring, without depending on
makeBinaryWrapper.
We can't just edit binary wrappers in place because of a length
mismatch, so we have to parse the generating makeCWrapper call out of
the binary, extract wrapper arguments from it and add them to the
Firefox wrapper.
All these contortions are needed because Firefox looks for its runtime
in argv0, so the proper argv0 needs to be set by wrappers to always
point to the "final" runtime. I think this could be avoided by wrapping
/lib/$libName/firefox instead of /bin/firefox, and I'd like to look into
that in the future, but for now I'm just fixing the immediate problem.
Darwin support was marked broken in 2019 with Firefox 69 and has missed
therefore missed out and not been tested on the following 29 major
releases since.
It cannot be supported again without a darwin user stepping up to take
care and work on and test every major release, which hasn't happened
since I took over maintainership.
The recommendation of the people that tend to the firefox source build
is for darwin users to use firefox-bin instead.
Firefox does not support passing pipewire as a system library and
instead relies on a vendored copy it ships. We keep the flag because it
is tied into the wrapper, because we still need to have access to its
libraries at runtime.
This should not change the derivation, but the new attribute names make
more sense once we package something that is not Firefox using this
expression.
Firefox 81 introduced a new print dialog. Under NixOS, this dialog
offers only "Save as PDF" as the destination. To print to a real
printer, one has to click "Print using the system dialog" and print
from there. This is not only one unnecessary extra click, but the
system dialog also does not offer preview.
With this commit, Firefox starts offering real printers in its
printing dialog, removing the above mentioned deficiencies.
CUPS is needed because Firefox uses dlopen() to load libcups.so.2 at
runtime. See
https://searchfox.org/mozilla-central/rev/b52cf6bbe214bd9d93ed9333d0403f7d556ad7c8/widget/nsCUPSShim.cpp#28
In order to make the man pages accessible, the previous code used
nix-support/propagated-user-env-packages. However this file is also used to set
the PATH when the application is executed with `nix run`, thus including the
wrapped and the wrappee in the environment.
Having the wrappee enumerated first in the environment caused `firefox` to
default to the wrappee, and as such not being able to find a proper GTK. This
was a source of failures while opening a file-picker.
This change removes the code to propagate the wrappe in the environment, as the
man pages are already linked in the wrapper output.
082ed38 introduced it to fix the profile-per-install policy of FF 67. But since
FF 69 (or 68?), there is `MOZ_LEGACY_PROFILES`, which we use since 87e2618.
There is no reason for the `SNAP_NAME=firefox` workaround anymore.
Additionally, the combination of `SNAP_NAME=firefox` with
a large ~/.nix-profile/share in `XDG_DATA_DIRS` triggered
https://bugzilla.mozilla.org/show_bug.cgi?id=1569625 for me, so this really
fixes a bug in my configuration.
The only downside of this approach is that we lose support for running FF 67
(and possibly 68).
When firefox is executed by programs that also make changes to
`LD_LIBRARY_PATH`, the paths can conflict causing firefox to look for
shared libraries in the wrong location. This is because the wrapper
script around firefox *appends* library paths to `LD_LIBRARY_PATH`
instead of prepending them, causing library paths that are already in
the environment to take precedence over the library paths that firefox
depends on.
As an example, Discord and firefox both depend on different versions of
libnss. When Discord launches firefox, which happens when clicking on
hyperlinks, the path in `LD_LIBRARY_PATH` to libnss set by Discord takes
precedence over then one set by the firefox wrapper script causing
firefox to load a different version of libnss than the one it was built
against. This causes a fatal error in firefox which prevents it from
starting.
This commit fixes this issue by switching the firefox wrapper script to
*prepend* its library paths to `LD_LIBRARY_PATH`.
Fixes#118432
