Closed Bug 1703656 Opened 3 years ago Closed 1 year ago

Consider creating a static settings page


(Webtools :: Searchfox, enhancement)



(Not tracked)



(Reporter: asuth, Assigned: asuth)


(Blocks 1 open bug)



(1 file)

So far various experiments like the code coverage prototypes have tried sticking all of our settings in the navigation sidebar, but this doesn't scale well for options or having good explanations of what the options are.

We should consider adding a global settings page that we link to from either the search bar at the top or from the navigation sidebar.

A good first candidate for the settings would be the document.title behavior I introduced in bug 1702319. I think this is already a situation where people's use cases already diverge sufficiently that it's hard to have a single perfect solution for this, but where we can keep the matrix of functionality small enough to not create an unmaintainable mess of permutations.

Example document.title settings options:

  • For the title:
    • ( ) Always show the filename.
    • ( ) Dynamically show the selected line or current position:sticky symbol.
  • If showing a symbol:
    • ( ) Include collapsed namespaces.
    • ( ) Omit namespaces.

This could also allow for manual overrides to the Firefox theme beyond inheriting the browser's dark mode setting, etc.

This could then take immediate effect by having all pages listen for "storage" events as emitted by LocalStorage on other pages in the same origin whenever a mutation occurs.

Note that I am proposing a global settings page right now, which is somewhat at odds with my proposal in bug 1703115 to try and isolate the repositories from each other. My general take on this is:

  • It would be very annoying to have to change settings for every repository.
  • Similar to Firefox preferences or telemetry probe names or localized strings, if we're changing the underlying semantics for a setting in a way that would confuse the existing code, we give the setting a new (storage) name.
    • The settings binding code can know what are current settings and what are old settings and purge anything that's not a current or old setting from localStorage. That could be done way down the road.

Additional UX thoughts:

  • It makes sense for the settings button to have a UI badge that gets applied when there are new settings that correspond to new (configurable/optional) features.
    • It makes sense for the badge to itself be an opt-in feature that's disabled by default.
    • Displaying the settings page when there's a "version upgrade" would clear the badge until the next upgrade.
    • The setting for this would be there from day one of the settings UI but we can punt on actually implementing the badge.
Assignee: nobody → bugmail
See Also: → 1783761
Blocks: 1808415
Depends on: 1809987
Closed: 1 year ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.