1951985 - GeckoView does not respect the distinction between "user" and "default" prefs when they are set through RuntimeSettings

Status: NEW

(GeckoView :: General, task, P3)

Description

[Olivia Hall [:olivia]]

GeckoView is not respecting the distinction between “default” and “user” Gecko prefs when set via RuntimeSettings because the pref is reset on startup.

The goal of this bug is to research and possibly implement a solution to this issue. It is possibly relevant because depending on how we save information to rollback on Nimbus, the distinction could be very important.

Full results of determining this bug may be found here.

Abbreviated summary of results:

Pref Set by GeckoView as PrefWithoutDefault

Tested: dom.security.https_only_mode_pbm
Init:

• Services.prefs.prefHasUserValue(dom.security.https_only_mode_pbm): false
• Services.prefs.prefHasDefaultValue(dom.security.https_only_mode_pbm): true
• Services.prefs.getBoolPref(dom.security.https_only_mode_pbm): false
• defaultBranch.getBoolPref(dom.security.https_only_mode_pbm): false

After change in about:config:

• Services.prefs.prefHasUserValue(dom.security.https_only_mode_pbm): true
• Services.prefs.prefHasDefaultValue(dom.security.https_only_mode_pbm): true
• Services.prefs.getBoolPref(dom.security.https_only_mode_pbm): true
• defaultBranch.getBoolPref(dom.security.https_only_mode_pbm): false

After hard close / reopen:

• Services.prefs.prefHasUserValue(dom.security.https_only_mode_pbm): false <-- should be true
• Services.prefs.prefHasDefaultValue(dom.security.https_only_mode_pbm): true
• Services.prefs.getBoolPref(dom.security.https_only_mode_pbm): false <-- notice pref didn't change
• defaultBranch.getBoolPref(dom.security.https_only_mode_pbm): false

It is because allowInsecureConnections is clobbering the value at startup through httpsOnlyMode here. It is stored in Fenix here. This pattern is common on Fenix.

Pref (in comparison to PrefWithoutDefault) might even have a bigger problem where it states a "user" pref is a "default" due to the way Fenix is setting them.

Comment 1

[Olivia Hall [:olivia]]

Attachment: Test-Results-User-v-Default-Prefs.md

Manual testing that illustrates Android isn't respecting "default" v. "user" prefs in a strong way.

Comment 2

[Olivia Hall [:olivia]]

Note: This is related to how Android clobbers about:config settings as well.

Comment 3

[Olivia Hall [:olivia]]

Two root issues here:

1. The way Android resets prefs on startup and how Fenix/AC store the actual pref value makes all RuntimeSettings prefs be tracked outside of Gecko. Because of this, items are constantly reset at startup.
2. The distinction between "default" and "user" is weak because all RuntimeSettings prefs run through this method - notice Services.prefs.getDefaultBranch(""); is setting on the default branch, so a PrefWithoutDefault will become a default if it is manually set.

Comment 4

[Olivia Hall [:olivia]]

This might also be "working as intended", if that is the case, then I'd be good to document the decision.

However, some prefs like the one on whether to set the popup on translations make more sense as a pref that can and should change based on the user preference and be set on the "user" branch. It shouldn't be clobbered and re-locked into a specific default each time.

From what I can tell, this behavior of clobbering the pref back to default each time makes sense for stability level prefs, but not true cosmetic or choice preferences.