1703656 - Consider creating a static settings page

Status: RESOLVED FIXED

(Webtools :: Searchfox, enhancement)

Description

[Andrew Sutherland [:asuth] (he/him)]

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.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

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.

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

Attachment: Landed mozsearch PR: Settings page