Comment by ChrisSD | Hacker News Reader

Comment by ChrisSD | Hacker News Reader

Parent Full thread

> What this text carefully avoids stating directly: that’s the only nine (as in: single-digit 9) add-ons which you will be able to install on Firefox for Android now. After being able to use thousands of add-ons before, this feels like a significant downgrade. Particularly given that there appears to be no technical reason why none of the other add-ons are allowed any more, it being merely a policy decision. I already verified that my add-ons can still run on Firefox for Android but aren’t allowed to, same should be true for the majority of other add-ons.

There is a technical reason. They need to thoroughly test the new implementation of the APIs before they enable broader support. Just because the author did some (brief?) testing of a few more addons, it doesn't mean that the APIs themselves are production ready.

The main issue is that the new Firefox was released too early so compromises had to be made. Thoroughly testing a handful of addons is easier than thoroughly testing the entire web extension surface area.

This isn't a great situation to be in but there's no need to imagine nefarious plans to explain it.

The argument being presented would just as well support Microsoft releasing an automatic update to windows (automatically deployed to all their users) that only supported some tiny fraction of white listed applications. They then don't clearly make any promises about removing the white listing, or any timelines, but only vague statements about "ensuring a positive user experience" and "working with their application development partners".

Most people would probably see this as a Very Bad Thing, for a few reasons. First of all, if we were to take the claim that it's "to ensure stability of APIs" at face value, it would indicate a staggering lack of maturity in their decision making process around releases. Next, we shouldn't take the "API" argument as being anything representative of reality: applications people develop (or browser extensions) have always been the responsibility of the developers developing them. If there were bugs in a browser, they'd discover and work around them, or they'd have a broken extension/application. There isn't a way around that. Perfect APIs don't fix it: people write bugs into their applications/extensions/platforms all the time. Things are broken all the time. Testing has never been Mozilla's responsibility. It's always been on extension authors. There are already ways to "declare" in an extension that support of a specific version exists.

There is no competent technical reason to end up in this situation. We're only left with incompetence and malice. And it's _very_ difficult to think that the people running a popular mobile browser could be so incompetent. Though I'm sure we've all said that before about other Mozilla decisions.

The decision that lead to this was releasing the new browser before it was ready. This was done because Mozilla can't afford to be maintaining and supporting two different browsers on the same platform at the same time. This is nothing to do with extensions per se. They are just a casualty of pragmatism; given the initial decision the team had to prioritise.

Secondly, Mozilla absolutely do have a responsibility to ship APIs that work to spec. It's not up to Addon authors to fix Mozilla's bugs (and that may not even be possible depending on the nature of the bug). And of course you're assuming Addon authors would be interested in going so far out of their way to support what is a relatively small user base.

This argument is continuing to ignore the solution that's already used to handle new APIs that are unstable and might not be ready: allowing developers to opt-in to deployment on that platform via standard metadata included in apps/extensions. If there was a concern with things being unstable, that would be the first thing to go to! There's already support for similar things. Creating special whitelisting is something extra that had to be done. Given the "we have too much work" angle here, I find it hard to understand why the existing mechanisms weren't extended instead of creating a new one.

It seems very funny to say "we had to give up and release a broken browser" and in the same breath take on extra responsibility for API correctness prior to letting any one who can't convince Mozilla to whitelist them to use the APIs. And take on responsibility of maintenance of a whitelist

Who do you think people complain to when their browser doesn't work right? It doesn't matter if an addon is responsible, many people will blame the browser (or at least go to them for support). This increases the support cost and leads to a very negative perception of the browser itself. Also I'd suggest that addon authors publicly complaining about broken Firefox APIs would be a whole other headache for Mozilla.

We've been here before with desktop Firefox when the browser got a lot of flak for issues that were mainly caused by addons.

>This increases the support cost and leads to a very negative perception of the browser itself.

Their solution to that problem hasn't exactly led to a positive perception of the browser either, and it hasn't even left them the out of blaming it on anyone but themselves.

Sure. But there's no good solution here. As I said, the decision to support only one browser on Android is what lead to this. That browser isn't fully ready so all the team can do is go for the least worst option (which is admittedly a judgement call).

Besides, it would not be a good look to be blaming extension authors for Mozilla's problems. So I don't think that's a viable "out".

I downloaded this fork which adds way more extensions to the whitelist and many I've tested work totally fine such as the extension I made (SponsorBlock)

https://github.com/interfect/fenix

Is it "Iceweasle Mobile" or "Iceweasel Mobile?" Both spellings appear in the README several times...

Reply on news.ycombinator.com