Firefox wayland add environment variable

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


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, 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?

1 Like

I have MOZ_ENABLE_WAYLAND=1 in this file and it seems to be working fine.

You could verify: about:support >> Graphics: Window Protocol

1 Like

You can just add it to the .desktop file.


Exec=env MOZ_ENABLE_WAYLAND=1 firefox

Its best to avoid global variables when not necessary

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.

1 Like

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

1 Like

FF defaults to target 60, I think there is a about:config for it but idr.

You sure FF can maintain 144hz though? :stuck_out_tongue_winking_eye:

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

ohh I see, 60 is fine, just checking if its some errors

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).

1 Like

Might be because of how Wayland or kwin exposes the display? I wonder if gnome does it too?

Display0 1920x1080@60Hz scales:1.000000|1.000000

Display0 1920x1080@60Hz scales:2.000000|2.000000

This shows correctly for my laptop’s screen, it seems.

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. :stuck_out_tongue_winking_eye:

In the end, we have choice, which is good. :smiling_face_with_three_hearts:

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

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.