My "Firefox Developer Edition" does not work on MacOS: The interface is unstable - not responding to clicks. Version 89.0b3

I would assume that this should give you the English version: https://download.mozilla.org/?product=firefox-devedition-latest-ssl&os=osx&lang=en-US

Also, I use the en-US or the en-GB version (have to check) and had no issues in the last days, but will monitor and post here if I see something similar.

I tried two versions: en-US and en-GB. And that didn’t work.

are the steps described in https://twitter.com/XF2R1/status/1386214009754456069 fix the issue?

Thanks, I’ll figure it out. Twitter is very slow in Russia due to political restrictions. Temporarily rolled back to version 74.0b6.

ah, let me include the content here:

type “about:support” (without quotes) on your address bar, hit the “Refresh Firefox” button in the upper-right corner, and confirm it

I cannot find the button.

I noticed that the interface turned white when I re-installed the program.

it’s about:support (no space, no semi-colon at the end)

I think I found the preference responsible for the bug: browser.uiCustomization.state.

If you can locate your profile directory, open prefs.js and delete the corresponding line.

Eg on a local profile it was

user_pref("browser.uiCustomization.state", "{\"placements\":{\"widget-overflow-fixed-list\":[]},\"seen\":[\"developer-button\",\"profiler-button\"],\"dirtyAreaCache\":[],\"currentVersion\":16,\"newElementCount\":0}");
1 Like

I think I found the preference responsible for the bug: browser.uiCustomization.state.

I’ve encountered this issue on Windows and not Mac OS, but I can confirm that deleting this pref solves the issue for me.

This was the value:

user_pref("browser.uiCustomization.state", "{\"placements\":{\"widget-overflow-fixed-list\":[]},\"seen\":[\"developer-button\",\"profiler-button\"],\"dirtyAreaCache\":[],\"currentVersion\":16,\"newElementCount\":0}");

If it helps, I can also send you my profile folder backup if there is anything else in there that would indicate more.

1 Like

I’m having the exact same issue. I first noticed it when trying to work on a client’s website this morning. I am running MacOS 10.14.6.

Where do I access the preference value? Trying to use about : support didn’t do anything.

You can find your profile folder following the instructions on https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data#firefox:mac:fx89

(see the Finding your profile without opening Firefox section)

Once you have your profile folder located, there should be a prefs.js file inside of it. Open it with a text editor of some kind, find the line containing browser.uiCustomization.state, and delete the whole line.

After that, you should be able to start Firefox Developer Edition again.

Hopefully this is just going to be a temporary workaround and we can rollout a fix very soon.

1 Like

Thanks a lot to Julian Descott !!
This worked for me.

Same here! thanks a lot @jdescottes :bowing_man:‍♂
Will this be applied for ever or should we do this on each update? :thinking:

Happy to see that you are unblocked!

Will this be applied for ever or should we do this on each update?

The migration code responsible for this issue has now been identified and fixed in https://bugzilla.mozilla.org/show_bug.cgi?id=1706219

The patch should quickly reach Nightly, and I’m sure we will push it to Beta & Developer Edition very soon.

The manipulation will no longer be needed after that.

This arcane workaround has indeed been fixing the problem on my M1 mac already two times. Actually, either a plugin or Firefox itself must have reconfigured as the problem reappeared a few days ago again and gladly I had bookmarked this contribution.

But can it please be fixed? If Mozilla is serious about maintaining or growing the FF market share, I think leaving a problem in their core product for half a year is indeed a show stopper. Surely many others are not searching the entire Internet to edit some .js files on their fs randomly.

Hi Tim, the bug mentioned here was normally fixed in Firefox 89, so you are probably facing a new issue even if the symptoms are similar.

Can you share which version of Firefox this happened with? And did you record the values of the preference before deleting it by any chance?

Actually I didn’t :sob: Will try to remember in case it happens again!

Thanks for the info!

I’ve been trying to make it fail on purpose after seeing your post. I set browser.uiCustomization.state to various values (eg strings which would fail parsing, or simply the one shared by mkohler earlier in this thread). But I did not manage to reproduce it yet. Firefox (dev edition) always managed to start correctly (autofixing the preference when I really used non-sensical values).

Let’s see if it happens again for anyone else and if we can get an idea of which value puts the profile in a bad state.