Open Bug 1615348 Opened 5 years ago Updated 3 years ago

Update the UI from prefs before calling a preference pane's init function

Categories

(Firefox :: Settings UI, defect, P3)

defect

Tracking

()

People

(Reporter: jaws, Unassigned)

References

Details

From bug 1582740 comment #2,

When loading a preferences pane we create the content from a template and then call the preferences API to update the UI from prefs: https://searchfox.org/mozilla-central/rev/153feabebc2d13bb4c29ef8adf104ec1ebd246ae/browser/components/preferences/in-content/preferences.js#68
The preferences API does this asynchronously: https://searchfox.org/mozilla-central/rev/153feabebc2d13bb4c29ef8adf104ec1ebd246ae/toolkit/content/preferencesBindings.js#140
And so we end up calling a pane's init function before the UI elements have the correct state: https://searchfox.org/mozilla-central/rev/153feabebc2d13bb4c29ef8adf104ec1ebd246ae/browser/components/preferences/in-content/preferences.js#70
So when we first decide whether to disable the checkbox or not its checked state is not correct: https://searchfox.org/mozilla-central/rev/153feabebc2d13bb4c29ef8adf104ec1ebd246ae/browser/components/preferences/in-content/main.js#1193-1194

We then start polling for the default browser check. The first poll happens one second after init at which point the chekbox is correctly checked and so we disable the checkbox: https://searchfox.org/mozilla-central/rev/153feabebc2d13bb4c29ef8adf104ec1ebd246ae/browser/components/preferences/in-content/main.js#316-334

I'm not really sure what is going on with the locked state, haven't looked into that too much.

We really shouldn't be calling a category's init function until after the preferences have been applied. Preferences.updateAllElements should return the promise it creates and we should await on it before calling init().

See Also: → 1582740
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.