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

Developer Tools
#21

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
#22

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.

#23

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
#24

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

#25

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

#26

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.

#27

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.

#28

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?

#29

Screenshot 2022-08-16 at 12.44.16
Screenshot 2022-08-16 at 12.44.161346×708 193 KB

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

#30

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.