Simplify Suggest initialization and how it handles updates to Nimbus variables
Categories
(Firefox :: Address Bar, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox137 | --- | fixed |
People
(Reporter: adw, Assigned: adw)
References
(Blocks 1 open bug)
Details
(Whiteboard: [sng])
Attachments
(1 file)
Suggest's handling of updates to Nimbus variables is a little complicated. It does two things when a variable is updated:
- If the variable corresponds to a pref that's exposed in the settings UI, it calls
updateFirefoxSuggestScenario()
to re-sync the variable's value to the pref on the default branch. (It also does this ifquickSuggestScenario
was updated but I'm removing that in bug 1947053.) - source - If a default-branch value for any pref is incorrect for the intended scenario, it also calls
updateFirefoxSuggestScenario()
. - source
I'd like to remove case 2 altogether. Instead, I'd like for Suggest to initialize the intended "scenario" once and for all at startup. After startup, we can use individual Nimbus variables to enable certain suggestions/features.
Case 1 is overly complicated because it causes updateFirefoxSuggestScenario()
to re-enter itself. On startup, Suggest calls updateFirefoxSuggestScenario()
, which sets some prefs, which causes "updates" to Nimbus variables whose fallbacks are those prefs, which hits case 1, which calls updateFirefoxSuggestScenario()
again. We use _updatingFirefoxSuggestScenario
inside updateFirefoxSuggestScenario()
to prevent infinite indirect recursion in this case.
The only prefs that need updating in case 1 are the ones in UI_PREFS_BY_VARIABLE
: prefs exposed in the settings UI that specifically are not fallbacks for their corresponding Nimbus variables. So we should only update those prefs in case 2. Since they aren't fallbacks, there's no danger of re-entry.
Updated•1 month ago
|
Assignee | ||
Updated•1 month ago
|
Assignee | ||
Comment 1•1 month ago
|
||
Depends on D237505
Comment 3•1 month ago
|
||
bugherder |
Description
•