Hacker News Reader

Comment by rurp | Hacker News Reader

The amount of regressions Mozilla has inflicted on Firefox in recent years blows my mind. One of their few big advantages over Chrome is better user control, but they have been working continuously to destroy that.

Getting rid of most extensions and removing about:config are two big wtf decisions. All that does is piss off power users, which are the main advocates for this browser. Plus so many other baffling changes to remove or worsen existing features, along with the pointless UI reshuffles.

Edit: I should clarify that about:config has only been removed from mobile Firefox, so far at least.

View on HN

> removing about:config

about:config is right where it's always been, unless I've missed something?

You've missed nothing, OP is full of it.

They're talking about the mobile application, where only a small subset of extensions was available for a few years. Access to about:config was disabled in official builds (but forks and custom builds such as some on F-Droid still have it).

https://github.com/mozilla-mobile/fenix/issues/21276

> Access to about:config was disabled in official builds (but forks and custom builds such as some on F-Droid still have it).

From your link, there are problems that are specific to `about:config` only on mobile, due to Android OS and GeckoView API specifics:

  - There are preferences that …is reset when the app restarts.
  - There are many preferences that …do nothing.
  - There are preferences …which breaks interacting with some websites.
  - There are platform preferences that …result in startup crashes …and reinstalling results in the deleting of data like bookmarks, passwords, history, etc.

https://bugzilla.mozilla.org/show_bug.cgi?id=1813163

  Look, it’s not like we’re insensitive to the desire for configuration; it’s that we know that on Android there are footguns that don’t exist on desktop!

  We want to figure out a way to do this in a way that makes it difficult to break GeckoView. I’m sorry that this isn’t good enough for many of you, but with all due respect, you’re not the ones on the receiving end when somebody breaks their browser because they didn’t know what they were doing!

https://old.reddit.com/r/firefox/comments/i51k0q/mozilla_cou...

Kinda reasonable, honestly? It sounds like more than just "page may render funny" types of footguns. Unknown quantities of unlabelled "Lose All My Data" buttons are probably what this site would call an antipattern.

> They're talking about the mobile application, where only a small subset of extensions was available for a few years.

On the above Reddit link, they also explain the extensions thing was because they were "literally not done implementing the APIs yet" and focused on the "highest priority extensions". So, the "big wtf decision" might be why they released it in that state, rather than "getting rid of most extensions".

Hide those options then? I can imagine many ways to "fix" the issue of having all those bugs without ham-fistedly removing the entire feature

These seem like bugs that could be fixed, but it also seems like there should be relatively simple ways to work around them without disabling about:config, e.g.:

If some settings can cause a crash (and you don't have a complete list), create a separate launcher that only edits the settings in about:config without ever trying to run other Fenix code, so the user always has a way to revert settings if they're causing a crash on startup.

If some settings can be applied but are reset the next time the app runs, save the setting value itself and then re-apply it on each startup.

Other problems like settings doing nothing or breaking websites are just ordinary bugs. Until they're fixed, the user can just refrain from using those settings, or revert them if they cause problems. These sorts of issues are acceptable for users knowingly mucking around in about:config, it's fine, fix the bugs when you get time. It's no reason to disable access to the other settings that actually work in the meantime.

I don't think anybody's saying the issue is technically infeasible to fix or work around.

They just haven't had anybody to spend engineering time doing so yet. Perhaps:

https://codetribute.mozilla.org/projects/fenix

https://firefox-source-docs.mozilla.org/setup/contributing_c...

We may disagree with Mozilla's priorities, but they do have finite resources. E.G. Should the extensions API have been delayed even more than it already was, to first build this separate `about:config` launcher as a kludge?

They're not being wilfully bullheaded in this case, is what I mean. The "P5"/"Enhancement" Bugzilla issue is open, but unassigned.

> They just haven't had anybody to spend engineering time doing so yet.

But this has been the other major criticism of Mozilla. They take the money they get from Google and spend it on not-Firefox when Firefox market share should be their top priority, because if that number goes to zero they're defunct.

>you’re not the ones on the receiving end when somebody breaks their browser because they didn’t know what they were doing!

about:config already has a warning when you first open it that you'll screw up your settings if you don't know what you're doing. So if someone borks their install as a result, it isn't Mozilla engineer's job to apologize or hand hold them through it.

Every software until the 2010s (Windows itself, with its registry) has had this implicit disclaimer that you forfeit all official support if you dick around with the internals in an non standard way. So why is it now at the other extreme of 'fuck all power users, we will only target those who can't walk and chew gum simultaneously' ?

Yes! FF PMs and designers seem to HATE user customization, add-ons and power user capabilities yet those are the main reasons I came to FF and why I still use it. While FF is still the best browser for me (barely), it's only achieved this by all the alternatives enshittifying and dumb-ifying their browsers even faster than FF. As it is I have to spend significant effort under the hood customizing UserChrome scripts just to maintain minimal usability. (...and thank the heavens for Lepton (https://github.com/black7375/Firefox-UI-Fix), a regularly maintained, well-curated, all-in-one collection of essential Firefox fixes (which can each be turned off individually via flags.)

Firefox has enshittified itself if your reference point is the original Firefox of the early 2000s that unseated Internet Explorer's dominance. User customization has steadily eroded since version 4 when they started copying Chrome, from multi-process to removing the statusbar to introducing the hamburger menu to the insane practice of incrementing major version numbers into the triple digits.

>While FF is still the best browser for me (barely)

Give Pale Moon a try and ignore the FF fanboy propaganda of it being oLd aNd iNSeCuRe. It isn't, it's regularly updated to keep up with Google dominated web standards and security patches, and runs on an independent fork of Firefox's Gecko rendering engine. It is not a mere rebuild like Librewolf, Waterfox etc but a separate browser that retains all the full customizabiity of pre 2017 Firefox with full XUL extension and NPAPI plugin support.

Sounds like they hired GNOME devs.

> Getting rid of most extensions

What extensions did they get rid of?

They changed the extension model which broke the extensions using the old model. Many of the developers didn't have the resources to rewrite the extension from scratch, or the new model had restrictions that made what the extension was doing difficult to impossible, so they disappeared.

That was the switch from their own API and unsandboxed model to the standards-based one, right?

I think all in all getting sandboxing as well as making it easier to provide cross-browser extensions was worth the breaking change.

Mandatory sandboxing increasingly seems like a misfeature. Now you can't install an extension that does a lot of things that are useful, ostensibly to protect you from malware.

Optional sandboxing can be good because users can have more confidence that something can't hurt them. But it can also be bad because users will have more confidence that something can't hurt them, and then it does anyway.

Meanwhile the ability to exercise arbitrary permissions given the user's authorization is something we've lost. And what have we gained, when the user just runs how_to_actually_uninstall_mcafee.avi.exe and gets the malware regardless?

No, you can still grant permissions to web extensions, but the difference is that it's now explicit, and it is at least possible to design extensions with minimally-required privileges. This vastly reduces the blast radius of an extension publisher takeover or an insider attack, for example.

> what have we gained, when the user just runs how_to_actually_uninstall_mcafee.avi.exe and gets the malware regardless?

Nothing would happen if I double-click that file, since it doesn't run on my OS. On the other hand, a compromised browser extension could deal an incredible amount of damage to me.

Are you saying that because we can't protect all users from all harm, we should just give up?

> No, you can still grant permissions to web extensions, but the difference is that it's now explicit, and it is at least possible to design extensions with minimally-required privileges.

The problem is the reverse. Some permissions are now considered "too dangerous" for the extension, so there is no facility to grant them even if the user wants the extension to do that and it has a good reason to.

> Nothing would happen if I double-click that file, since it doesn't run on my OS.

In which case the website could have fingerprinted your browser and served you the one that does.

> Are you saying that because we can't protect all users from all harm, we should just give up?

I'm saying that we should give people the tools and information they need to decide if and to what extent they can trust something, instead of presuming to decide for them.

I agree, and that mechanism is to introduce a new, permissioned API into Firefox's Web Extension API implementation.

Requiring them to maintain two completely different extension APIs (the old XUL-based one and Web Extensions) would work too but seems excessive.

> I agree, and that mechanism is to introduce a new, permissioned API into Firefox's Web Extension API implementation.

The problem is new WebExtensions APIs are not welcome.

If XUL were to continue as it does on Pale Moon, here is no need for Web Extensions given they are a reduced subset in terms of functionality compared to the previous XUL/XPCOM versions.

And ironically for all the talk of making it more secure, the amount of cross browser malware has only shot up since Mozilla decided to dump XUL in favor of copying Chrome's extension system.

WebExtensions is Chrome based not standards based. And Firefox had sandboxed and unsandboxed extensions before.

What Mozilla promised would have been worth it. Parity with Chrome's APIs. APIs to support popular features of old extensions. Support for extension developers to develop new APIs. But they abandoned these promises.

And they managed the transition badly. They chose an arbitrary deadline before evaluating scope or designing a migration path. They held the arbitrary deadline as they missed estimates. Extension developers didn't know when or if APIs they needed would be implemented. And no version of Firefox supported old extensions and reasonably complete WebExtensions APIs. These decisions made many problems for developers and users. And this was shortly after many developers spent much effort making their XUL extensions multi process compatible or converting them to sandboxed extensions.

> and removing about:config

What?

On mobile.

> Getting rid of most extensions

I am still butthurt

Welp. Name checks out.

Second-order name checkout

Third order if improperly prepared crustacean.

Stay away from Red Lobster. (Personal experience.)

Reply on news.ycombinator.com