I can’t speak how Firefox devs intended it, but in my mind the new profile system is more of an “additional feature available for profiles in the managed profiles directory” - not a replacement for “real” profiles. In my tools, I’ve always linked to additional profiles using firefox --profile path/to/profile thus they are not listed in profiles.ini anyway (or at least they don’t need to be) and this still works fine wherever that directory happens to be located in.

I perceive the new profile system more as a extended capability of the old profiles than completely new and different thing. Although for a typical user it probably seems like a new feature since previously the profiles were quite invisible.

With new profiles, each profile will have a profile group they belong to, which means roughly “these profiles are linked”. Profile data is stored in separate directories just as before, but the linked profiles can open browser instances of each other and they can have some information shared between them, such as shared preferences, which is stored separately from the profiles themselves. I don’t think it’s there yet, but I believe you could then also have a profile-1 to open new tab in profile-2 etc.

Different Firefox versions can’t share profiles in the same group, so release Firefox has its own group, Developer Edition has its own group etc. In addition, I believe this new profiles capability is limited to “standard” profiles only, i.e. those that are stored in the default location and/or are reachable via profile-manager. They cannot be used with profiles loaded from arbitrary directories via command-line flags.

Indeed, but what I don’t get is why on earth do people spew this damn crap about manifest v3 as a whole, when the actual issue is just the removal of "webRequestBlocking" feature that Google is about to bring along with their implementation of mv3. Why the hell aren’t folks mad about the actual issue but instead just want to be mad about the whole bloody thing, which actually also does bring some very real privacy improvements among other nice things.

If a website has a compatible PWA manifest the there will be an item labelled “install” in the three-dot menu of Firefox in place of usual “add to homescreen” item.

Edit: There’s a few other requirements as well for the website to be considered installable as PWA, such as it must have a registered service worker so it can work offline. But regardless, if the website provides all the requirements then it can just be installed straight from the menu.

Notepad++ works great for taking notes. Besides, it’s open 24/7 anyway so dedicating a tab or two (or dozen lol) feels pretty natural.

I only use Joplin if I have some “very structured” notes about some topic, and while that is also open 24/7 np++ is always my go-to because “it just works” without having to care at all about formatting nor anything fancy.

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.

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.

From Firefox 113 onwards -moz-box related properties won’t work because the UI switched to using standard flexbox instead. So your -moz-box-ordinal-group: 2 won’t do anything. Use order: 2 instead.