Closed Bug 103911 Opened 19 years ago Closed 8 years ago

Find in this page in about:config does not work

Categories

(SeaMonkey :: Preferences, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: nine, Unassigned)

References

()

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: 17 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
Duplicate of this bug: 407834
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.
Duplicate of this bug: 438039
(Filter "spam" on 'prefs-nobody-20080612'.)
Assignee: prefs → nobody
QA Contact: prefs
Duplicate of this bug: 445006
Current about:config UI contain build-in search panel, so closing this as WFM
Status: NEW → RESOLVED
Closed: 17 years ago8 years ago
Resolution: --- → WORKSFORME
Whiteboard: [2012 Fall Equinox]
You need to log in before you can comment on or make changes to this bug.