Bug 1966506 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

We need to introduce a way to disable and reenable inputs based on pref values to config-based settings.

The `browserRestoreSession` checkbox is disabled depending on the value of the `browser.privatebrowsing.autostart` pref, so could be a good candidate for replacement as part of the work on this feature.

In that case as well as many others, the pref that controls whether or not the input is disabled is different from the pref that's controlled by the input and used to set it's value, checked state, etc. This means we'll need to introduce a mechanism for making settings respond to changes in "dependent" prefs as part of this work.

Here's a preference configuration that could work for this case:

```js
Preferences.addSetting({
  id: "browserRestoreSession",
  pref: "browser.startup.page",
  // add a new "dependencies" array for additional prefs we want to listen for changes on
  dependencies: ["browser.privatebrowsing.autostart"],
  // add a function with the logic for whether or not the input should be disabled
  disabled: () => {
    // TODO: read from dependent pref
  },
  ...
});
```

We'll then need to add logic to the `Setting` class to:

1. listen for changes to each pref in the `dependencies` array in order to emit a change event
2. add a `disabled` getter that calls the `disabled` function and returns `false` by default (I imagine this will look pretty similar to the `visible` getter)

There will be some additional work in the `settings-control` and `settings-group` elements to ensure `disabled` gets set on input elements. In `settings-control` we may need to change [this](https://searchfox.org/mozilla-central/rev/bd4d1cd1ca3037e6dc8d4081a4303824880b1b45/browser/components/preferences/widgets/setting-control/setting-control.mjs#26) `onSettingChange` listener to just call `this.requestUpdate` to ensure that the input will re-render when one of the dependent prefs changes. We may or may not want to handle setting the value in `willUpdate` instead.

Acceptance criteria:

* it's possible to `disable` an input based on some preferences configuration
* inputs can be disabled based on "dependent" prefs i.e. prefs other than the one used to determine an input's value
* the disabled/enabled state of the input changes when the pref value changes
* add tests to cover all of the above
We need to introduce a way to disable and reenable inputs based on pref values to config-based settings.

The `browserRestoreSession` checkbox is disabled depending on the value of the `browser.privatebrowsing.autostart` pref, so could be a good candidate for replacement as part of the work on this feature.

Here's a preference configuration that could work for this case:

```js
Preferences.addSetting({
  id: "browserRestoreSession",
  pref: "browser.startup.page",
  // add a function with the logic for whether or not the input should be disabled
  disabled: () => {
    // TODO: add logic to determine whether or not the checkbox should be disabled
  },
  ...
});
```

We'll then need to add logic to the `Setting` class to add a `disabled` getter that calls the `disabled` function and returns `false` by default (I imagine this will look pretty similar to the `visible` getter). There will be some additional work in the `settings-control` and `settings-group` elements to ensure `disabled` gets set on input elements.
Acceptance criteria:

* it's possible to `disable` an input based on some preferences configuration
* add tests to cover this
We need to introduce a way to disable and reenable inputs based on pref values to config-based settings.

The `browserRestoreSession` checkbox is disabled depending on the value of the `browser.privatebrowsing.autostart` pref, so could be a good candidate for replacement as part of the work on this feature.

Here's a preference configuration that could work for this case:

```js
Preferences.addSetting({
  id: "browserRestoreSession",
  pref: "browser.startup.page",
  // add a function with the logic for whether or not the input should be disabled
  disabled: () => {
    // TODO: disabled logic goes here
  },
  ...
});
```

We'll then need to add logic to the `Setting` class to add a `disabled` getter that calls the `disabled` function and returns `false` by default (I imagine this will look pretty similar to the `visible` getter). There will be some additional work in the `settings-control` and `settings-group` elements to ensure `disabled` gets set on input elements.
Acceptance criteria:

* it's possible to `disable` an input based on some preferences configuration
* add tests to cover this

Back to Bug 1966506 Comment 0