1502867 - Allow displaying only modified preferences

Status: RESOLVED FIXED

(Toolkit :: Preferences, defect, P5)

Description

[:Paolo Amadini]

We can implement a checkbox that will allow the redesigned "about:config" search result to be limited to modified preferences, as shown in the design mockup.

I don't think we'll need an option to show only unmodified preferences.

Comment 1

[:Paolo Amadini]

I'm lowering the priority of this because sorting by status in the current "about:config" is done only on 0.4% of page views, and we already have "about:support" that shows relevant modified preferences for the troubleshooting use case.

I'm not closing the bug for the moment because this is a situation where we might find a use case we haven't considered, but filtering based on the value would also complicate the code in bug 1501410. Implementing this would also require a whole new set of regression test cases to be written.

Comment 3

[:Paolo Amadini]

This looks like a common request just by looking at the page, so my ask at the moment would be for actual examples of when you encounter this in a real scenario.

This shouldn't just be just as part of testing out the new page, and should be a case where you've actually had to navigate to the old "chrome://global/content/config.xul" instead of "about:support".

Please include which preference name you've searched for, and for which reason you wanted to search only among modified preferences in the first place.

I'd expect reports to come in after we've switched the default in Firefox 67.

Comment 4

[Mike Hommey [:glandium]]

Users regularly end up having to do things like this:
https://twitter.com/damienguard/status/1087959182911905795

Doing something similar by switching back and forth between about:support and about:config is not sustainable. Editing files is not either. A list of editable modified prefs is not entirely helpful for bisection, but for simpler debugging workloads, it's very useful.

Comment 5

[Matthew N. [:MattN]]

(In reply to :Paolo Amadini from comment #1)

I'm lowering the priority of this because sorting by status in the current "about:config" is done only on 0.4% of page views, and we already have "about:support" that shows relevant modified preferences for the troubleshooting use case.

Are you taking into account that the sort is preserved between about:config loads? I keep about:config sorted by status for the most part.

One use case is figuring out why my profile has a bug that isn't reproducible in a new profile. about:support isn't a good substitute since it uses an allow list and exclude list of preferences (it isn't all-inclusive) and I don't think teams are good about ensuring their most relevant prefs are listed there. I don't think there is a good way to fix the latter problem without adding processes to adding a new pref (which seems heavy handed) and having everyone audit existing prefs.

Comment 6

[:Paolo Amadini]

(In reply to Mike Hommey [:glandium] from comment #4)

Users regularly end up having to do things like this:
https://twitter.com/damienguard/status/1087959182911905795

Uh, that's a counter-example though. While it worked in this case, you don't want to ask most users (who won't know how to edit preference files directly) to try and fiddle with all the preferences from "about:config" that don't have a default value, and reset them until they fix the issue... (And to be fair, that can already be done without a specific filter.)

We have Firefox Reset to fix most of those issues, and there's probably also a reason why the whitelist and blacklist in "about:support" exists...

To clarify, in comment 3 I'm not looking for past examples of things that worked well with the old page, but for new examples where things won't work at all with the new page.

Comment 8

[jwms]

Here is a crude drawing of some of the ideas I had about the about:config page that I wished was there over the years:

https://bugzilla.mozilla.org/show_bug.cgi?id=1167974

Comment 9

[Laurențiu Nicola]

(In reply to :Paolo Amadini from comment #0)

We can implement a checkbox that will allow the redesigned "about:config"
search result to be limited to modified preferences, as shown in the design
mockup.

I don't think we'll need an option to show only unmodified preferences.

I didn't use the sorting functionality each time I've opened about:config (and the telemetry seems to show that neither do others). But recently I've been contemplating refreshing my profile, and I'd like to see what preferences I've modified. There's a lot of them to slog through, but a "show modified" option would be fine for my case.

sorting by status in the current "about:config" is done only on 0.4% of page views

Out of curiosity, does that number come from telemetry? Can you share the key name?

Anyway, I would avoid this line of reasoning. For example, I wonder how many browsing sessions initiate a WebRTC connection and if the percentage is comparable.

---

And since I'm writing this comment and we seem to be proposing feature requests here, can we have about:config display the unused (invalid, removed or "hidden") preferences that have a user value set?

Comment 10

[Matthias :Kammueller]

We have telemetry data for about:config with the key ABOUT_CONFIG_FEATURES_USAGE.
Interesting would be the "sort by value" cases. Sort by name will be default, sort by status is replaced by the to-build tickbox.

Consider filing a new bug for feature requests. This redesign was a student project which is now more or less finished in its first version -- even if there are some improvements we thought of for newer versions, as can be seen in the mockup I built (https://github.com/kammueller/new-config)

Comment 11

[BelFox]

My two reasons to add this enhancement:

1. I have been using Firefox non-stop for > 12 years, and I didn't know the modified values can be found in about:support (since I never filed a support question using data from this page), while I do know that I can find them in about:config. So I expect most users to look for a solution in about:config.
2. Switching back and forth between about:support and about:config doesn't seem like an elegant solution, if this can be prevented with a simple checkbox or "status" column.

Thanks for reading.

Comment 12

[Jens]

Everybody ending up googling for "about:config sort" you can (for now) enter "chrome://global/content/config.xul" instead of "about:config" to get back the old sortable layout. Then you can sort for the "status" column to only see the changed (non-default) values.

Comment 13

[Darkspirit]

I was a bit unsure about this: The regression range seemed correct. But reintroducing something that was essential before is usually not classified as an enhancement. Sort by modified prefs is usually the first change I did after setting up Firefox. Now you have to scroll an eternity to find a problem-causing pref change. (Was this regression consciously signed off by product?)

Comment 14

[:Paolo Amadini]

I reviewed this back in February with Andreas and we definitely concluded that showing only modified preferences is not essential from a product perspective.

As for the categorization, this "about:config" page is a completely new design that for the first time had a UX and product review, missing from the original. I don't think there is much value in considering every change from the old "about:config" as a regression. In the case of this bug it is mostly an academic discussion, because even if it was a regression, it would be one we consciously accepted anyways.

The more I think about this, the more I'm convinced that having this feature in "about:config" would not necessarily be the best way forward anyways. The cost/benefit balance of implementing it here has shifted, and we may find out that if any compelling use case comes up with a wider audience (it hasn't come up in Nightly in six months), it may be fulfilled in a better way elsewhere.

Comment 15

[jwms]

seems like these are duplicate bug/feat requests

https://bugzilla.mozilla.org/show_bug.cgi?id=959843
https://bugzilla.mozilla.org/show_bug.cgi?id=1502867

Comment 16

[Matthew N. [:MattN]]

(In reply to jwms from comment #15)

https://bugzilla.mozilla.org/show_bug.cgi?id=959843

That is for Firefox on Android

https://bugzilla.mozilla.org/show_bug.cgi?id=1502867

That is this bug

Comment 17

[Jeff Muizelaar [:jrmuizel]]

Complaints from r/firefox: https://www.reddit.com/r/firefox/comments/ebwr6a/the_new_aboutconfig_page_is_horrible/

Comment 18

[Thomas Wisniewski [:twisniewski]]

I for one sometimes have to check which about:config flags I may have toggled, while doing webcompat or other testing/QA work. Even just having a "show modified" button next to "show all" would help out there. Would the UX team be against patches adding that?

I'm certainly not a fan of having to open about:profiles, find my prefs.js, see which flags I've changed there, and then have to search for each in about:config and toggle them back to confirm whether they are causing the issue I'm seeing.

Comment 19

[Adam Batkin]

...this "about:config" page is a completely new design that for the first time had a UX and product review, missing from the original...

Really?

1. You have to dismiss TWO warnings instead of one, in order to see anything ("Accept the Risk and Continue" then "Show All")
2. Actually you don't have to dismiss the second warning ("Show All") because you can instead search, and it will show you the results - this is not intuitive or easily discoverable
3. Search is even less intuitive, because if you type something short (like "nt") it does absolutely nothing, seems like there is a minimum of 3 characters for it to even start thinking about doing a search
4. The table has no headings to clarify what you are seeing
5. There's gratuitous white space around each cell, so less stuff fits on the screen
6. You can't sort by column (there are lots of reasons why people might want to do this, I won't justify them all now)
7. There are little icons at the side that are meaningless (what does the little opposing arrows thing mean? I've literally never seen that before - the hover text says "toggle")
8. If you do a search for a key that doesn't exist, a non-intuitive thing appears at the bottom to allow you to add a key - this has 2 problems:
   8a) If the search returns more results than fits on the screen, you don't even know that there's a thing at the bottom of the screen (search for "hyphenat")
   8b) Once you do see the bit that would let you add things, it's still not intuitive (how about some text explaining what that section is for, instead of the little white space between the search results and the new key)? I get it, text means localization. But lack of text means confusion.
9. Every time I do a search and then clear, I have to re-click "Show All" (why!?)
10. Editing fields is most easily accomplished using a mouse (for example double-clicking on a bit of text or the pencil icon) which (for text fields) gives you an inline editor. That can't be cancelled and dismissed using the mouse (i.e. if you make a mistake). Escape works, but AFAICT that's the only way

Also you can't easily find user-modified preferences (this bug).

Sorry, that's all I could find as of now, but I literally discovered the new about:config page 5 minutes before I started composing this. Because a colleague asked me how to configure Firefox in a certain way so that it would work well in a certain type of corporate environment, and I couldn't figure out how to find the settings that I had modified. I've been using about:config for....as long as I can remember and I didn't even know about about:support. Even with about:support, that's less useful than the old about:config since I can't sort or search the table of modified preferences (also, the table easily gets lost in the sea of other useful information on about:support).

The old preferences are still there (for now) so I'm good (for now). But I don't think that claim ("...the first time had a UX and product review...") is an appropriate answer to anything be raised in this Bug or any of the other Bugs (some of which have already been raised about some of the issues I mentioned):

The new about:config provides literally NO user benefits over the old about:config (it does use a more modern tech stack, which users don't see/notice) and contains a significant number of regressions compared to the old one. Maybe you have telemetry that claims that people didn't use those features. But maybe the types of users that would use those features (which are, admittedly, more advanced) have disabled telemetry (intuitively I would suggest that this likely the case), or the telemetry is somehow wrong (i.e. does it remember sort-order for those of us who had sorted by user-modified and left it that way for the past decade?)

And I bet that people who routinely mess with about:config are EXACTLY the kinds of users who are Firefox's biggest advocates, making the case for why their friends/family/colleagues should switch to Firefox, supporting those users if they run into troubles, configuring deployments of Firefox to work within corporate settings, and triaging issues.

Comment 20

[:Paolo Amadini]

I have read comment 18 and all of comment 19, and I would eventually like to provide an extensive answer, time permitting.

Firstly, however, I would like to distill some statements that are relevant to this bug report in particular:

...I for one sometimes have to check which about:config flags I may have toggled, while doing webcompat or other testing/QA work
...a colleague asked me how to configure Firefox in a certain way... and I couldn't figure out how to find the settings that I had modified.

These are the kind of "user stories" that we need to move the product forward as a product, rather than a set of individual features.

These two in particular have been commonly brought up, and I believe they would be better covered by the "most recently used" list that I had previously prototyped in bug 1497728. With the new page design and underlying code, it can now be implemented much more easily in "about:config" than before, and with minimal UX changes.

While an MRU list cannot be retroactive, it has the advantage that some preferences can be in the "modified" state by default, and the change that introduces a new behaviour or an issue consists in resetting the preference to the default. As mentioned before, if there is simply a need to find all the "modified" preferences retroactively for another reason, there are already several other ways to do it.

I've added a more detailed description and more user stories in bug 1497728.

Comment 21

[Laurențiu Nicola]

What does "recent" mean in the context of bug 1497728? Would these be the preferences modified in the last X hours / days?

If so, that feature unnecessarily the one requested here, without catering to all of the use cases that this would help with. Here's one more (if not already mentioned, I didn't read the whole thread again): I have long-lived profiles and sometimes run into bugs that don't occur in a fresh one. Before reporting them, I try to go through the preferences I know I care about and toggle them in the new profile, but sometimes it's one that I forgot about.

A "recently modified" probably won't help here, so I would need to resort again to manually diffing the two prefs.js files.

Comment 22

[:Paolo Amadini]

(In reply to Laurențiu Nicola from comment #21)

What does "recent" mean in the context of bug 1497728? Would these be the preferences modified in the last X hours / days?

No, "most recently used" (MRU) only refers to the order of modification, similarly to how applications keep lists of recently opened documents.

Comment 23

[Laurențiu Nicola]

Nb. You're probably aware of it, but what I said also applies for those kind of lists -- they usually show the last X open files or so.

Comment 24

[Thomas Wisniewski [:twisniewski]]

if there is simply a need to find all the "modified" preferences retroactively for another reason, there are already several other ways to do it.

That sounds promising. Would you mind sharing links explaining these ways? The only one I currently am aware of is viewing prefs.js, which I cannot claim to be a pleasant UX, especially for frustrated users troubleshooting a problem.

Comment 25

[:Paolo Amadini]

(In reply to Thomas Wisniewski [:twisniewski] from comment #24)

That sounds promising. Would you mind sharing links explaining these ways?

Sure, and to be fair most of them have been mentioned already. At some point I will recap them in a more detailed way, but in summary the general user-facing ones are "about:support#prefs-tbody" and "prefs.js". As upcoming features, in addition to bug 1497728, there is bug 1582535 that could add the state to the table that is copied to the clipboard, as a side effect of improving localization and accessibility. You could then copy everything to a spreadsheet and filter and sort there. For the moment, you can also still access the old "about:config" page. As an experienced user, you can output the list of names or names and values in the Developer Console with a one-liner, and finally you can use a CSS hack to hide the non-bold rows - although it's worth stressing the word "hack", because there's a huge difference in cost between that and a proper code-reviewed implementation of a value-based filter, even if the result superficially looks similar. We can spend less effort with greater benefit by working on bug 1497728 and bug 1582535.

I'm now even more convinced that our product managers made the right call when they determined that the new "about:config" was complete without the ability to filter by modified state. It saved engineering effort, but also, from the anecdotal evidence in this bug, the absence of filtering had a positive product impact because some people have now discovered the existence of "about:support" when they were previously unaware of it.

The only one I currently am aware of is viewing prefs.js, which I cannot claim to be a pleasant UX, especially for frustrated users troubleshooting a problem.

I want to address briefly that for certain classes of frustrated users troubleshooting a problem, "prefs.js" offers a more pleasant user experience than what sorting in "about:config" used to provide. Since "prefs.js" is a text file, it can be sent through various means upon request, compared with other versions or other profiles, and so on. It is already common to do this with files like "handlers.json" or "places.sqlite" - and if the assumption is that you don't already know the likely cause of an issue, there is also a chance that one of the other configuration files in the profile is causing it.

Comment 26

[Adam Batkin]

I learned about about:support, which is cool.

But that doesn't help my use-case, since there are dozens of changed preferences, and telling me that I can/should dump those into a spreadsheet where I can do further filtering/sorting isn't exactly helpful (it's about as helpful as asking me to look through my prefs.js). And if I wanted to make a quick change to test something out (and then revert a day later) would require switching between 3 different contexts (about:config, about:support, and a separate spreadsheet application). Similarly, Bug 1497728 wouldn't help my case, since I changed those settings (the ones I was looking for) probably 6 years ago (except for a couple which were 2 years ago) so they'd be all over the place. I can't tell how Bug 1582535 would help either, that would just makes changed preferences more visually distinctive (in a sea of hundreds, that's not helpful). A checkbox to allow me to view only modified preferences would help, just as easily as allowing me to sort-by-modified (actually a checkbox would arguably be even better than sorting, since I can still sort using other parameters, like modified time, once that's available).

We went from a single well-known pane-of-glass where a variety of problems could very quickly be solved in a variety of different ways to 4 different suggestions (about:config, about:support, prefs.js and a spreadsheet!?), none of which solve anyone's problems in a complete way, all of which require significantly more work.

Wveryone solves problems in different ways. A table that lets you filter and sort would be fast, intuitive and simple, since tables are so common in modern user interfaces.

I'm now even more convinced that our product managers made the right call when they determined that the new "about:config" was complete without the ability to filter by modified state. It saved engineering effort, but also, from the anecdotal evidence in this bug, the absence of filtering had a positive product impact because some people have now discovered the existence of "about:support" when they were previously unaware of it.

Really? Again, I'm glad I learned about about:support (a link at the top of the about:config page suggesting that I also look in about:support would be very welcome). But just because I can't articulate every possible use case for why it would be useful to be able to filter and/or sort by "modified" (and there are millions of other Firefox users who may have other use cases) doesn't mean that it wouldn't be beneficial. I've already explained one of my use cases (the one I happened to run across, which should have taken less than 15 seconds to solve), and you have summarily dismissed my use case and offered a variety of terrible alternatives. Just because there exist alternatives doesn't mean that they are any good.

Comment 27

[Thomas Wisniewski [:twisniewski]]

Thanks for the post. I'm not thrilled that the decision is for users to have to juggle between not-particularly-discoverable UIs to do the same job they could do before (for the use-case I presented at least), but if that decision has been made, and such that not even a contributed patch would be considered, then I guess that's that.

Comment 28

[BelFox]

I couldn't have written it down better than Adam in Comment 26. The suggestions made do not adequately solve the issues we and many other users are having.

Instead of repeating my arguments (see Comment 11), I have this sincere question: does it really take that much development/testing time to add a clickable (sortable) header row to a well-known page as about:config, when other table interfaces in Firefox (Settings > Applications, Web Developer > Network, ...) already have this functionality?

I agree this is not a must have, but this bug could be considered a nice-to-have that could create a lot of positive response from loyal FF users.
Thanks!

Comment 29

[Eavesdown]

I would agree with the above commenters that all of the proposed solutions so far are seemingly just less efficient, more roundabout ways to manage what should be the simple task of quickly viewing and adjusting modified values. I'm not specifically familiar with web browser development, but I code all sorts of other projects for a living, and I can't see how an extra sort column or filter checkbox would be particularly difficult to implement in this context. Is the time involved in implementation actually a serious factor in the decision-making process here, or is there a more fundamental objection to including this feature?

Comment 32

[alex]

As the author of bug 1608996 I fully agree.
We need back the column headers and a switch to always show the full list.

An addon would be okay, but I think the restricted new APIs don't allow for such addons at the moment.

But WHY did you change this anyway? There was a perfectly working solution, with the huge advantage of using native UI and the new UI has no features that the old one did not have.
The version now using HTML has the same drawbacks like the settings page or (slightly off-topic, but interesting as comparision) the whole vivaldi UI. It just ignores your platform's UI, its widgets and theme, and the global shortcuts and other customizations.

Native UI is a good thing, it should not be replaced by HTML-based implementations, just because it is possible. And it is probably easier to enable column headers and similar standard features of native UI widgets, than reimplementing them because the UI is now implemented using HTML.

So back to the original bugreport:

• Please bring back the column headers
• Please add an option to always show the full list
• Please bring back the context menu with "copy", "copy name", "copy value" and "reset" items

Comment 33

[alex]

Working with it just now, the missing sorting by "is changed" is especially annoying when searching for some setting that was changed and you see all matching settings instead of the relevant (i.e. changed) ones first.

Comment 34

[Michael Froman [:mjf]]

After reading through the comments here, I tried using about:support to find the modified pref that I needed, and it wasn't listed there. I know it was the one I wanted because I spent 30 minutes slowly scrolling through my modified prefs on my desktop to find the one that did the trick. Then I went to about:support and it does not show up in the list. The pref in question is "toolkit.legacyUserProfileCustomizations.stylesheets". For me, using about:support failed as a possible replacement for "sort by modified" on about:config.

Comment 35

[Eavesdown]

(In reply to Michael Froman [:mjf] from comment #34)

After reading through the comments here, I tried using about:support to find the modified pref that I needed, and it wasn't listed there. I know it was the one I wanted because I spent 30 minutes slowly scrolling through my modified prefs on my desktop to find the one that did the trick. Then I went to about:support and it does not show up in the list. The pref in question is "toolkit.legacyUserProfileCustomizations.stylesheets". For me, using about:support failed as a possible replacement for "sort by modified" on about:config.

It sounds like that preference might not qualify as "important" for the purposes of the Important Modified Settings support view. Is there a list of preferences that do qualify at this time, or is that only visible in the source code?

Comment 36

[:Paolo Amadini]

It seems that the preferences under "toolkit" are not listed in "about:support", which I believe is an issue because important configuration changes may go unnoticed. Thank you Michael for reporting the problem, I filed bug 1611980 to fix this in a way that can be future-proof, and hopefully result in an improvement for technical support in general. If I understand correctly, if we already had a feature like bug 1497728, the preference would also have been listed among the ones that you modified manually.

When we've implemented bug 1497728, I'm thinking the list may be made to work retroactively on a case by case basis without too much effort. This could be done with a Developer Tools snippet to feed the list with the preferences that have been modified before. For most users, however, the list would start empty because spurious data would reduce its usefulness, and I don't believe we have a cost-effective and reliable way to distinguish which modified preferences to exclude.

Comment 37

[:Paolo Amadini]

(In reply to Ruben from comment #28)

I have this sincere question: does it really take that much development/testing time to add a clickable (sortable) header row to a well-known page as about:config, when other table interfaces in Firefox (Settings > Applications, Web Developer > Network, ...) already have this functionality?

This is a good question, and I believe it is the crux of the matter. Something like this would have a non-trivial cost even if we were using a reusable component, which we don't have in this case.

In a small code base or as a one-off project, I would say that a page similar to "about:config" could be made by one person in a week or less. In our codebase, at least five developers spent several calendar months on it, and I'm not considering all the user experience design, management, and coordination. And this is a tiny fraction of the time that Mozilla developers regularly spend on more involved features.

In addition to the described up-front development cost, there is the future maintenance cost. Mozilla runs thousands of automated test suites every hour. Each time the tests for "about:config" are executed, about 60 seconds of machine time have to be paid for. This is very high compared to other features, whose tests run in a few seconds, because of still unresolved performance limitations. Every new element to test, like a sortable header, adds to this cost. As of now, nobody could find the time to optimize the tests yet, thus bug 1507747 is still pending.

There is also the time that future developers have to spend on understanding existing code, sometimes when working on something completely different that happens to affect the page. This grows with the complexity of the code base and the number of developers who need to look at it.

Firefox engineers and managers are faced daily with the choice of where to invest these limited resources - and to address a point made in comment 18, in the case of this bug the visual design is trivial, and the costs are elsewhere, mostly in development and review, corner cases, and maintenance.

I've mentioned bug 1497728 because it has a much higher impact, benefiting more categories of users, and can be developed at a lower cost. I clearly understand that bug 1497728, like every other alternative described before, is not an exact replacement for the feature requested here. However, I believe the other bugs are better investments at this specific moment.

Finally, the choice of spending this effort on a new "about:config" page, whose cost by the way is still tiny compared to the average feature, was dictated by the need to remove XUL. Most XUL widgets are difficult to maintain because they emulate the look of native UI, but they are not native UI. This means that Firefox can't leverage any feature the operating system provides, unlike other programs that use native programming interfaces.

Removing XUL is a strategic move that reduces the maintenance cost in the long run and allows more features to be developed. In my view, and probably Mozilla's strategic view, this provides a huge user benefit, although indirect.

Comment 38

[Adam Batkin]

I don't believe that bug 1497728 will help for most use cases (or at least for most of the people waiting on this bug). No one knows what "recent" means, plus this bug isn't about finding recent changes, it's about finding all changes (again, in my case, I was looking for settings that I changed 6 or 7 years ago, which I'm pretty sure would not be considered "recent" by any standards).

The new about:config was necessary for genuine technical reasons (remove XUL). But there should be no disagreement that it is a significant regression in functionality. This particular bug is only one of many bugs that address holes left by the new about:config page. My opinion is that there should be a well-thought-out long-term design/roadmap for the new about:config page (and we can later figure out how to get there) that addresses the concerns that have been raised - recognizing that there are use cases and usage patterns that may not have been captured by the current design or the telemetry on existing features. And we stop trying to "rationalize" why users don't need a particular piece of functionality (that they do in fact need), trying to convince them to do something a different way (that ends up being more complex, time consuming or limited), and pretending that advanced users (or really any users) aren't capable of using simple user interfaces (a sortable, filterable table with a bunch of useful columns would literally be the most intuitive and usable UI/UX that you could possibly build).

I think everyone would happily accept being told "here is the workaround for the time-being, it will be worked on" but it is not acceptable to say "your use case is invalid, here do this other thing that will solve your problem instead" (when "this other thing" won't in fact solve the problem at all).

Comment 39

[Jens]

Very well said, Adam! I was just about to write exactly the same.

I'd like to emphasize:

a sortable, filterable table with a bunch of useful columns would literally be the most intuitive and usable UI/UX that you could possibly build

Exactly! That's learnt, intuitive UX/UI behaviour.

I am a Nightly user and mozregression user. I have filed many, many bugs with STR and regression ranges. And the new about:config really hurts my workflow.

Comment 40

[:Paolo Amadini]

An engineering roadmap for the new "about:config" page would represent a generality of use cases and needs, in addition to those expressed in this bug.

The most effective roadmap, according to my experience and the feedback I've observed overall, would include bug 1497728, bug 1582535, bug 1560683, and possibly the optimizations of the tests for bug 1507747, and all of them would be higher in priority than this bug. This means that we should be wary about adding any code or tests for this bug before we've fixed the others, even though this bug is a valid use case when taken by itself. The performance issues blocking bug 1523028 can proceed independently, since they are mostly individual platform bugs.

We explicitly decided when we started the project that we wouldn't create an exact replacement of the old page, and we wouldn't automatically consider any difference or missing feature from the old page as a high priority bug, but we would evaluate them individually. We closed some bugs as "regressions we have accepted", while other bugs like this one are still valid, but blocked by higher priority work. This was also motivated by the cost considerations highlighted in comment 37.

The replacement of "about:config" was part of the roadmap for XUL removal, and from a product perspective we completed this stage because what we released doesn't use XUL and it already serves its essential purpose. Work will continue as part of general Firefox development such as improving the technical support experience, as I don't believe there would be a separate budget just for "about:config" as an independent entity.

Comment 41

[BelFox]

(In reply to :Paolo Amadini from comment #37)
Thank you for taking the time to write down your arguments in such an elaborate way. Much appreciated!

(In reply to :Paolo Amadini from comment #37)

I've mentioned bug 1497728 because it has a much higher impact, benefiting more categories of users, and can be developed at a lower cost.
(In reply to Adam Batkin from comment #38)
in my case, I was looking for settings that I changed 6 or 7 years ago, which I'm pretty sure would not be considered "recent" by any standards.
If "recent edits" is implemented like "last 10/last 50/all settings manually changed", instead of "settings manually changed over the past day/month/year", it probably could solve Adam's use case as well? Just an idea ...

Comment 42

[BelFox]

Formatting went wrong in my previous post. Sorry about that. Why doesn't Bugzilla have an "edit comment" function?

To repeat myself:
If "recent edits" is implemented like "last 10/last 50/all settings manually changed", instead of "settings manually changed over the past day/month/year", it probably could solve Adam's use case as well? Just an idea ...

Comment 43

[lostdharmai]

If there are reasons not to put this functionality back into about:config, why not make use of something that already exists - the listing of modified preferences in about:support? Right now, they show Important modified preferences, but with some improvements they could also show preferences modified by a user or an extension.

Comment 44

[Darkspirit]

My online banking website doesn't load with Nightly (endless loading), but works in Private Browsing. Addons are disabled. Now I need to narrow down which prefs could have caused this.
about:profiles > Ctrl +F "default-nightly" > Open Folder > (Opens with Konqueror, wtf) > right click on prefs.js > Open with Kate

Comment 45

[alex]

I just want to add a bit of explanation, that was missing in my post above and that may explain your telemetry results.

The most important point is not sorting the whole list by "is modified", but that the filtered list is sorted by the status.
This is useful, because when a user is searching a certain setting, there is a good chance that he modified it before (and now wants to reset it or try another value).

A "only modified" checkbox is a similar solution, but by sorting modified settings before unmodified ones you can still see both.
When you scrolled over the modified ones and did not find the setting, you may find it in the list of unmodified settings when you keep scrolling.

Comment 46

[Sören Hentzschel]

If it's really important for someone to see only modified preferences I have a workaround for you: Just execute the following code in the web console (after you pressed the button to show all preferences):

var elements = document.getElementsByTagName('tr');
[...elements].filter(el => !el.classList.contains('has-user-value')).forEach(el => el.style.display = (el.style.display === 'none') ? 'table-row' : 'none');

Repeat this to show all all preferences again. I hope it helps.

Comment 47

[Tom S [:evilpie]]

Attachment: Bug 1502867 - Add button to only show modified preferences in about:config. r?paolo

This seemed easy to implement to so I just went ahead did it. I hope we can land this, I miss this feature quite often.

Comment 50

[laurens]

Add me to the list of semi-power users that is flabbergasted by the removable of 'sort by modified' in about:config

The about:support shows modified, but no easy way to modify the modified settings (no pun intended)

Comment 52

[Tom S [:evilpie]]

Sorry. I am not actively working on this. Unassinging myself in case someone is interested in fixing this.

Comment 53

[Ed]

Anybody?

Comment 54

[Tim Nguyen :ntim]

Attachment: Bug 1502867 - Add checkbox to show only modified preferences in about:config.

Comment 55

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f2282dc7b4dd
Add checkbox to show only modified preferences in about:config. r=mconley,fluent-reviewers,flod

Comment 56

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/f2282dc7b4dd

Comment 57

[Michael Froman [:mjf]]

Awesome this functionality is restored! Thank you!