New and improved "about:config" for Firefox Desktop
valentin.gosu at gmail.com
Fri Jan 25 17:40:38 UTC 2019
Is there a way to restrict autocomplete suggestions to things that have
been typed in the about:config page?
I typed net - for network - and got a suggestion for planet of the apes :)
Otherwise this is awesome work! Great job!
On Thu, 24 Jan 2019 at 21:32, Paolo Amadini <paolo.02.prg at amadzone.org>
> Last year a group of students, Luke, Matthias, and Vincent, designed and
> implemented a new version of "about:config" in order to improve the
> ergonomics and align the look and feel with other in-content Firefox
> pages. They did an amazing job, working with design input from Amy Lee
> and with myself doing code reviews.
> I'm happy to announce that this work will be available to everyone in
> Firefox 67, and can be already used in Nightly at this URL:
> Most improvements are the natural result of using HTML instead of XUL:
> * There are visible buttons for editing preferences
> * String values are displayed in full as multiline text
> * Find in page works for both names and values
> * Triple click selects one preference name or value quickly
> * Text selection works on multiple preferences
> * The context menu is the same as regular web pages
> - Copy to the clipboard
> - Open selected link
> - Search with your preferred engine
> * Search results don't include spurious value matches anymore
> * Closing and reopening the browser while the tab is pinned
> preserves the search term
> We've not just converted the old page, we've designed something new
> based on actual use cases, telemetry data, and opportunity cost. We
> preferred natural HTML page interactions, for example a double click now
> selects text instead of toggling the value. The way the page is explored
> with screen readers has also changed, and we've ensured that the new way
> is still clear and easy to use.
> We're still keeping the old "about:config" around at the following URL
> for a while, to mitigate risk related to unforeseen circumstances:
> Thunderbird will not be affected by this change initially, but at some
> point we'll remove the old code from mozilla-central since Thunderbird
> will be the only remaining user.
> This page can be slower than the old one in some cases. On slower
> machines the page may take a moment to display all preferences, if you
> so choose. We worked around this by waiting for the first input before
> displaying results, as 93% of "about:config" page shows include a search
> anyway. Navigation, scrolling, and find in page are then fast.
> We've used performance profiling to optimize the page and avoid the
> slowest layout modes, but we've not compromised on using the latest
> best practices for Firefox Desktop like Fluent localization, which are
> anyways in the process of being optimized on their own.
> We've explicitly chosen to avoid virtualizing the list, that is only
> rendering visible DOM nodes, because this would add complexity that is
> not needed for an internal page. It would also nullify most of the
> advantages in accessibility and usability that we gained at a low cost
> just because we're using a simple HTML table. Effort would be better
> spent on optimizing the web for the layout of tables of about 3,000
> rows, which would benefit every web site instead of Firefox only.
> *Tutorials and screenshots on the web*
> While with some features there is a concern that a change would make it
> more difficult for users to follow instructions found in older tutorials
> on the web, this is much less of a concern in this case, given that the
> page caters to experienced users and the changes affect presentation
> rather than actual functionality.
> In fact, existing information on the web can more easily become obsolete
> because the preferences go away or change their meaning, rather than
> because of a change in how the values can be changed.
> *Features that have not been rewritten*
> If the new page is missing a feature that the old one used to have,
> there is probably a good reason. Luke added telemetry probes to the
> current "about:config" so we know how people use it. It's basically just
> one mode of operation across all channels: search, then maybe edit or
> add a preference.
> There are more details in the history section below, but this is to say
> that it is unlikely that we would accept a patch to add back a certain
> feature just because it used to be present before. All patches would
> have to be motivated by an actual need and include exhaustive
> regression tests.
> That said, we have ideas for supporting new use cases for browser
> developers, like pinning a list of favorites or just showing recently
> modified preferences first, but we don't plan to start working on them
> before the current version reaches Release.
> *More details on history, motivation, and process*
> If you're reading this you probably already have a good idea of what
> we're talking about, but it's worth stating how we thought about the
> project when we approached it.
> "about:config" allows the occasional modification of application data
> that developers have chosen to store using the internal Preferences API.
> This may be operational data, feature flags, or settings that cannot be
> modified anywhere else in the user interface because it would be
> dangerous or rarely needed. This page is used very often by browser
> engineers during regular development and occasionally by other users
> after reading specific documentation in advance.
> The original "about:config" page was put together in the remote past as
> the "simplest thing that works" for the use case above. At the time,
> element, and a few predefined "alert" and "input" modal dialogs. While
> this didn't result in the most comfortable user interface possible, it
> served the purpose and we're still using it today with little or no
> Now we're in the process of removing XUL from mozilla-central, including
> the "tree" widget, and we're taking this opportunity to use standard web
> technologies for more of our internal pages. The practical effect is
> that we've improved the user experience of a functionality that was
> effectively left unchanged for decades.
> When rewriting the page, however, we followed the exact same criteria:
> simplest thing that works, cheap, and easy to maintain, but without XUL.
> Just reimplementing the same user experience, which was a side effect of
> the cheapest tools available at the time, would have been unnecessarily
> expensive today.
> One good thing with this approach is that the page can feel like part of
> Firefox with little effort, just by using HTML and the default styles
> from the Photon design system.
> Also, thanks to the better web platform that we have today, the same use
> lines of HTML and CSS, without any external UI components. For example,
> we can use HTML5 form validation to get a better user experience when
> editing numeric values at a low cost.
> We've also added extensive regression test coverage as we progressed, in
> line with our usual practices, to ensure easy maintenance going forward.
> Thanks again to Luke, Matthias, and Vincent for making all of this
> firefox-dev mailing list
> firefox-dev at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the firefox-dev