Closed Bug 103911 Opened 24 years ago Closed 13 years ago

Find in this page in about:config does not work

Categories

(SeaMonkey :: Preferences, enhancement)

Product:
SeaMonkey
Component:
Preferences
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: nine, Unassigned)

References

(
URL
)

Details

(Keywords: helpwanted, Whiteboard: [2012 Fall Equinox])

Mozilla has pretty many preferences and it's cool to have them listed in about:config but it'd be nice if someone could even search for them in this huge list. Steps to reproduce: 1. go to about:config 2. press Ctrl+F for find in this page dialog 3. search for something Actual result: nothing is found dialog shows Expected result: lines with matches should be marked (just like on a normal page)
reassign to chipc
Assignee: sgehani → chipc
Status: UNCONFIRMED → NEW
Ever confirmed: true
this would be very useful! nominating...
Keywords: mozilla0.9.7
I was just about to log this as well. This is also 4xp. Since Nav4 didn't use any fancy control, you could easily search the list.
Keywords: 4xp
taking about:config bugs from chipc.
Assignee: chipc → sspitzer
Take a simple page with a big textarea. Try to find anything in this textarea... You can not ! It seems that the find function is not looking into every element. This is very annoying. Should be corrected for Mozilla 1.0. (I try with build RC 1 : 2002041711)
*** Bug 155380 has been marked as a duplicate of this bug. ***
*** Bug 180381 has been marked as a duplicate of this bug. ***
note that find as you type was disabled for xul displays such as about:config (bug 190495.
*** Bug 194378 has been marked as a duplicate of this bug. ***
I see that this bug is marked as an enhancement, but couldn't it be considered a defect? I mean, it's normal to expect that any page should be searchable, so when one page isn't, then it's a bug that should be fixed.
about:config is not a "page". It's part of the browser UI. And a hidden one at that. No normal non-developer user should be accessing it, unless asked to do so to debug a problem.... So any changes to it are indeed enhancements. (For comparison, is it a problem that you can't do "find in this page" on the browser menus? Or on the mailnews window if you load it in browser via a chrome URL?)
> No normal non-developer user should be accessing it I strongly disagree. In the first place, "About Config" is available right in the Help menu. It's also available as the Preferences editor under QPrefs, if you use Multizilla. In the second place, about:config is a very useful feature, and not just for Mozilla developers. As the documentation points out (I can't remember now where), Mozilla has far too many preferences to have a UI element for each one in the Edit Preferences dialog. The only way to get at these other preferences is either to find and edit prefs files by hand, or use about:config. I love about:config. When I want to do surgery on profiles, I go to about:config. It's a great feature, and Moz developers should be proud to have made all of Moz's settings so fully and easily available to us, the users. If you could add a Find, or, dare I say it, Find and Replace, to about:config, you would give us a powerful tool for managing our browsing experience.
I think this bug is perfectly legit, it just deserves very low priority. It would be nice to have "Find in page" for about:config, but come on.. sure a few people use about:config, but most people are not going to be using about:config, let alone going to need to Find In Page... (and I don't care what menu item its under, especially in MultiZilla which is an external project!)
>"About Config" is available right in the Help menu. Not in mozilla.org builds. It was probably added by some extension you installed.
> >"About Config" is available right in the Help menu. > > Not in mozilla.org builds. It was probably added by some extension you installed. OK. Probably Multizilla, though their site doesn't say.
Andrew E. Schulman: http://multizilla.mozdev.org/features/other-features.html "- Modified Help menu" "- extra menu item 'About Config' (displays all active preference settings)" "sure a few people use about:config, but most people are not going to be using about:config" Yeah, but only because it doesn't work like they wanna use it!
Surely arguing that few people will use this is silly. At least 6 dups and 11 votes have been filed. Surely, it was only a small oversite, which prevents find from working on this page. Surely it is not asking too much to make it work like the rest of the interface. I have gone to about:config several times to try to find something, and cursed every time the lack of find.
so why don't you fix it? i'll give you five days. it's not easy to fix this, find is implemented for html and might be implemented for text, it is *not* implemented for xul, and implementing it is not simple. hurry up and fix it already.
Assignee: sspitzer → der1way
Adding myself to CC:list because i guess with the option to actually make changes in about:config [and not just listing them] being able to search about:config really can be convenient...at least for me ;)
voting for this bug. I think that about:config in which it is impossible to to a text find is slightly useless.
There also other XUL places where something like "Find In Page" would be useful, not only about:preferences (Preference Editor that is). For example Bookmarks sidebar has nice search feature (it is Search... button, which pops up "Find Bookmarks" dialog, where you can select which part of bookmarks (name, location, description, keyword) you want to search for (although it would be nice not to have combo box, but the list of checkboxes: I want to search both name and location and only them) and also Search field which does search as you type (also called *incremental* search) at least both name and location). History sidebar has no such feature, nor CookieBar sidebar (add-on)). I think tah because Bookmarks Manager has those features... but it is where one can borrow code from. For me it would be nice to "Search In Page" and "Find As You Type" for XUL made pages like about:preferences and Search for more than one search engine choosen, but it would be enough to have Search form and/or Search button.
See bug 207840 which implements this idea (with a patch !), although slightly differenty. It doesn't use Ctrl-F or a find dialog box, but a search-bar similar to the one in mail/news. I can't dupe one against the other, but bug 207840 would certainly solve this problem. We'll just have to add a Ctrl-F to show the searchbar (or jump to the textfield).
Depends on: 207840
Regardless of bug 207840, this bug continues to have a useful purpose. The "easiest" way I can think of accomplishing the goal of making find-in-page work would be to cheat: rewrite the config page to be an HTML page which is generated by javascript. Sorting could be handled the same way as apache directory listings (the prefs would be in an HTML table and the titles would be javascript links). It should be pretty easy to do in DOM, and I may take a whack at it today if I don't end up working on the filtering patch. So I don't accidentally step on any toes, I'l like to ask you the current assignee is doing with it (Don Erway). Do you (Don, or anyone else for that matter) have any ideas/suggestions about how to handle it, or perhaps some concept code?
After speaking with someone, I've accepted that HTML-izing about:config would only be a temporary hack, since there are some plans in store for about:config that would not work in HTML. Also, that would be ignoring the obvious need for a working Find service for XUL documents.
Please remove derway as assignee. I've worked on gnu emacs, and various other bits of opensource here and there, but never ever built a mozilla from source. I have no idea how I got assigned this. All I ever did was comment on it.
Assignee: der1way → ben
I have a question for people who want this functionality: would the functionality provided by bug 207840 satisfy you (either as-is or with the filtering applying to all visible fields and not just the pref name)? I ask because I've looked at teaching Find about XUL Tree elements, and it would not be trivial or pretty (the about:config tree is fed by a dynamic data source; currently, Find just walks the DOM; the data source is not reflected into DOM in any way). Trees can be fed by dynamic data sources or they can be determined by their DOM children. If this were to be implemented, Find would have to make a special case for XUL Tree elements where it digs through the data source itself. Alternately, some mechanism could be provided for XUL data sources to expose their own search functionality so that Find could defer to the document somehow. I'm just thinking out loud, and I don't think I'd be up to the latter change (it sounds possible, just more work than I want to do in this area of mozilla). Lastly, I'm not convinced all this work would be worthwhile, since it would seem to only benefit a hidden feature (about:config). Sorry for the spam.
Yes, that would work for me. If I can search on regular expressions in any field... I don't know what else I'd need.
Comment in the other bug if you want regex support (or details of what you'd like); right now, it's a non-regex search in the preference name field due to lack of suggestions.
Yes, 207840 should be adequate. It is certainly, at least, a big improvement over visually scanning hundreds of lines.
*** Bug 209185 has been marked as a duplicate of this bug. ***
*** Bug 225261 has been marked as a duplicate of this bug. ***
*** Bug 235449 has been marked as a duplicate of this bug. ***
As there hasn't been any negative answer to comment 26, resolving this as a dupe of fixed bug 207840. *** This bug has been marked as a duplicate of 207840 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
This bug is definitely not a dup of bug 207840. Using Mozilla 1.7Beta, I can go to about:config, and still access Edit -> Find in this page. The "Find in this page" window will come up, and anything I enter will not be found. To fix this bug, either grey out "Find in this page" or make it work. Since the same functionality is already present through bug 207840, I'd say just grey it out. Either way, it is not a dup. If everyone agrees, I'd like to reopen this bug.
that seems reasonable. lets reopen This looks like what we want to change: http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/nsBrowserStatusHandler.js#242 basically it uses mimeTypeIsTextBased() to set the isImage broadcaster. sounds like we should either add xul to that (so that mimeTypeIsTextBased() returns false for xul) or add another type of check to detect XUL
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(In reply to comment #35) > that seems reasonable. lets reopen > > This looks like what we want to change: > http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/nsBrowserStatusHandler.js#242 > > basically it uses mimeTypeIsTextBased() to set the isImage broadcaster. > > sounds like we should either add xul to that (so that mimeTypeIsTextBased() > returns false for xul) or add another type of check to detect XUL Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20041003 Firefox/0.10 Not XUL in general please, that would remove the find function in ChatZilla too. Just disable it in about:config would be fine enough.
> Steps to reproduce: > 1. go to about:config > 2. press Ctrl+F for find in this page dialog > 3. search for something > Actual result: nothing is found dialog shows This is still the case in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1
> either grey out "Find in this page" or make it work. grey out. It is hard to make it work. I had a look at this when working on Find a little while ago. Add to this the issue of _selecting_ the found text in the XUL... Simply put, it is not worth the effort. Better to improve the Filter to find in keys and values as well (bug 213832).
Product: Browser → Seamonkey
Assignee: bugs → prefs
Status: REOPENED → NEW
QA Contact: bugzilla
Can somebody say again why this feature can't be implemented? Now, on Firefox 2.0.0.13 in April 2008 we still can not search chrome's configuration file.
(Filter "spam" on 'prefs-nobody-20080612'.)
Assignee: prefs → nobody
QA Contact: prefs
Current about:config UI contain build-in search panel, so closing this as WFM
Status: NEW → RESOLVED
Closed: 21 years ago → 13 years ago
Resolution: --- → WORKSFORME
Whiteboard: [2012 Fall Equinox]
You need to log in before you can comment on or make changes to this bug.