Cannot filter for preferences values in about:config anymore
Categories
(Toolkit :: Preferences, defect)
Tracking
()
People
(Reporter: whimboo, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: regression, regressionwindow-wanted)
With the rewrite of about:config we lost an important feature that would be great to get back. As of now it is no longer possible to search for actual values of preferences. The only search which is performed is for the preference name.
In case you only know parts of the value but don't know to which preference it actually belongs, there is no easy way anymore to find that particular preference. Users would have to manually inspect the prefs.js file to find out which preference name it actually is.
Steps:
- Create a new preference like
general.useragent.overrideand set it tofoobar - Search for
foobar
With the old version it was possible to find this preference, now it doesn't work anymore.
Right now I'm not sure in which exact version of Firefox that landed.
|
||
Comment 1•6 years ago
|
||
Since the new about:config works like a website you can press Ctrl + F (macOS: Cmd + F) and search for "foobar".
|
Reporter | |
Comment 2•6 years ago
|
||
I should have said to filter. I'm not particular interested in all the other lines.
Also having to press Show all (which I haven't noticed before) every time is annoying.
|
||
Comment 3•6 years ago
|
||
We did consider the use case of someone having to search for a specific preference value in bug 1501658, even though it is something done much more occasionally than searching for the name. We made the decision of fulfilling that use case exclusively through the find-in-page functionality.
Filtering values and names at the same time has the clear disadvantage of creating spurious results, so while I understand that some people may find the new behavior slightly inconvenient, other people will find this new workflow to be a slight improvement. Also, as pointed out in the original bug, as soon as the value is factored in the filtering code, the filtering becomes much less trivial considering all the edge cases we have to handle and write tests for, and this is unnecessary work we can avoid.
We clarified in the placeholder string in bug 1579115 that this is not a bug but the intended behavior.
Description
•