The default bug view has changed. See this FAQ.

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

RESOLVED FIXED

Status

SeaMonkey
Preferences
--
enhancement
RESOLVED FIXED
14 years ago
5 years ago

People

(Reporter: Christian Franke, Assigned: Christian Franke)

Tracking

Bug Flags:
blocking1.8a5 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 3 obsolete attachments)

(Assignee)

Description

14 years ago
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

14 years ago
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.
(Assignee)

Comment 2

14 years ago
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 ;-)
(Assignee)

Comment 3

14 years ago
Created attachment 128769 [details] [diff] [review]
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.
(Assignee)

Comment 4

14 years ago
Created attachment 128771 [details] [diff] [review]
Patch: same as attachment 128769 [details] [diff] [review] 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.

Updated

13 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 5

13 years ago
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?
Attachment #128771 - Flags: review?(bugs)

Updated

13 years ago
Attachment #128771 - Flags: review?(bugs) → review?(neil.parkwaycc.co.uk)

Comment 6

13 years ago
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.
(Assignee)

Comment 7

13 years ago
Created attachment 162582 [details] [diff] [review]
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.
Attachment #128769 - Attachment is obsolete: true
Attachment #128771 - Attachment is obsolete: true
(Assignee)

Updated

13 years ago
Attachment #162582 - Flags: review?(neil.parkwaycc.co.uk)

Comment 8

13 years ago
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(... + ";" + ...))
(Assignee)

Comment 9

13 years ago
Created attachment 163337 [details] [diff] [review]
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.
Attachment #162582 - Attachment is obsolete: true
(Assignee)

Updated

13 years ago
Attachment #163337 - Flags: review?(neil.parkwaycc.co.uk)

Updated

13 years ago
Attachment #163337 - Flags: review?(neil.parkwaycc.co.uk) → review+
(Assignee)

Updated

13 years ago
Attachment #163337 - Flags: superreview?

Comment 10

13 years ago
-> Christian.
You should request sr from a specific person.
Assignee: bugs → Franke
(Assignee)

Comment 11

13 years ago
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.
Attachment #163337 - Flags: superreview? → superreview?(sspitzer)

Updated

13 years ago
Attachment #128771 - Flags: review?(neil.parkwaycc.co.uk)

Updated

13 years ago
Attachment #162582 - Flags: review?(neil.parkwaycc.co.uk)
(Assignee)

Comment 12

13 years ago
Any chance to get patch checked in?
Flags: blocking1.8a5?

Updated

13 years ago
Flags: blocking1.8a5? → blocking1.8a5-
Product: Browser → Seamonkey
(Assignee)

Updated

12 years ago
Attachment #163337 - Flags: superreview?(sspitzer) → superreview?(mconnor)

Updated

11 years ago
Attachment #163337 - Flags: superreview?(mconnor) → superreview+
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;
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Comment 14

10 years ago
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

10 years ago
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

10 years ago
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

10 years ago
(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

10 years ago
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?
(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

10 years ago
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?
(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

10 years ago
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

5 years ago
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!
You need to log in before you can comment on or make changes to this bug.