4 ms·

> he way supported add-ons work right now is that there's a list (AKA a collection) of supported add-ons maintained by Mozilla that you see on a phone by defaul

> he way supported add-ons work right now is that there's a list (AKA a collection) of supported add-ons maintained by Mozilla that you see on a phone by default. They're not maintained by Mozilla, but they're "recommended" and are reviewed more thoroughly. (I used to work on Firefox for Android)

teruakohatu 5y ago
> (I used to work on Firefox for Android) Can you offer any insignt into why Mozilla makes up jump through all these hoops just to install extentions?
- iggldiggl 5y ago
  Unfortunately it seems that at some point they've also talked themselves into believing that continuing to run add-ons within the main browser process has suddenly become the height of irresponsibility and absolutely and totally unsafe, so a few add-ons are grudgingly permitted with additional scrutiny given during review, but - they don't want expand that process further, because it's counter to the direction that AMO has been moving (from manual pre-publication review of all public add-ons towards automated checks and only manual post-publication spot checks) - running add-ons in a separate process as on Desktop isn't possible, because on Android secondary processes can get killed at any time, which add-ons aren't set up to handle correctly For some reason I've only seen this explanation buried somewhere inside some Mozilla's Discourse forum (I think, if I remember correctly), but I think not much (if at all) as an explanation in the Github issue tracker and certainly never on the official Add-ons blog. Though I have to admit that even if the above explanation was given a wider airing, for me it already smacks too much of "the safest computer is one you never turn on" and I'd still be unhappy about the add-ons situation and continue complaining.
  - dblohm7 5y ago
    > running add-ons in a separate process as on Desktop isn't possible, because on Android secondary processes can get killed at any time, which add-ons aren't set up to handle correctly That's true (though it will probably improve as WebExtensions evolves toward service workers), but engineering wasn't hung up on that.
- dblohm7 5y ago
  On the engineering side, there aren't any good reasons. Engineering didn't put in all the effort to implement the add-ons APIs on Mobile only for it to be restricted to such a small set. It's product management's decision.

teruakohatu 5y ago

> (I used to work on Firefox for Android) Can you offer any insignt into why Mozilla makes up jump through all these hoops just to install extentions?

iggldiggl 5y ago
Unfortunately it seems that at some point they've also talked themselves into believing that continuing to run add-ons within the main browser process has suddenly become the height of irresponsibility and absolutely and totally unsafe, so a few add-ons are grudgingly permitted with additional scrutiny given during review, but - they don't want expand that process further, because it's counter to the direction that AMO has been moving (from manual pre-publication review of all public add-ons towards automated checks and only manual post-publication spot checks) - running add-ons in a separate process as on Desktop isn't possible, because on Android secondary processes can get killed at any time, which add-ons aren't set up to handle correctly For some reason I've only seen this explanation buried somewhere inside some Mozilla's Discourse forum (I think, if I remember correctly), but I think not much (if at all) as an explanation in the Github issue tracker and certainly never on the official Add-ons blog. Though I have to admit that even if the above explanation was given a wider airing, for me it already smacks too much of "the safest computer is one you never turn on" and I'd still be unhappy about the add-ons situation and continue complaining.
- dblohm7 5y ago
  > running add-ons in a separate process as on Desktop isn't possible, because on Android secondary processes can get killed at any time, which add-ons aren't set up to handle correctly That's true (though it will probably improve as WebExtensions evolves toward service workers), but engineering wasn't hung up on that.
dblohm7 5y ago
On the engineering side, there aren't any good reasons. Engineering didn't put in all the effort to implement the add-ons APIs on Mobile only for it to be restricted to such a small set. It's product management's decision.