Yeah, that indeed sounds like a bug.

Huh. I dunno what the actual requirements for Android compatibility are then. Anyhow, being recommended or in a custom collection isn’t strictly a requirement anymore.

This isn’t true anymore. Any extensions that are explictly marked as Android compatible (by the author) should now be installable from AMO. I’m pretty sure that the extension needs to use manifest v3 to be able to be Android compatible, but as long as that is true and the author has set the Android compatibility flag, you should be able to add it normally.

Installing from AMO seems to work fine for me - although I’m using Nightly variant, which certainly could behave differently. However, Firefox 120 is supposed to work the same I believe.

This should be pretty simple to do, although what exactly do you consider a “duplicate”? Does it count as duplicate if the bookmarks have the same name, or same url, or does both name and url need to be equal?

Edit: So the extension could work like this - it’s awaiting review, but the eventual AMO page would be here

That ain’t normal. You can certainly customize Firefox to behave that way with custom userChrome.css file, but you would have to do that on purpose.

I suppose it’s also possible that if Firefox is installed via your package manager then they might do some customization to it. I’ve seen some linux distros package these sorts of custom Firefox builds that apply various changes to official Mozilla builds.

Also, with mv3 extensions, the extensions that are not actively doing some work are not really “running” in the first place but are just waiting for some event to happen that they have previously told Firefox to inform them about, but there isn’t any persistent execution context that is constantly running.

I believe one reason why extension support was not-fully enabled earlier was because mv2 extensions required persistent background context for each extension and that could cause issues if Android just decided to kill that process. But with mv3 the extensions are required to be able to be suspended and then woken up on demand.

I don’t know if the syncing part will work for unsigned extensions, but you need to use the same storage area on both endpoints. So if you set kitten key to sync area (browser.storage.sync) - then you need to also read it from the sync area, but in your example you are reading from local area which is for local not-to-be-synced data only.

Right, and that’s fine. The one good thing about these “collections” is when they describe what the pref does (I mean, so does official source typically). But that matters only as long as the audience actually reads those descriptions. But then if you just pick the ones you actually care about (which you should totally do) it becomes irrelevant from which “collection” you found about it from.

None.

I don’t think it’s a good idea to take some huge collection of prefs and just apply them blindly.

Instead, make the changes that you actually want to do, so that you actually know what changes you are causing. If you want to put those into your user.js file then feel free, but in my opinion it’s just better to change them in about:config directly - that is, unless you need to apply the exact same set of changes to multiple profiles.

There isn’t anything to specifically update the favicon of a tab. But you can do the exact same thing websites can update their favicon with; run a content script on the web page that modifies the favicon. Firefox will then show whatever the new icon image is in the tab bar.

I don’t have a better example but the content script of an extension I wrote updates the favicon during media playback in a tab. As an overview it creates a canvas of the original favicon, creates a new link element as the “new favicon”, updates that canvas during playback, and then sets the created link element href attribute to the data uri created from the canvas.

I guess this style might fit the bill

I mean, first you need to set up using custom style sheets - some guidance here, but after you’ve set that up you can try the style I mentioned.

Also, mobile Firefox has supported PWAs for a long time. I wouldn’t say PWAs on desktop would be useless, but they make much more sense on mobile than on desktop.

You need to make sure that both of these prefs are true:

• browser.newtabpage.activity-stream.feeds.section.topstories
• browser.newtabpage.activity-stream.feeds.system.topstories

Also, you should note that user.js sets all the prefs in it at every startup, so if you set these prefs in about:config but they are set to some value in user.js then your changes will be undone on startup.