Closed Bug 1540065 Opened 8 months ago Closed 2 months ago

Make about:config access configurable via runtime settings

Categories

(GeckoView :: General, enhancement, P3)

All
Android
enhancement

Tracking

(firefox70 wontfix, firefox71 fixed)

RESOLVED FIXED
mozilla71
Tracking Status
firefox70 --- wontfix
firefox71 --- fixed

People

(Reporter: JanH, Assigned: snorp)

References

Details

Attachments

(2 files)

There might be embedders that legitimately don't want to expose this, but in the general case I don't think this should be hard-locked on the Beta/Release vs. Nightly GeckoView distinction, and tied to a runtime setting instead that the embedding app could then enable/disable as desired.

As a workaround, can the app intercept about:config when the user enters the URL in the address bar?

Priority: -- → P3

You mean for blocking access? That would work, too, if we're okay with having this opt-out I guess?

Why was this blocked in non nightly builds in the first place? It's an essential tool for me to have full control over my browser, even on mobile

(In reply to Jan Henning [:JanH] from comment #0)

There might be embedders that legitimately don't want to expose this, but in the general case I don't think this should be hard-locked on the Beta/Release vs. Nightly GeckoView distinction, and tied to a runtime setting instead that the embedding app could then enable/disable as desired.

We could consider this or the suggestion Chris makes in comment #1, but so far I haven't heard a convincing argument for doing so.

The reason about:config is blocked in the first place is because we purposefully don't provide an API to apps for setting prefs, and it seemed wrong to allow users to make a configuration change that the app is unable to do itself. We allow about:config in local and Nightly builds because it was necessary in order to test some experimental platform features such as WebRender.

So basically if I'm understanding you correctly, you are saying that only settings available via UI should be configurable?

For my use cases at least, that severely limits what I can do

How exactly is it "wrong" to allow us o make changes to our setup, especially the more advanced users who regularly tweak those sort of things? And how is that ok in any other version of firefox besides preview?

I eagerly await your response

I'm a power user and I welcome this change. Most advanced users don't use stable anyway.
I also do support as part of SUMO and a lot of n00b users change things they don't understand and then ask for help. When a profile refresh fixes their issue, they blame Firefox for not being able to keep it's profile intact.
People that want to test experimental features, should not do it on stable. They might bump in bugs already fixed in Nightly.

Um the issue is in Firefox Preview for Android atm.....

Which isn't particularly stable.....

And btw I tweak those settings, know what I'm doing, and DON'T use nightly because I need a stable browser not one that might break next update, had that happen

And also chrome://flags is not restricted to Canary why should about:config be restricted to Nightly?

And it's not just experimental features there it's just really more advanced settings.

(In reply to bamnell from comment #5)

So basically if I'm understanding you correctly, you are saying that only settings available via UI should be configurable?

I'm saying we shouldn't allow a user to configure Gecko in a way that is unsafe. There is a spectrum of solutions here, though, and it's possible we don't currently have the right balance. We could consider allowing about:config all the time but only for a whitelist of prefs, for instance.

For my use cases at least, that severely limits what I can do

Can you list some of the prefs you'd like to change which don't typically have their own UI?

How exactly is it "wrong" to allow us o make changes to our setup, especially the more advanced users who regularly tweak those sort of things? And how is that ok in any other version of firefox besides preview?

Right now it's very easy to break Fennec with one about:config change. I don't want the same thing to be possible in Fenix. I realize this is limiting for a small percentage of users, but we're choosing to err on the side of safety right now. Nothing is set in stone, however, so if people who use about:config can let us know what they'd like to see, we can evaluate some possible changes.

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) (he/him) from comment #8)

Can you list some of the prefs you'd like to change which don't typically have their own UI?

Not :banmel, but I looked at my user.js, and here are the ones I would care to change on mobile and are unlikely to be exposed in the UI:

  • beacon.enabled
  • browser.urlbar.matchBuckets
  • dom.forms.autocomplete.formautofill
  • extensions.formautofill.creditCards.available
  • extensions.pocket.enabled
  • javascript.options.asyncstack
  • network.IDN_show_punycode
  • network.security.esni.enabled

(In reply to Laurentiu Nicola from comment #9)

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) (he/him) from comment #8)

Can you list some of the prefs you'd like to change which don't typically have their own UI?

Not :banmel, but I looked at my user.js, and here are the ones I would care to change on mobile and are unlikely to be exposed in the UI:

Thanks for the response! Many of these are completely unused in GeckoView, but there may be a couple that make sense to expose in some kind of way. In particular, network.security.esni.enabled is an experimental feature that we probably don't mind people flipping on (though I haven't checked with the networking folks).

I would be a lot happier if we had something like about:features where we could surface things like that.

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) (he/him) from comment #10)

Thanks for the response! Many of these are completely unused in GeckoView, but there may be a couple that makes sense to expose in some kind of way. In particular, network.security.esni.enabled is an experimental feature that we probably don't mind people flipping on (though I haven't checked with the networking folks).

I would be a lot happier if we had something like about:features where we could surface things like that.

Sure, having an about:features is fine, but it was a product decision to not enable network.IDN_show_punycode by default, which for some users is more of a security risk than avoiding an annoyance.

(In reply to bamnell from comment #7)

And btw I tweak those settings, know what I'm doing, and DON'T use nightly because I need a stable browser not one that might break next update, had that happen

And also chrome://flags is not restricted to Canary why should about:config be restricted to Nightly?

And it's not just experimental features there it's just really more advanced settings.

Another thing is that multiple profiles aren't really supported on Android, and multiple installs of the same application package aren't possible at all.
The former is a problem because I might like to keep separate profiles for my normal browsing and for experimental testing, and in the absence of real profile support it's easier to just keep Nightly completely for experimental browsing and testing, and use Beta or Release for my normal profile (where I'd still like to tweak some things that aren't possible through the UI, though).
Perhaps even worse is the fact that you can't have multiple installs of the same package, so whenever I need to track down a regression via mozregression or by doing it manually, I have to uninstall my current Nightly (or sometimes Beta) in order to replace it by the Nightly/Beta version I want to test. With the way Android works, doing this also kill all previous app data, i.e. my browser profile. At least personally I use a rooted phone, so can at least restore a full backup of my original profile afterwards, but that's not true for everybody and still somewhat of a hassle - and Sync still needs to be manually reconnected afterwards anyway, which is even more annoying (especially during the time when my former e-mail provider used to randomy greylist the sync confirmation link mails for hours).
Hence one more reason not to use Nightly for regular browsing on my phone.

As for the kind of prefs I've modified,

  • occasionally played around with some of the font.size.inflation.* tweaks beyond the main pref that can be controlled via the regular settings
  • the ui.touch/mouse.radius.* prefs
  • browser.sessionhistory.max_total_viewers back when it was still set to 1 by default because the original Fennec ran on a phone with only 128 MB (!) RAM - and while I also tried it Nightly, being able to tweak this in my main profile (not Nightly, see above for why!) as well and and observing its effects was one reason I finally submitted a patch for increasing the default value
  • some of the apz.* scrolling behaviour tweaks
  • apz.one_touch_pinch.enabled when it was temporarily disabled on Release because of some bug that didn't really affected me
  • potentially network.trr.mode if it starts interfering in unwanted ways with my DNS configuration
  • ui.scrollbarFadeBeginDelay and ui.scrollbarFadeDuration because I think the scroll bars disappear too soon by default, and also look nicer if they actually fade out instead of directly disappearing
  • view_source.wrap_long_lines before I eventually submitted a patch to change its default value to true

and some things that are rather Fennec-specific and not directly applicable to a GeckoView world, but still examples where having about:config access was useful

  • browser.sessionstore.max_tabs_undo (I prefer a slightly larger value than the default)
  • browser.tabs.useCache (never permanently enabled on Release because of some major bugs for some users which nobody had the resources to ever track down, but for me this works well enough to keep it enabled regardless)
  • Fennec does its own default app selection for downloading, but we never implemented a UI for resetting those choices, so the only way to do that is via about:config
  • getting some session store debug logs from regular Beta/Release users - it's already bad enough that accessing logcat logs isn't exactly easy for normal users (and the move to Webextensions killed jchens useful add-on), but at least that way the could use their normal browser and didn't have to install Nightly as well
  • disabling automatic add-on updates, because unfortunately on Android there's no UI to manage updates per extension, so if you have >=1 extension that you want to keep on a specific version for whatever reason, the only choice is to completely turn off updates (but at least you have a choice)

I use prefs related to privacy (such as resist fingerprinting and tracking protection) and disabled webgl

That's all I can think of off the top of my head

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) (he/him) from comment #8)

I'm saying we shouldn't allow a user to configure Gecko in a way that is unsafe. There is a spectrum of solutions here, though, and it's possible we don't currently have the right balance. We could consider allowing about:config all the time but only for a whitelist of prefs, for instance.

Right now it's very easy to break Fennec with one about:config change. I don't want the same thing to be possible in Fenix. I realize this is limiting for a small percentage of users, but we're choosing to err on the side of safety right now. Nothing is set in stone, however, so if people who use about:config can let us know what they'd like to see, we can evaluate some possible changes.

I'm surprised and disappointed to hear this kind of attitude from Mozilla. One of the main advantages Firefox has over the competition is the increased control over configuration.

It seems you are now adopting a culture of "we know what's better for the user than he does" in the name of protecting the average user from breaking his browser. The average user isn't going to just stumble across "about:config". Add warnings if you feel you must. But completely restricting access just doesn't make sense.

A white list of prefs doesn't make sense either. There will always be prefs that some users want to adjust that you have not anticipated.

As long as all crashes/bug reports show prefs that have been adjusted to non-default values, I see no down side to allowing full about:config access in release builds.

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) (he/him) from comment #8)

I'm saying we shouldn't allow a user to configure Gecko in a way that is unsafe. There is a spectrum of solutions here, though, and it's possible we don't currently have the right balance. We could consider allowing about:config all the time but only for a whitelist of prefs, for instance.

Right now it's very easy to break Fennec with one about:config change. I don't want the same thing to be possible in Fenix. I realize this is limiting for a small percentage of users, but we're choosing to err on the side of safety right now. Nothing is set in stone, however, so if people who use about:config can let us know what they'd like to see, we can evaluate some possible changes.

  • There's an exhaustive list here. That's about 200 items, so good luck. It's actively maintained, and if you want to think through the details of such a critical change to about:config functionality, that's the main place you should reach out to in the Firefox community. (Just open an issue in the Github repository, so we don't clutter Bugzilla.)

  • Generally speaking, exhaustive preferences are needed for anything where Firefox engages in network requests that do not result from direct browsing. That includes all requests towards Mozilla including update checks, Google Safebrowsing, and even things like OCSP or prefetching. There are many such items.

  • Preferences are also needed to disable most web standards on an individual basis. Tor Browser needs many of these. Non-tor users need a few, like service workers, beacons, EME, HTTP Alternative Services, Push, HTTP/2, ... For fingerprinting reasons it's best not to change too many preferences that sites can detect, but in some cases entropy is lowered by customising. When it's not entropy, it's exposure that gets reduced.

  • Certain desktop preferences do not apply to the future Firefox for Android (i.e. Fenix), so it is okay not to list them. For example, browser.uiCustomization.state or anything related to the UI or user interaction that is mouse-only. But we should use a blacklist of prefs irrelevant to Fenix, not a whitelist of prefs deemed "safe".

Right now it's very easy to break Fennec with one about:config change. I don't want the same thing to be possible in Fenix.

  • Just like the scratchpad is shielded against copy-pasting, about:config can be shielded from unthoughtful modifications without removing control from users. It can be a door hanger like on desktop, but preferences could also be ranked on criticality, like security.*. Let's think of implementing shields rather than nuking user control.

  • Future development policy on Fenix should be to keep adding granular preferences like Firefox does on desktop. Any time they add or remove a feature, they add or remove a set of preferences. It has worked very well on desktop; with a bit of cleaning on items irrelevant to mobile, I see no reason it would not work there.

  • Let's not centralise power in the hands of Mozilla developers. There's a matter of trust at the root of Firefox's status in the world. Mozilla is trustworthy because they commit to giving full control over their browser's behaviour to users, so that trust is not necessary. Centralising power by removing granularity and exhaustiviness of user control forces trust back into the equation.

As JanH mentioned, the font inflation options, most especially font.size.inflation.minTwips, have been critical for me to get desktop sites usable on mobile. Without it, text is far too small (or lines stretch too wide, requiring side-to-side scrolling if I've zoomed further). I've been setting that option on install on every new phone since 2012 - usually within a couple days when I realise I'd forgotten and start wondering why text is so small.

But ideally we don't need to pick-and-choose options to expose - a blacklist of unstable options (or keeping it as "at users' own risk") sound sensible to me.

We've decided to add a GeckoRuntimeSetting that will control whether or not about:config is exposed. Fenix will use this to enable about:config in all scenarios. Thanks to everyone here for their input!

Assignee: nobody → snorp
Pushed by jwillcox@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/82c4e08d9890
Guard about:config access with 'general.aboutConfig.enable' pref r=Ehsan
https://hg.mozilla.org/integration/autoland/rev/6736ed7f5805
Add `GeckoRuntimeSettings` controls for enabling `about:config` r=geckoview-reviewers,agi,esawin
Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71

firefox70=wontfix because we don't need to uplift this about:config fix to GV 70 Beta.

You need to log in before you can comment on or make changes to this bug.