To be honest, that would be a great scenario. If future changes prevent the add-on from working completely, then my hope is that Firefox incorporates the add-on main feature internally. Ultimately, I want the add-on to adapt to the Firefox internal changes rather than fight them. I wish I knew! At the moment, it does not appear so but that is always a possibility. Are more Firefox internal changes going to cause more issues in the future?.In any case, I would want to use something that I know would be reliable.

Flags like these are sometimes only temporary (I tend to think .2h2020 will be one of these), and sometimes stay around for a long time (and I think will be one of these). Could Firefox provide an official access to these flags?.I want the add-on to be a stable and reliable piece of software. Even if there were, I would have to be very carefully using them- any 'hacky' solution would likely not be reliable and at great risk of breaking in the future. Is there any 'workaround' to get these values?.It is unfortunately out of my control at the moment, and this piece helps explain the technical reasons why. I truly hope this one scenario will not be a blocker for the users, and I understand some will be disappointed. Mostly for transparency and documentation purposes. Why such a long piece to explain the add-on is going to behave incorrectly under one scenario?.This will be added to the 'known issues' list. Everything else will continue to work as before. Bookmarks created by drag-and-drop will automatically be moved to the configured default folder (if the Firefox built-in bookmarking override is enabled) instead of staying where dragged (moving bookmarks is not affected). It means the add-on will continue to work, with a minor limitation. Not having a way to read these values, the add-on will have to assume every bookmark is created by the system. This has been the case since Firefox 57.x ('Quantum') and the introduction of WebExtensions, for good security reasons. Every user can access and change them via the about:config page, but there is no WebExtension API allowing developers to read these values, or any of the about:config values. The issue is that there is no way for the add-on to know the value of these flags. One could assume figuring out the value of these flags when the add-on is running and adapting the internal logic accordingly would be enough to fix the add-on. Firefox 85.x has the flag enabled by default for everybody, and also gets a new flag (I am not quite sure yet how the two interact together).This explain the issues reported in This extension does not work after updating to Firefox Dev 84.0b2 #356. From what I can tell not everybody got the flag enabled either. It appears its behavior changed between the beta and the stable release. Firefox 84.x gets the new .2h2020 flag.As you can imagine, this breaks the internal logic of the add-on. Instead of using the 'Other Bookmarks' folder, it will use a different one. With this project, Firefox is changing the default folder where created bookmarks are added.

override the default bookmark folder if configured in the former, and doing nothing in the latter). It allowed me to process things differently if they were created by Firefox or by another means (i.e. The add-on was using this fact as a base for its internal logic. not by a third-party extension) were added by default to the 'Other Bookmarks' folder. Previously, all bookmarks created by Firefox (i.e. Let me try to explain why and how I am trying to fix this. More specifically, it breaks the original and main feature allowing you to set the default bookmark folder for bookmarks created using the browser built-in system. However, it does change the way bookmarks are handled internally by Firefox, and as a consequence, breaks the add-on. As the name indicates, it intends to improve the experience regarding bookmarking with the browser, which I believe is a good thing! The Firefox team has been working towards a project called '2020H2 bookmarks improvements' (meta Bugzilla entry here). I am planning to release a new major version 3.0 and I hope to have it available on AMO before the official release of Firefox 85 to the public on. Bookmarks created by drag-and-drop will automatically be moved to the configured default folder instead of staying where dragged if the Firefox built-in bookmarking override is enabled (moving bookmarks is not affected). It will continue to work, with a minor limitation. Firefox internal changes means the add-on needs to change the way it works internally as well.

Firefox set default bookmark folder