Closed Bug 251543 Opened 21 years ago Closed 21 years ago

find toolbar doesn't find a thing

Categories

(Toolkit :: Find Toolbar, defect)

Product:
Toolkit
Component:
Find Toolbar
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: axel, Assigned: bugzilla)

References

Details

(Keywords: regression)

On a fresh aviary build from today, with fresh profiles (removed both ~/.firefox and ~/.mozilla/firefox) on a freshly converted mozilla profile, typing /build on http://www.mozilla.org/developer/ opens the find toolbar, but doesn't find any text. I get a js error in the js console for each keystroke, Error: uncaught exception: [Exception... "Component returned failure code: 0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE) [nsIJSCID.createInstance]" nsresult: "0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE)" location: "JS frame :: chrome://global/content/bindings/browser.xml :: get_fastFind :: line 242" data: no]
Make sure you have removed typeaheadfind from --enable-extensions in your .mozconfig file: http://snipurl.com/7s1x
I had the binary still around, I clobbered the extension and dist/bin and dist/lib and built depend. I'll try a clobber build as soon as I find the time, which may be as late as july 26th.
*** Bug 251660 has been marked as a duplicate of this bug. ***
WFM with the current official nightly on winXP. Find is broken with my own build, but I have typeaheadfind in my extensions list.
WORKSFORME after a brute force clobber. Removed objdir and built from scratch. If Chris doesn't object, this can be closed.
I didn't do a clobber build after removing typeaheadfind, and it doesn't WFM. I'll do a clobber, and if it WFM we can close.
Doesn't WFM either on a linux build from fresh CVS. Does it depend on GnomeVFS?
If this is related, I've found that the find toolbar doesn't work at all on the Ars Technica forums. http://episteme.arstechnica.com/
(In reply to comment #8) > If this is related, I've found that the find toolbar doesn't work at all on the > Ars Technica forums. http://episteme.arstechnica.com/ I just tried the Ars Technica main page, and the find stops working if FAYT has no results and the find toolbar closes. This is bug 251996 which I filed yesterday. Try the steps I layed out in this bug, and you'll see what I mean.
I'm also experiencing these problems, with a clean CVS build from 19/07/2004, a clean profile, and no mention of typeaheadfind in the --enable-extensions option. I get the same errors in the javascript console. After pressing Ctrl+F, entering a word produces no highlighting of any kind, nor movement in the page, the find next and find previous buttons do not produce any effect, nor is there any text in the status bar as letters are being typed. This actually hinders my browsing a fair deal, but this is a nightly build and there's always that risk involved. What I would like to do is offer any help I can testing/rebuilding things until this problem can be fixed...
The web page mentioned in the opening of this bug works fine for me. Before I new this bug existed, I opened bug 251996 which now has two different test cases from seperate web sites on which FAYT does not work. The symptoms of the defects are similar to those described here, but not with the javascript error mentioned in this bug. Should the bug I opened, bug 251996, be marked a duplicate of this one??
Well, this bug affects me on every page (in other words, I haven't found a page the find works on), whereas your bug sounds as if it's on specific pages. Also if you're not producing the same js errors (and two of us have managed to come up with identical errors), then yours is almost certainly a different problem. Hope this helps...
WORKSFORME with the 20040722 branch nightly build (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040722 Firefox/0.9.1+). This bug seems to be fixed with yesterdays checkins of Blake Ross for bug 248423, bug 250482, bug 250922, bug 250942, bug 251860 and bug 222410.
Hi, I'm still experiencing this, with a fresh aviary build and new profile. I'm still getting no user feedback, type ahead find is not working, either with or without the option checked under advanced, and I'm still getting the javascript error about get_fastFind on line 242 of global/content/bindings/browser.xml. Any suggestions for tests, or precise build options would be useful, it's quite possible I'm just building the thing incorrectly, but I have no frame of reference. Any other help would also be greatly appreciated, thanks...
Ok, A completely clean CVS build, removal of all old profiles (including the initial setup by root) seems to have done the trick and I'm now getting a fully functioning find toolbar. So unless anyone else is still experiencing the bug, we can probably close it now. Sorry for the inconvenience... Mike 5:)
WORKSFORME, finally. Changes that require a clobber build could use a announcement in the newsgroups. .builds may do, including .browser and .seamonkey would be good, too.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
*** Bug 260205 has been marked as a duplicate of this bug. ***
*** Bug 260065 has been marked as a duplicate of this bug. ***
I am seeing this bug in the preview release. My JS console shows the exact error given by the original reporter, character for character. Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040921 Firefox/0.10. I'm running on Gentoo Linux on a 2.6.7 kernel; I did an emerge unmerge of the existing version of Firefox, then I removed all remaining files in /usr/lib/MozillaFirefox (and the dir itself), then I emerge'd the new Firefox. I also blew away my profile and allowed Firefox to create a new one, then copied over the following files from my backed up profile: formhistory.dat, history.dat, cert8.db, key3.db, bookmarks.html, cookies.txt, signons.txt, adblock.txt, localstore.rdf, user.js, tabextensions.rdf. I have tried reverting to the original .rdf files to see if that made a difference; it does not. I have tried playing with different combinations of typeaheadfind settings in about:config, but that seems to make no difference either. Suggestions would be appreciated. To avoid having to create a new bug and losing this valuable history, I'm requesting that someone sufficiently empowered reopen this bug. Thanx.
see: http://bugs.gentoo.org/show_bug.cgi?id=64196 for a patch to the gentoo ebuild.
Yes, that fixes it. Thanx Herbie.
*** Bug 260416 has been marked as a duplicate of this bug. ***
*** Bug 261250 has been marked as a duplicate of this bug. ***
See also bug 270114
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.