Closed Bug 239533 Opened 16 years ago Closed 8 years ago

about:config shoulds support URL query for specific prefs


(Toolkit :: Preferences, enhancement)

Not set





(Reporter: benc, Assigned: int3)



(Keywords: dev-doc-complete, Whiteboard: [inbound])


(2 files, 5 obsolete files)

about:config is too cool, and I use it all the time now, but the bigger problem
is that we have too many prefs!

What would be great is if we could use the URL parsing features to extend the
about:config so that it would allow the following:

1- display of a single pref:

2- display a subtree of the namespace:

3- display an arbitrary list of prefs:

This seems like it would be easier to do now that we support filters.
about is a simple URI which has it's own URL parser, so we are free to do
whatever we want. I like this idea.
It would be extra-cool if you could change settings via URI. For example, I
would love to be able to create a bookmark or pair of bookmarks that allow me to
toggle a setting. It's OK, if it has to be complex, or javascript ala the google
search add-on. Just so I could toggle browser.tabs.loadInBackground without
having to dig into prefs. Other settings may interest other users.
I would prefer the syntax:


That will scale nicely as new features are added to about:config, such as being
able to search on multiple fields as in bug 213832:

Product: Core → Mozilla Application Suite
I'll be very happy and appreciated if "filter=net*.*ro?y*.*" format is accepted.
I prefer "DIR(Win)" or "ls(*nix)" like filtering.
Bug 213832, another enhancement of about:config filtering(regular expression), has been landed on 12/27 by Gavin Sharp.
I have been wishing for something like this for years. It is not trivial, but would add tremendous value. Particularly if there is a way to offer a preference change through a simple link, like Eudora did for it's own .ini settings. This being comlicated, a simple clickable filter would be very welcome in the meantime.

** Clickable about:config URIs to change settings:

* Security:

Obviously, a link changing a preference cannot be allowed to do it without a well-informed user confirmation. It needs a UI (popup?) presenting:

  - the meaning of the preference (see below)
  - the default value
  - the current value if different
  - the new value

So this can only work if we also have

* Documentation:

All settings need to be clearly documented. Currently, most (but not all?) are documented in various separate wiki pages, which cannot be automatically searched or exported. So this structured documentation effort would need to be done first. It would produce either a file which would be delivered with Mozilla apps for this purpose, or a searchable database which would be queried when a preference is changed this way, or both.

** In the meantime, a clickable URI with optional filter:

Something like what Steve suggests in comment #3 would seem fine. And this seems not too difficult to implement.

** Support for different Mozilla apps:

One additional feature would be the ability to specify the application to which the setting is to be applied. Preferences could apply to Firefox, Thunderbird, Sunbird, etc. What about an Intranet web page listing the recommended settings for Thunderbird? When clicked in Firefox, there should be a way for FF to know to send that to Thunderbird which would then handle the interface for the user approval. Of course, TB suggested settings could be sent through email (like what was done with Eudora), but what about Sunbird settings?

Maybe something like

In this bug, I don't want settable preferences. In fact, I'm pretty sure that links that set preferences are a bad idea.

If you want to request that, please file a new bug, and link to this bug as a blocker of that bug.
Attachment #342843 - Flags: review?
Attachment #342843 - Flags: approval1.9.0.4?
Attachment #342843 - Flags: approval1.9.0.4?
Comment on attachment 342843 [details] [diff] [review]
config.js mod to support about:config?filter=<string>

This needs review before we'll consider it for approval, but likely this isn't branch material and should just get fixed in 1.9.1.
change patch format
Attachment #342843 - Attachment is obsolete: true
Attachment #344752 - Flags: review?
Attachment #342843 - Flags: review?
Changing product/component to Toolkit::Preferences

+  var url = document.documentURI;
+  var str = /^about:config\?filter\=/;
+  if (str.test(url)) {

var filterstring ="?filter=".length,;

(stolen from <>)

The following should be merged with the end of ShowPrefs() (see Bug 440154):

+    textbox.value = url.replace(str, "");

textbox.value = filterstring;

+    textbox.focus();
+    FilterPrefs();
Assignee: jag → asmpgmr
Severity: normal → enhancement
Component: UI Design → Preferences
Product: SeaMonkey → Toolkit
QA Contact: pawyskoczka → preferences
> The following should be merged with the end of ShowPrefs()
Well the code in the whole patch should be moved to the end of ShowPrefs().

Also when you request for a review you have to fill in the requestee field otherwise the review request will never be noticed by anyone. Gavin Sharp or neil@parkway seem to be the most likely reviewers for this patches in this area.
updated to work with bug 440154
Attachment #344752 - Attachment is obsolete: true
Attachment #345888 - Flags: review?(
Attachment #344752 - Flags: review?
Flags: wanted1.9.2?
Whiteboard: [needs review gavin]
Comment on attachment 345888 [details] [diff] [review]
config.js mod to support about:config?filter=<string>

Sorry for the delay... Shouldn't this just use
Attachment #345888 - Flags: review?(
Flags: wanted1.9.2?
Attached patch Patch v1 (obsolete) — Splinter Review
So seems to always be empty for about: URLs (see bug 675555). I've adapted the original patch to 1) use decodeURIComponent 2) call FilterPrefs() in only one place.

I'm not sure whether we should fill the textbox with the URL parameter if it already contains a value; my current patch does that while the original did not.

Do we have a test directory for about:config? I wanted to write a test for this but I wasn't able to find a tests/ directory under toolkit/components/viewconfig.
Attachment #549749 - Flags: feedback?(
Attached patch Patch v1 (obsolete) — Splinter Review
Oops, the last patch had changes I hadn't intended to put in.
Attachment #549749 - Attachment is obsolete: true
Attachment #549750 - Flags: feedback?(
Attachment #549749 - Flags: feedback?(
Comment on attachment 549750 [details] [diff] [review]
Patch v1

How about:
var uri = document.documentURIObject;
var matches = /[?&]filter=([^&]+)/i.exec(uri.path);
Attachment #549750 - Flags: feedback?( → feedback+
Whiteboard: [needs review gavin]
Attached patch Patch v2 (obsolete) — Splinter Review
Patch updated with suggestions.

Taking this since it's been a while since it was last touched.
Assignee: asmpgmr → jezreel
Attachment #549750 - Attachment is obsolete: true
Attachment #550167 - Flags: review?(
Attached patch Patch v3Splinter Review
Attachment #550167 - Attachment is obsolete: true
Attachment #550168 - Flags: review?(
Attachment #550167 - Flags: review?(
Comment on attachment 550168 [details] [diff] [review]
Patch v3

I think this is actually not a particularly useful feature, since about:config isn't linkable, and if you're going to type the URL in manually you might as well type in the filter manually too, but we can just land this - let's just not spend any more time on this :)
Attachment #550168 - Flags: review?( → review+
Keywords: checkin-needed
Keywords: checkin-needed
Whiteboard: [inbound]
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla8
Could be useful for add-on developers.
Keywords: dev-doc-needed
Is this actually supposed to work? It doesn't for me.
(In reply to Eric Shepherd [:sheppy] from comment #23)
> Is this actually supposed to work? It doesn't for me.

This works for me. going to "about:config?filter=sessionstore" pre-fills the textfield and filters correctly (in both nightly & aurora)
Ah, I didn't read enough, I wasn't including the "filter=" part. It does work.
Duplicate of this bug: 618512
Duplicate of this bug: 250958
Depends on: 928649
Blocks: 1208602
Duplicate of this bug: 1244965
Duplicate of this bug: 1248646
You need to log in before you can comment on or make changes to this bug.