After Firefox updated to 156, 7 of my extensions stopped working in my regular profile. They still appear in the extensions list, but their toolbar buttons either do nothing or disappear after a restart. I restarted Firefox and the computer, then disabled and re-enabled each affected extension. I also removed one extension and installed it again, but that only restored its button until the next launch.
I created a separate profile to check whether the problem was tied to my existing settings, and the same extension worked there. What should I check next in the original profile without wiping it, and is there a useful log or setting that could identify what Firefox 156 is blocking?
If the same extension works in a clean profile, Firefox is probably not blocking it globally. That points to damaged extension state, a profile policy, or something restoring stale profile files at startup.
First, open about:support, use “Open Folder” beside Profile Folder, then close Firefox completely and copy that folder somewhere safe. In the original folder, rename extensions.json, addonStartup.json.lz4, and compatibility.ini by adding .old to each filename. Start Firefox twice and check the extensions again. Firefox should rebuild those files. You may have to re-enable some add-ons, but this is much less destructive than refreshing or replacing the profile. Similar extension-registry resets are commonly used when enabled add-ons remain installed but fail to load.
For an actual error message, open about:debugging, choose “This Firefox,” find an affected extension, and click “Inspect.” Check its Console immediately after a failed startup or after clicking its dead button. The Browser Console is useful too, especially if you open it soon after launching Firefox and filter by the extension’s name or ID. about:debugging lists installed WebExtensions and provides an inspection console for them.
Check about:policies as well. Look under both Active and Errors, particularly for anything involving ExtensionSettings. This matters even on a personal machine if security software, workplace management, or an old policies.json file has touched Firefox.
If the extensions start working after the file reset but break again after another restart, watch for software that modifies the profile folder: antivirus tools, profile cleaners, cloud-sync clients, backup restore features, or incorrect folder permissions. A button that returns after reinstalling and vanishes on the next launch often means Firefox’s newly written state is being replaced or cannot be saved. Only if the extensions work but their buttons remain missing would I rename xulstore.json; that resets toolbar layout, so it is better treated as a separate UI fix rather than the first repair.
If the affected extensions work when every other add-on is disabled, you’re dealing with a conflict rather than damaged profile files. Re-enable the remaining add-ons in batches until the buttons fail again, which is quicker than rebuilding the whole profile.
Reinstalling the affected extensions can wipe their local settings, so I wouldn’t start there. Buttons disappearing after a restart sounds more like Firefox’s toolbar state or startup cache than seven extensions independently breaking.
@ghostbadger50’s conflict test is useful, but first open about:support and use “Clear startup cache.” Then check Customize Toolbar and the extensions menu, since the update may have unpinned buttons rather than removed them. If the extensions run from their entries in the extensions menu but their toolbar icons vanish, that narrows it to the interface configuration.
Before trying “Refresh Firefox,” make a profile backup. Refresh is fairly blunt and can create extra cleanup work even when the actual problem is just a damaged toolbar layout.
The hidden downside of rebuilding extension files is that the fix may vanish at the next launch if your profile has a user.js file. Firefox reapplies that file on every startup, and an old privacy or hardening setup can force preferences that newer extensions no longer tolerate.
With Firefox closed, check the profile folder for user.js and temporarily rename it to user.js.disabled. Don’t touch prefs.js. Start Firefox twice and test again.
Firefox does not normally create user.js, so if it exists, it came from a tweak package, management tool, or manual customization. That would neatly explain why repairs seem to work and then undo themselves after a restart.
Create another temporary profile from about:profiles, launch it, and do not sign in to your Mozilla account. Install only one affected extension and restart Firefox a couple of times. If it stays working, sign in but leave Add-ons and Settings unchecked in the Sync options. Test another restart before enabling either category.
This matters because a “clean” profile stops being a clean comparison once synchronized add-ons and preferences are pulled into it. If the failure appears right after Add-ons or Settings sync is enabled, disconnect Sync before repairing the regular profile. Otherwise you may keep fixing local files while the unwanted state gets copied back.
If nothing changes, delete the temporary profile and continue with the registry and user.js checks. At least this rules out another device or synchronized preference without touching the profile you actually use.
Don’t waste an evening doing a profile surgery before checking one boring thing: are all seven of these old, or from small developers who went quiet? Seven extensions dying at the same moment after a major version bump rarely means seven separate conflicts or seven corrupted registry entries–it usually means they all share something that the update changed underneath them.
The obvious candidate is the Manifest V2 to V3 transition; Firefox has been phasing out old-style extensions for some time, and a major update is precisely when a background-page extension that used to load will suddenly register but do nothing (which matches your symptom perfectly, button present but dead, or button gone when the startup cache rebuilds). Before doing anything else, open all of these affected extensions’ entries in about:addons, expand their details, and see when they were last updated–if they were all stale MV2 add-ons, no amount of renaming extensions.json will bring the buttons back, because Firefox is loading the add-on and then refusing to run the deprecated parts.
So @j.collins’s batch conflict test is a reasonable idea in general, but I’d hold off on it here. It’s built for the case where one add-on poisons another. With seven failing together, you’ll spend an hour toggling things to land on the same answer the ‘last updated’ date gives you in two minutes.
The rest of the thread is solid for the other scenario. If the add-ons turn out to be current and maintained, then yeah, @mr_probe’s user.js check is the one I’d actually prioritise, because a leftover hardening file quietly forcing prefs is the classic ‘fix undoes itself on restart’ trap, and it costs nothing to rename and retest.
One thing no one seems to have mentioned is checking whether any of the seven are just flat incompatible at the moment and waiting on the developer to fix. That’s a profile problem you can’t fix. The realistic options if that’s the case are to downgrade Firefox temporarily and disable auto-update or find a maintained replacement. Not ideal, but better than waiting a week for someone to stop treating their dead project like a corrupted profile.
Don’t downgrade Firefox or switch off updates yet. The Manifest V2 explanation confused me because Firefox did not follow Chrome’s blanket removal of those extensions. An old add-on can certainly break, but its age or manifest version alone does not explain why it works in a fresh profile.
Before changing profile files, open a normal website where an affected extension should work, click the extensions button, then open that extension’s menu and check its site permissions. Try granting access for that site or all sites, depending on what the extension needs. Do the same under the Permissions tab in about:addons. Permission choices belong to the profile, so a clean profile can behave differently even with the identical extension installed.
Make sure the test page is not an about: page, the add-ons site, or another protected Firefox page, since extensions may appear dead there by design. If permissions are already granted and they revert after restarting, then the profile-state and user.js suggestions become much more convincing. But checking access first is quick, reversible, and avoids turning a permission problem into a profile repair project.