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)
Firefox
Settings UI
Tracking
()
NEW
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:
- Should we have a
setting-formcomponent or something similar to handle this case? - How should Setting Config objects be implemented when needing to react to changes in input elements?
- Should they always have something like
inputValuethat is the source of truth for the value? - Should
setup()be used to initialize a value forinputValue? - Should there be a dummy Setting/Settings that are used to keep track of the control's input value?
- Should they always have something like
- 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?
- Should
- 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.
- 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?
Updated•6 months ago
|
Comment 1•5 months ago
|
||
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.
Description
•