I start to use wayland, and firefox need to be set with an environment variable, MOZ_ENABLE_WAYLAND=1, I am not sure where it should go, in terminal
MOZ_ENABLE_WAYLAND=1 firefox
works good for me, with the Window Protocol entry correctly says wayland in about:support. But to make it works when I use app launcher, I am not sure where should I put it. According to https://wiki.archlinux.org/title/Firefox#Wayland, I can put into .desktop or environment.d somewhere?
should I make a file ~/.config/environment.d/firefox.conf and put MOZ_ENABLE_WAYLAND=1 in it,? or just ~/.config/environment.d/envvars.conf will do it? or some .desktop file?
Having a local .desktop works, but it has the disadvantage that you become decoupled from the .desktop which is installed by the package, which may change over time.
Putting it into a *.conf file in ~/.config/environment.d/ is imho the better solution and is applied globally for your user, no matter how you start FF.
Thanks guys, there is a issue, although the Window Protocol shows wayland, which is correct, the Target Frame Rate shows 60 instead of 144, and Display0 shows 5120x2880@144Hz scales:2.000000|2.000000, but my monitor is 3840x2160
When you use the .desktop way you avoid unnecessary globals.
Setting things globally when you don’t need to is poor practice IMO and its not like the .desktop file has wide swinging changes between versions. This also allows for FF to easily be run in Wayland or Xwayland with custom .desktop files or even having separate profiles too for specific things
and I have tested the same thing on my amd laptop, when I do nothing (do not set the environment variable), it says xwayland with rate and resolution correct, but if I set the environment variable, it says wayland with wrong frame rate and resolution
Mine shows 4388x2468@60Hz scales:2.000000|2.000000 on 3840x2160 at 175%. I noticed before that those values don’t display what you would expect on Wayland, but I didn’t bother to look into it. It seems the calculation is off when using scaling (kwin I assume).
It isn’t unnecessary if you want it to be the local (global) default.
I would consider it more bad practice to pin a single source file to a particular release version. Maybe the file in question doesn’t change that often, but eventually it will.
One could also argue that if you - for whatever reason - want to deviate from the preferred user default you could (un)set it in a .desktop file.
Xdg desktop file specficaton has been stable for at least 10yrs. I’ve been using the same .desktop file for Firefox for 4yrs with only addition being Wayland env variable. Weren’t not pinning a readily breakable file here that’s dependent on a specific version of Firefox and is integral to the source tree and build. This is an exaggeration
Its very silly to set globals then override them locally when you can simply work entirely locally. Global variables also have the downside that you can’t be certain how they effect other applications. Global variables should be used sparingly and only when absolutely necessary.
Getting in the habit of declaring globals for things that don’t need it is a good way to run into unnecessary breakages that could be avoided. In this case that’s not likely but when you tell someone how to set a global they’re likely to continue to set them globally which can get messy.
In this case it should be OK, just be careful with globals @yuanhao
