New and improved "about:config" for Firefox Desktop

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: chrome://browser/content/aboutconfig/aboutconfig.html 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: chrome://global/content/config.xul 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. *Performance* 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, this involved about 600 lines of JavaScript, a supporting XUL "tree" 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 changes. 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 case can be supported using about 400 lines of JavaScript and a few 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 possible! Cheers, Paolo