Open Bug 2014287 Opened 6 months ago Updated 5 months ago

Determine pattern to handle form-like groups in the config-based settings

Categories

(Firefox :: Settings UI, task)

task

Tracking

()

People

(Reporter: tgiles, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [recomp])

Bug 2006248 introduced a form-like group to the config-based Settings. I spent a good deal of time trying to figure out ways to handle the interactions needed for this, but wasn't able to simplify the code that was proposed in Bug 2006248. So here's some questions we need to solve:

  1. Should we have a setting-form component or something similar to handle this case?
  2. How should Setting Config objects be implemented when needing to react to changes in input elements?
    • Should they always have something like inputValue that is the source of truth for the value?
    • Should setup() be used to initialize a value for inputValue?
    • Should there be a dummy Setting/Settings that are used to keep track of the control's input value?
  3. What would be the way to write a Setting Config that the value of the Setting is dependent on a pref or some other setting but also can update its value when its input value changes?
    • Should setup() be used for this?
    • Should there be a dummy Setting used to track the non-committed value of the control's input?
  4. What would be the preferred way of committing a Setting's value if the Setting is using a text input? How would we handle this case if changing the value should update a pref?
    • For example, when switching models in the Customize Smart Window pane, the radio buttons for the first three immediately update a dependent pref's value but the fourth does not until the "Save" button is pressed.
  5. What would be the UX of this form-like group? Are my changes to the form saved if I blur an input in the form? Do I need to always activate a submit/save button to ensure my changes are committed?

We have a number of places where we have related components that replaced a dialog that could use the form association and consistent handling of Enter/Escape.

Good example (handles Enter/Escape but could use form association still):

  • Sync: Change device name

Other examples:

  • Website language: select + add button
  • Smart Window: custom model settings
  • Custom homepage: URL + add button
You need to log in before you can comment on or make changes to this bug.