Update the UI from prefs before calling a preference pane's init function
Categories
(Firefox :: Settings UI, defect, P3)
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-1194We 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().
Updated•3 years ago
|
Description
•