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
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
