(Also a former Mozilla developer, worked Fennec and Fenix)
I think a more nuanced perspective here is that roughly 80% of the work was done, and the remaining 20% require significant effort and organizational energy.
Not all of the WebExtension API surface is currently supported; there's a long tail of infrequently used extensions that require non-trivial engineering effort and often cross-team coordination to implement. However, the actual usage of these APIs in Fennec was very, very low, so the actual bet and the organization sales pitch for this work must be on building a platform, and evidently that's not happening. You can argue that this type of platform work and extensibility is why people use Firefox for Android. You can also look back at the actual usage telemetry (current whitelist is basically what vast majority of people used) and wonder if that additional investment will move the needle.
There's also front-end/back-end engineering required to fully expand existing UIs into a proper "store" experience.
Personally, I think as a matter of principle Firefox for Android should be fully open in terms of what extensions it allows installing.
I believe that will eventually happen - it's where the prevailing winds are blowing inside the org, too! but it may take time for the stars to align, people to have energy to fight through the internal malaise, to pitch work that may not immediately help with any OKRs and is mostly about building community goodwill and sending a message, etc.
As always, it basically comes down to lack of strong leadership.
> Not all of the WebExtension API surface is currently supported; there's a long tail of infrequently used extensions that require non-trivial engineering effort and often cross-team coordination to implement.
While API support in GeckoView/Fenix might be incomplete as compared with Fennec, then again the API support in Fennec was equally incomplete when compared to Desktop, and yet with Fennec there were no restrictions in installing addons.
> There's also front-end/back-end engineering required to fully expand existing UIs into a proper "store" experience.
I suppose you could always try polishing thins up even more, but given that addons.mozilla.org already had (actually still has) a mobile view/responsive layout that seemed perfectly adequate, this still seems somewhat strange.
Right, I think it's pretty close to parity! I vaguely recall seeing some odd API that wasn't supported in Fenix that was in Fennec, but they're pretty rare. Fairly sure you could access history in Fennec via a webextension, and I think that's not supported in Fenix.
I think what's generally missing in these discussions is that the whole project to bring extensions into Fenix was extremely user-driven - whatever people actually use in any significant volume on Fennec, Fenix supports. And the actual UX of installing extensions is just so much more streamlined and nicer in Fenix.
If you purely look at it from the "most value for most users" perspective, Fenix extensions are a great success. And, it's also a success in purely engineering terms - code that's not bringing a lot of value but yet creates an overall maintenance drag is omitted.
What may have been missing from it is the ideological bit - for a platform to be truly open - and to be a viable platform!, it can't have a restricted "whitelist". And I agree with this. But it's not clear that "mobile-browser-as-a-developer-platform" is a sustainable long-term pitch for an organization as small and as resource constrained as Mozilla.
So, there's a tension between these two perspectives. In purely "rational" terms, what's there is good, and there are a ton of other much more pressing issues to work on for the small teams - bugs, performance, missing functionality that can actually "move a needle", etc.
You can make an argument that in this case, the rational, data-driven engineers won. Which is the opposite of what HN seems to think of Mozilla!
What's probably needed for full webextension support is a strong, perhaps not purely rational leader that will rally folks and actually push the teams to do the work that may be useless, or useful to a tiny percentage of the user base, in a belief that it'll produce a better future. Which may or may not pan out!
> If you purely look at it from the "most value for most users" perspective, Fenix extensions are a great success.
Except for the part where so many extensions that already have the needed APIs implemented still can't be installed.
Changing that setting would move the needle with minimal developer effort.
> But it's not clear that "mobile-browser-as-a-developer-platform" is a sustainable long-term pitch for an organization as small and as resource constrained as Mozilla.
They were trying to make an entire OS, and now they can't keep the browser shell updated?
There's correction and then there's overcorrection.
Also I want my desktop and phone browser to work together well, so failure to make the phone work pushes me away from everything.
> What may have been missing from it is the ideological bit - for a platform to be truly open - and to be a viable platform!, it can't have a restricted "whitelist".
> What's probably needed for full webextension support is a strong, perhaps not purely rational leader that will rally folks and actually push the teams to do the work that may be useless, or useful to a tiny percentage of the user base, in a belief that it'll produce a better future. Which may or may not pan out!
While I appreciate the development work you and other Mozilla engineers have done on Firefox, this kind of attitude is causing Firefox to bleed users. This argument dismisses honest feedback from users as "ideological" and "not purely rational" because it doesn't align with Mozilla's product decisions. Desiring access to more add-ons is a utilitarian position to take, not an irrational one. On the other hand, continuously ignoring your users is a surefire way to lose them as soon as they find a viable alternative to your product, and that's what I would call irrational.
Allowing users to opt out of the extension whitelist on the stable channel of Firefox for Android is a low-effort, high-impact change that would greatly benefit users who use add-ons other than the 18 whitelisted ones, while not harming the users who choose to stay with the whitelist (enabled by default) in any way. By refusing to make the whitelist optional, Mozilla is making Firefox for Android significantly less useful to users who want to use non-whitelisted add-ons, while not improving the experience for the users who choose not to opt out.
Senior at a lot of the larger companies I've interacted with is often a kind of a "terminal level", meaning that you're not expected to rise above it, and can comfortably spend most of your career at that level.
Staff, sr staff, principle and other monikers are usually about affecting change at the scale larger than your team, operating at larger scope, and growing people around you.
When I explain various aspects of concurrency and multi-threaded programming to non-programmers, using analogy of people doing some tasks really helps.
I've picked this up from Feynman's lectures on computing - highly recommend them!
I use passpack to generate/store passwords, remember them in Firefox, and let Firefox Sync get them onto my different devices. Works pretty well!
My host of devices includes multiple laptops (Linux, OS X) and many different phones - both Android and iOS. Since Firefox runs everywhere, this works nicely. Firefox Sync has end-to-end encryption, but data stored at-rest on devices is guarded purely by physical access, which is fine for my use cases.
We also finally turned on "offline cache" support in Firefox For Android (for 50+ releases) - if you have a page in your cache, and you're attempting to load that page while offline, it should "just work". See https://bugzilla.mozilla.org/show_bug.cgi?id=1232867
The old Firefox sync protocol used secure keys to encrypt user data; the new protocol uses one's Firefox account password to encrypt it. A memorable password is a low-entropy password, which means it is an insecure encryption key.
Mozilla's protocol purports not to reveal passwords to Mozilla itself, but the security of the system rests on Javascript files delivered from … Mozilla. They can, if they wish, target a user and serve him suborned Javascript which send the plaintext password back. Unlike a tampered build of Firefox itself, which might actually be noticed, this could be a one-shot attack.
Worse, not just Mozilla as an organisation can do this: it can be compelled to do so on behalf of any government which has the power to compel it (or those employees capable of targeting someone).
How long ago? I've been here 12 years (first school, now work), and it's changed a lot, almost all for the better. There's a decent arts/music scene, a dozen good restaurants, affordable housing, lots of new construction, light rail coming online next year.
Not much to do in Waterloo. It's good if you're introverted and just want to game/do projects/self-improvement after work, though. Which isn't that bad thinking about it.
Thinkpad W541 (i7, 32gb RAM, SSD), running Fedora, often connected to an external monitor, mouse and keyboard.
For travel, I use Thinkpad X1 Carbon (3rd gen), also running Fedora.
Nowadays I mostly work on native Android dev, so environment is primarily just AndroidStudio, vim, terminal (Guake) and what seems like hundreds of open tabs.
It used to be all Macbooks for many years though. I still have a 2012 tricked out Air and a 2013 rPro, which I need to sell off.
I think a more nuanced perspective here is that roughly 80% of the work was done, and the remaining 20% require significant effort and organizational energy.
Not all of the WebExtension API surface is currently supported; there's a long tail of infrequently used extensions that require non-trivial engineering effort and often cross-team coordination to implement. However, the actual usage of these APIs in Fennec was very, very low, so the actual bet and the organization sales pitch for this work must be on building a platform, and evidently that's not happening. You can argue that this type of platform work and extensibility is why people use Firefox for Android. You can also look back at the actual usage telemetry (current whitelist is basically what vast majority of people used) and wonder if that additional investment will move the needle.
There's also front-end/back-end engineering required to fully expand existing UIs into a proper "store" experience.
Personally, I think as a matter of principle Firefox for Android should be fully open in terms of what extensions it allows installing.
I believe that will eventually happen - it's where the prevailing winds are blowing inside the org, too! but it may take time for the stars to align, people to have energy to fight through the internal malaise, to pitch work that may not immediately help with any OKRs and is mostly about building community goodwill and sending a message, etc.
As always, it basically comes down to lack of strong leadership.