Agreed. If there's one special feature besides search I've been using most, it was sorting by modified
Am Fr., 25. Jan. 2019, 12:16 hat Tom Schuster <t...@schuster.me> geschrieben: > I am always happy to see more xul going away. > > Please implement a filter to only show modified preferences. Sorting > by modified is probably my most common operation after search on the > old page. > > Thanks > > On Fri, Jan 25, 2019 at 11:40 AM Axel Hecht <l...@mozilla.com> wrote: > > > > Is there a tracking bug for follow-ups? > > > > I'd have a few, adding pref w/out search (*), show add on screen for > > long searches, filter/order by modified, search in values, can't abort > edit. > > > > (*) I just realize that I didn't understand how "add" works. Maybe the > > bug is to make that discoverable? > > > > Axel > > > > Am 24.01.19 um 20:31 schrieb Paolo Amadini: > > > 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 > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
