2) I'll concede the technical reasons. But it's been something like four years now, and you still haven't caught up with what the previous extensions could do. There's still no way to remap keys without waiting for the current tab to load, for example. This is a very important UX feature!
4) The problem is, when you force users to go through the Mozilla gatekeeper, it's all the more important to get this right and not have that gatekeeper sleeping on the job.
Second, the failure behavior was not fail-safe. Users had their previously-signed addons disabled when this struck. Many of these were necessary to protect their privacy, which was then compromised.
(Proper fail-safe behavior would have been to allow already-signed addons to keep working or put up a warning, so don't tell me it would have needed a huge investment of resources to avoid that catastrophe.)
How many other browsers have had a sudden global feature outage like that?
And, to make it worse, your leadership thought it was somehow reassuring to say, "Oh, don't worry, we broke the promises of the user experiments feature to push out a forced update that fixed this!"
>A decision to not sign addons would have consequences as well -- which we knew intimately, because they were very, very real and growing rapidly.
Mozillians keep insisting this but I have yet to see evidence. Has there been even one case of a user a) who is technically adept enough to enable unsigned add-ons, and b) sideloaded an extension, and c) suffered a security catastrophe that merited Mozilla intervention? Most of the naive users you're claiming to protect can't even get past a).
Chrome allows unsigned addons just by toggling developer mode. Where are their massive security breaches from that?
The original promise of Firefox was to give me back control of my machine. Having to go through Mozilla for my custom extension just feels like the days of getting software from shrinkwrap at Best Buy again.
My parody: https://www.youtube.com/watch?v=taGARf8K5J8
When you write about Firefox, you seem to write about various side projects like Firefox-Send, or Pocket that barely add any value to the actual users. Users don't want them (or even ask for them) - yet the teams are very happy to start and make some half-baked greenfield product [after all Firefox Send is a project failure - couldn't stop malware + nobody used it].
This might be a blasphemy, but IMHO even creating Rust is a bad side project. [maybe good for the world, but definitely bad for Firefox - resources are removed from browser development team]
2) Your comment makes me lose hope. Users are very clear: they want extensions. Yet you act as if XUL extensions is the only way to make extensions. Ever.
Do you mean that the whole Firefox team (probably 1000 people) cannot invent a new and secure extension model that allows to adjust the browser per user needs? I get it - creating it is hard. But it is literally your job. When you are a Firefox programmer you should work on the core product. Not on some easy side-project.
From outside perspective it looks that nobody wanted to deal with the difficult problems. Management just let the developers to ignore them and create new, sexy, greenfield side projects.
Another user pointed out that the new extension model does not even allow to remap keys immediately (personally haven't tested it) - most computer games allow this, so don't act as if this was some impossible programming challenge.
3) When you release unfinished, buggy products you alienate your user base. Most users understand that software can have bugs. But why does Mozilla constantly release things that break the users' work-flow? From user perspective it feels like change for the sake of change. You start to wonder what feature will the new patch remove or break.
At the same time your competitor is reliable. They can change the inside, but they don't touch the outside: the user interface stays constant.
4) The problems with extension signatures is a complete fiasco of the Firefox project management. It shows that inside you have zero control over the process - no tools to track workflow, critical tasks and what needs to be done? (are you still stuck on mailing lists?)
This one is 100% on Mozilla and please dont come up with some excuses, because they sounds pathetic.
I repeat: from user perspective it looks like a very small part of Mozilla deals with the actual Firefox and everyone deals with other, random stuff. Some gatekeeper had one job: sign the extensions once per year - and failed.
Also when you sign the extensions using some strange side channels, you sound like hypocrites when you claim that Firefox does not spy on its users.
5) Instead of focusing on core product, old bugs, user requests - the teams prefer to make "sexy" greenfield projects.
Proving proper Firefox installers to companies, means higher market share and consequently more money from Google. It's like someone at Mozilla was sabotaging the company from inside. Sorry, your argument that providing installers cost money is just absurd. Why you dont use the same argument about Firefox-Send, Pocket, or 20 other side-projects that are leeching development time/money from the actual browser? Browser is the one that earns money, but it is stripped from resources that are used for "adventures" of developers. Like the Firefox Send "adventure" that was a failed idea from the start, failed at the end. That money could have been spent working on your core product.
Also, when we speak about installers for corporate multiple people claim that inside Mozilla, there was a stubborn idiot that didnt want it to happen. It is a complete failure of management who didnt identify that person and fire on the spot.
The rest of us are working on stuff like: Fission (process-per-tab, roughly). Pageload performance. Memory usage. Printing. Moving stuff to the GPU. The never-ending treadmill of new web APIs. Porting to new platforms. Fixing bugs.
As for extensions: there is no intention to regain 100% of the power of XUL extensions. Never has been. Many extensions used to get the source code of an internal function, search and replace to update the code, and reinstall it. We're not going to return to that level of power. (Yes, XUL extensions don't have to do it this way; I'm using an extreme example to illustrate the former power.)
But that's not to say that Mozilla doesn't want to increase the power of WebExtensions. I'm not really privy to the decisionmaking there, but look -- we just laid off 250 people. I hope that's adequate proof that we have to make some hard resourcing decisions. And most of the "why don't you just..." requests are not as trivial as they seem, even when the requester's exact use case would be fine. Any extension API that allows deceiving the user or subverting their intentions must be handled carefully to maintain the security of users, and people are pretty darn good at finding unexpected ways to exploit seemingly innocuous capabilities.
I'm not going to debate the history or correctness of all the decisions that bother people. I agree with some, disagree with some, and aligning my views with yours or anyone else's isn't going to have much of an effect on anything. We've screwed up. I'm sure we haven't properly admitted to some screwups. People's experiences and workflows are different, and I know I'm always surprised to discover that 99% of users are not seeing something that bothers me. My intuition of what is or isn't important is not as good as I expect it to be.
1) The majority of developers at Mozilla are working on Firefox. Many more than 50. It is true that we have fewer staff than Google has working on Chrome (Mozilla is less than half, I heard rumoured?).
2) We did kill XUL extensions, after resisting for years. It would have been a self-inflicted fatal wound not to. https://yoric.github.io/post/why-did-mozilla-remove-xul-addo...
3) Anyone who's had to make a decision of when to ship a product will be familiar with the things you need to juggle. There was a much earlier alpha that got close to shipping and then held back. You would have been less happy with that. There are later versions that would have been more complete, at the cost of maintaining two separate code bases longer. Massive opportunity cost. Was it shipped at exactly the right point? Almost certainly not.
1000 might seem like a large number to you, but we are a small organization relative to others in the same space; we can't keep a lot of extra bets going.
4) Superficially: uh, isn't that what bugs are? The only way to prevent your decisions from causing problems is to not make decisions, and then that's a bigger problem. Specifically with the signing, nobody forgot to sign anything, a cert expired. We screwed up.
The decision to sign addons had consequences, yes. A decision to not sign addons would have consequences as well -- which we knew intimately, because they were very, very real and growing rapidly. But I can't make anyone believe that if the starting point is the assumption of incompetence.
5) Shifting resources away from enterprise does not equal "not caring about the product at all". I've long taken issue with that particular (now changed) decision too, but I never assumed that I had enough of the full picture to be confident that I was right and the decision makers were wrong. Contrary to prevailing opinion, just "providing" something is not free. Enterprise support costs resources. Throwing something over the wall and saying "patches welcome!" when it doesn't work for people is worse than not pretending to support it in the first place.
Your beef with side projects is a little bizarre to me. Why do you think they take up such a huge percent of resources? Assuming 95% is not a good faith argument that I can even respond to. Maybe we could agree that 0% would be unhealthy and shortsighted?
I'll stop there. I will suggest that you at least stop repeating things like "development teams are not working on core product" since I know that to be objectively false.
(I'll admit that at present there is one fewer developer working on core product right now, but that'll be fixed as soon as I close this tab.)