Change:
sha256 = "0qc62di5823r7ly2lxkclzj9rhg2z7ms81igz44nv0fzv3dszdab"; }) <ins> # These fix Firefox on sway and other non-Gnome wayland WMs. They should be # removed whenever the following two patches make it onto a release: # 1. https://hg.mozilla.org/mozilla-central/rev/51c13987d1b8 # 2. https://hg.mozilla.org/integration/autoland/rev/3b856ecc00e4 # This will probably happen in the next point release, but let's be careful # and double check whether it's working on sway on the next v bump. ++ lib.optionals (lib.versionAtLeast version "92") [ (fetchpatch { url = "https://hg.mozilla.org/integration/autoland/raw-rev/3b856ecc00e4"; sha256 = "sha256-d8IRJD6ELC3ZgEs1ES/gy2kTNu/ivoUkUNGMEUoq8r8="; }) (fetchpatch { url = "https://hg.mozilla.org/mozilla-central/raw-rev/51c13987d1b8"; sha256 = "sha256-C2jcoWLuxW0Ic+Mbh3UpEzxTKZInljqVdcuA9WjspoA="; }) ] </ins> ++ patches;

Discussion:
After upgrading to Firefox 92 on NixOS unstable, anything that requires a menu or a tooltip in the browser (hamburger menu, right click context menus, tooltips on tabs, etc.) stopped working. The menu itself isn't rendered, the whole UI freezes and sometimes the cursor changes to a hand, indicating a clickable button, but nothing happens when clicking where the button should be. Clicking outside the area where the menu should appear restores Firefox to a usable state, until another menu button is pressed. Steps to reproduce the behavior: Firefox the hamburger menu button on the top right corner The main settings menu for Firefox should appear. The hamburger button remains in a "clicked" state and the entire UI freezes, the mouse cursor might change to a hand, but no menu is rendered. Running Firefox on Sway with and Maintainer information:
I can reproduce this too, but I don't think it's NixOS' fault; we ought to report this upstream to sway and Firefox.
You can manually apply this patch to firefox to fix the issue: I'm testing that now.
~You should be able to use this overlay to work around the issue for now:~ This partially fixes it
Alright, this overlay fully fixes the issues while we wait on a new release: I'm going to make a PR adding this to our pkg for now.
The two patches applied, menus and form overlays are visible again and the freezing is gone. Thank you
Unfortunately, it seems the fix has not worked for me. It may be due to using the home-manager module; however, I have overriden its to use the patched version and the only noticeable difference is that now a tiny vertical line appears where the context menus should be. The freezing caused by it and the fact that the menu itself is still unusable are still present, though.
There were multiple similar bugs, perhaps?
As a data point: I'm running Firefox 92.0 with the above mentioned patches on Sway on NixOS unstable and everything works great.
Do you happen to use the home-manager module or do you run Firefox as a regular system package? That may be a differentiating factor and may point towards an issue with my home-manager configuration instead.
Through home-manager.
I have tried to add your method of explicitly wrapping the package and yet, the same behavior remains, unfortunately:
I wonder if this could differ based on GPU model.

(different rendering code paths on driver side)
Interesting. It is working for me on amdgpu, but I saw the issue yesterday on an i915 gpu, didn't investigate much, whether the patch already made it onto the unstable channel.
Yes, it is in already but not in yet.
I have tested this on amdgpu, nouveau, and i915 without problems. I'm wondering whether is actually using the patched version? Try to clone the repo, do and see if it works correctly. Alternatively, this should give you a firefox with the patch so you can make sure:
Ah, I managed to reproduce it on i915 now. It's not immediate for me, after a bit the menus seem to break. Amazing.
Maybe we also need this GTK patch:
Also worth trying:
Interestingly, the firefox-unwrapped package in my system has a different hash, namely . Compiling from the nixpkgs repo as you suggested does give me the version with the hash as you stated, and this version does behave correctly in regards to the menus. Something really strange is happening with my system updates then. Adding to this, I only got the version with the "black vertical line" as I described above (I attached a screenshot for reference) after I garbage collected a few generations of testing, which really shouldn't happen if I'm understanding the way nix works correctly. In any case, this is not an issue related to the Firefox package itself. !
I successfully have this working with firefox from mozilla's pkgs.
So I was able to fix this by removing the package from my home-manager config and adding it to my nixos-config. Not sure if this helps anyone here debug the issue, but it's worth a look. EDIT: Well, menus are fixed. Tooltips are still messed up.
I've been running Firefox out of a local nixpkgs build but I haven't tried messing around with the system config yet since then, I'll try your suggestion. One thing of note is that some sites' dropdown boxes are still broken, even with the patches, while everything else has been working fine.
I don't know what exactly is wrong but I am getting the random flickers on Firefox 93 as well. Has anybody found a solution?
I still get this issue sometimes.

It's odd because it's very hit-or-miss for me; restarting Firefox often fixes it, and restarting it again results in it being "broken" again. The same thing happened for a long time with the screenshot tool in Firefox: sometimes it works, sometimes it doesn't, and restarting Firefox sometimes "toggles" if it does or doesn't work. I haven't been able to debug any further, though.
I haven't experienced this issue anymore since Firefox 93; both the Bugzilla issue and the GTK merge request report this issue as fixed, does anyone else still have this problem?
Can you share your exact config related to Firefox so that I can try it? Last time I checked I still had the same problems in 93.
In , add to the list of packages. Then, in : EDIT: shouldn't make a difference, but for completeness' sake, I also have this in :
Thanks! Do you use any environment variables such as ?
I actually didn't use that, but maybe I should. is set by using the package.
Oh no. The flickers are still here for me with the following config.
That is troubling... might it be a GPU-related issue?
I marked this as stale due to inactivity. &rarr;
I think this can be closed as it has been fixed for me since 94 or something.