213832 - about:config filtering enhancement: search for status/type/value and allow wildcards

Status: RESOLVED FIXED

(SeaMonkey :: Preferences, enhancement)

Description

[Christian Franke]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5a) Gecko/20030718
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5a) Gecko/20030718

The about:config filtering/searching (Bug 207840 and related Bug 103911) can
only search for preference names.

The following enhancement would be useful:
- Search for all fields (pref.name, status, type, value)
- Allow '*' wildcards


Reproducible: Always

Steps to Reproduce:
1. Open about:config
2. Enter "mailbox:" in Filter field.
3. Enter "charset*user set*iso-8859".
Actual Results:  
Nothing displayed in steps 2 and 3.

Expected Results:  
Step 2.: Display all prefs containing the substring "mailbox:" in the value
Step 3.: Display all user set charset preferences containing substring "iso-8859"

BTW, similar enhancements may be useful for filtering in mail window and address
book.

Comment 1

[Jo Hermans]

Related: bug 211041 (case-insensitive searches), which already has a patch.

I agree with a search for all fields, but the wildcards is a bit too much I
think. Next time, somebody will ask for regular expressions. We're not building
a search-engine after all, but a simple view-filter.

Comment 2

[Christian Franke]

Re comment 1: I agree that thinks should not be too complicated ;-)

But with a simple '*' wildcard search, a "pref.name*value" filtering would be
possible.

As an alternative to attachment 126740 [details] [diff] [review] from bug 211041, the following patch may
implement '*' wildcards (and fix bug 211041 also ;-)

xpfe/global/resources/content/config.js:
   if (substring) {
     gPrefView = [];
+    var rex = RegExp( substring.replace(/([^*A-Za-z ])/g, "\\$1")
+                               .replace(/[*]/g,".*")             , "i");
     for (var i = 0; i < gPrefArray.length; ++i)
-      if (gPrefArray[i].prefCol.toLowerCase().indexOf(substring) >= 0)
+      if (gPrefArray[i].prefCol.match(rex)) 
         gPrefView.push(gPrefArray[i]);
     if (gFastIndex < gPrefArray.length)

Sry, don't have Moz. development installed, so this patch is hand-made and
untested ;-)

Comment 3

[Christian Franke]

Attachment: Patch: search for "pref.name;status;type;value" with '*' wildcard

Function prefToString combines pref to semicolon separated string used for
matching. To restrict search to e.g. pref value, use something like
";*;*;*substring"

BTW, there is a bug in my comment 2: First replace() must not quote digits,
otherwise you get backreferences in the regular expression.

Comment 4

[Christian Franke]

Attachment: Patch: same as attachment 128769 plus optional regex support

As an alternative, this patch adds "expert mode" with a few more lines: When
the filter string begins with "!", the remaining string is interpreted as a
regular expression (Re comment 1: sry ;-). Partial or bad expressions match
nothing.

Comment 5

[Christian Franke]

Comment on attachment 128771 [details] [diff] [review]
Patch: same as attachment 128769 [details] [diff] [review] plus optional regex support

Thanks for confirming.
Patches still work with Mozilla 1.8a4 and current config.js 1.19.

r?

Comment 6

[[e-mail]]

The text for the status and type is localized so it doesn't make sense to filter
for it, except possibly using drop-down lists.
I don't think it's worth joining the name and value.
When filtering for regexps I suggest that a leading / should trigger a regexp
match, and untill you entered a valid regexp including trailing / then no search
would be done. Supporting trailing /i would be neat.

Comment 7

[Christian Franke]

Attachment: Patch: changed according to comment 6

Status and type removed, but name and value are still joined. Without this, you
lose the ability to search for name AND value with "name*value".
Regexps now work as suggested, including /i option, which is the default for
non-regexps.

Comment 8

[[e-mail]]

Comment on attachment 162582 [details] [diff] [review]
Patch: changed according to comment 6

>+  var substring = document.getElementById("textbox").value.toString();
toString is unnecessary, value is already a string.

>+  if (substring && substring.charAt(0) == '/') {
AFAIK substring.charAt(0) is safe even if substring is empty. Or use
/\//.test(substring)

>+    var r = substring.match(/^\/(.*)\/(i?)$/);
>+    if (r) {
>+      try {
>+        rex = RegExp(r[1], r[2]);
>+      }
>+      catch (e) {
>+      }
>+    }
>+    if (!rex) // Do nothing on incomplete or bad RegExp
>+      return
Missing ; also rather than a separate test you could return directly from the
catch block.

>+      rex = RegExp(substring.replace(/([^*0-9A-Za-z ])/g, "\\$1").replace(/[*]/g, ".*"), "i");
Nit: I think \w would work for 0-9A-Za-z

>+      if ((gPrefArray[i].prefCol + ";" + gPrefArray[i].valueCol).search(rex) >= 0)
Nit: if (rex.test(... + ";" + ...))

Comment 9

[Christian Franke]

Attachment: Patch: changed according to comment 8

> Missing ;
JS parser is obviously relaxed here ;-)

>also rather than a separate test you could return directly from the
>catch block.
The intention was to have only one early return for both cases ('else' and
'catch').
The new version handles the (!r) case by catching 'no properties' exception.

Comment 10

[Steffen Wilberg]

-> Christian.
You should request sr from a specific person.

Comment 11

[Christian Franke]

Comment on attachment 163337 [details] [diff] [review]
Patch: changed according to comment 8

> You should request sr from a specific person.
OK, was not sure whether bug owner or patch author should do this.

Comment 12

[Christian Franke]

Any chance to get patch checked in?

Comment 13

[:Gavin Sharp [email: [e-mail]]]

Landed on the trunk for tookit and xpfe.

mozilla/toolkit/components/viewconfig/content/config.js; new revision: 1.14;
mozilla/xpfe/global/resources/content/config.js; new revision: 1.24;

Comment 14

[Dick Guertin]

I have Firefox 2.0.0.4 (June 2007), and this still isn't implemented.  Therefore, Bug 103911 is still not resolved.  The ability to either Find or Filter within  about:config is important.  For example, I can't find "about:blank" as a Value.

Comment 15

[Steffen Wilberg]

This never made it onto the 1.8 branch, which was created on 2005-08-12. The trunk checkin was after that, on 2005-12-27. So this will be fixed in Firefox 3. Using a trunk nightly, you can filter by e.g. Firefox, and it displays a lot more prefs than just general.useragent.extra.firefox.

Comment 16

[Dick Guertin]

Yes, my point exactly.  This is classified as FIXED, but it "will be fixed", so it isn't fixed NOW (according to the classification).  It should be classified as PENDING.

Comment 17

[Unknown W. Brackets]

(In reply to comment #16)
> Yes, my point exactly.  This is classified as FIXED, but it "will be fixed", so
> it isn't fixed NOW (according to the classification).  It should be classified
> as PENDING.
> 

It is fixed in the current code base.  Please keep in mind - this bugzilla is not as much about the latest release as about the current development.  It would be impractical to manage bugs based on the latest release - especially if one were delayed for security or legal reasons.

The bug is fixed in the latest version.  That version simply has not yet been released to the general public.  If you wish to see it, you can - download a nightly or alpha version.

At some point, it will be verified fixed.  This means that someone has verified that it actually is properly fixed.  This typically happens either soon before or soon after release.  Resolved fixed just means no more development needs to occur.

-[Unknown]

Comment 18

[Dick Guertin]

So what you are saying is that after 18 months, it still hasn't made it to the general population?  That's like me taking my car to an auto shop to get it FIXED and the shop returns it to me saying "It is RESOLVED FIXED".  But I discover it still isn't fixed, and the shop guy says "It will be fixed in the model coming out in two years".  Sorry, I don't consider that RESOLVED FIXED.  RESOLVED PENDING would be a better classification, or specify which version of Firefox will get the fix.  Bugzilla needs to look at this forum as having an impact on users.  When I was pointed to this entry, I saw RESOLVED FIXED, and I was looking at that as a user, not a developer.  The last entry was 2005, so why was Firefox not working?  Can you see where the user's perspective is important?

Comment 19

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #18)
> Bugzilla needs to look at this forum as having an impact on users.

Bugzilla is mainly for use by developers and testers, not users. I don't think spending a significant amount of time trying to design our bug tracking system so that it can be used by people who aren't interested in our development process is a worthwhile goal.

Comment 20

[Dick Guertin]

Then I don't understand why Mozilla Forum moderators direct people like me (users) to post bug reports on Bugzilla.  Isn't that a primary way for Bugzilla to learn about suspected bugs?

Comment 21

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #20)
> Then I don't understand why Mozilla Forum moderators direct people like me
> (users) to post bug reports on Bugzilla.  Isn't that a primary way for Bugzilla
> to learn about suspected bugs?

Presumably they direct people like you to Bugzilla because they suspect you can contribute, or that you might be interested in getting further details about a bug. You don't need to be a developer to contribute to Bugzilla successfully, but you need to be willing to accept that Bugzilla isn't a support forum or end-user notification system.

Comment 22

[Dick Guertin]

OK, I can accept that, but I didn't know that was the intend of Bugzilla.
I'll wait for Firefox 3 (although any sooner would be better).

Comment 23

[RNicoletto]

Sorry for bugspam, but I'm still unable to find a way to filter "about:config" entries based of "State" or "Value" parameters. 
Both MDN and Mozillazine Knowledge Base don't provide enough information about this topic.
Thanks!