BUILD: 2005-05-04-08 Linux nightly or Linux trunk debug build pulled at MOZ_CO_DATE="Wed May 4 01:56:31 CDT 2005" (but with caps/src/nsScriptSecurityManager.cpp updated to tip). STEPS TO REPRODUCE: 1) Start browser. 2) Load web page. 3) Hit Ctrl-F 4) Try to find something EXPECTED RESULTS: find things ACTUAL RESULTS: No response. Debug build shows: JavaScript error: , line 0: 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/tabbrowser.xml :: get_fastFind :: line 1569" data: no]

I also see this in the shell in which I run firefox: JavaScript error: chrome://global/content/bindings/tabbrowser.xml, line 1570: this._fastFind.init is not a function I saw bz say this worked in the 05-03-08 build works. It sounds too as though this is not showing on Windows, from what folks say on IRC. mconnor, you see anything like this? Cc'ing bsmedberg too. /be

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050505 Firefox/1.0+ 03:38 pdt build WFM

So the problem here seems to be for people who build with --enable-extensions=all. toolkit/components/typeaheadfind/ contains an interface with the same name (nsITypeAheadFind) and completely different contents as the original one in extensions/typeaheadfind/ . This means --enable-extensions=all breaks FastFind.

Oh, that's what this is? known bug, dating to fastfind's landing, I thought this was widely known... FYI, building wallet causes pain too (and crashes on the Privacy pane in 1.0.x). I thought that part of the new build mojo on trunk was going to prevent building extensions that don't work right with product X.

We should alter MOZ_EXTENSIONS_ALL at http://lxr.mozilla.org/mozilla/source/configure.in#4243 to be smarter about what extensions are incompatible with various apps.

(In reply to comment #5) > We should alter MOZ_EXTENSIONS_ALL at > http://lxr.mozilla.org/mozilla/source/configure.in#4243 to be smarter about what > extensions are incompatible with various apps. I filed bug 299186 for this issue. There should be a compatibility list of extensions for every available product.

(In reply to comment #6) > (In reply to comment #5) > > We should alter MOZ_EXTENSIONS_ALL at > > http://lxr.mozilla.org/mozilla/source/configure.in#4243 to be smarter about what > > extensions are incompatible with various apps. > > I filed bug 299186 for this issue. There should be a compatibility list of > extensions for every available product. The typeaheadfind extension is an important component for embedders. Since more and more distributions are building their packages against firefox' gtkmozembed instead of suite, the typeaheadfind extension should be made to coexist peacefully with fastfind. I have a patch for this which consist in renaming the typeaheadfind extension to 'typeaheadfindsea' (sea for "seamonkey") here: http://www.gnome.org/~chpe/taf.diff (backend changes only; needs some tiny changes to xpfe/ too to use the changed contractID and interface name).

I think a complete version of that patch would be very nice to have, thanks!

This patch renames the typeaheadfind extension to typeaheadfindsea ("seamonkey"). Most of the patch is just s/typeaheadfind/typeaheadfindsea/g in various capitalisations. Some cvs moves might be wanted instead of just removing/adding some files with the "sea" added into their names. I've searched for "typeaheadfind" on lxr [http://lxr.mozilla.org/seamonkey/search?string=typeahead] and changed all places I think where it's needed. I tested a linux gtk2 build of seamonkey suite with the patch, and typeaheadfind still works. Can someone suggest who to ask for r/sr, please?

Why can't embedders use fastfind? About the patch in particular, I don't see why we need to move/rename any files in CVS: just rename the interface within the existing file. You shouldn't even need to rename the implementation class at all. I'm not sure there is a need to rename the prefs either: we should definitely examine whether the pref names overlap poorly before doing a global rename, to avoid breaking existing users' settings.

(In reply to comment #10) > Why can't embedders use fastfind? Using typeaheadfind extension is setting one pref to 'true' (and it even defaults to true using suite's gtkmozembed). Fastfind requires you to write your own C++ code to use it. Plus, fastfind works differently (no statusbar output for example). > About the patch in particular, I don't see why we need to move/rename any files > in CVS: just rename the interface within the existing file. You shouldn't even > need to rename the implementation class at all. I don't remember exactly why I renamed the class... fastfind and typeaheadfind ext are both named nsTypeAheadFind; won't those symbol names clash? > I'm not sure there is a need to rename the prefs either: we should definitely > examine whether the pref names overlap poorly before doing a global rename, to > avoid breaking existing users' settings. At least the main pref, accessibility.typeaheadfind *has* to be renamed to something else, since otherwise the typeaheadfind extension will also be active within firefox and mess up the findbar/fastfind. The other prefs might be shared, but I'm not sure that they all should have same value between fastfind and typeaheadfind ext...

*** Bug 317898 has been marked as a duplicate of this bug. ***

Is this still an issue with current Gecko 1.9.1b2 ? (I think this (code) is obsolete...)

This is still an issue, yes (though at this point typeaheadfind isn't in m-c, so it just doesn't build by default).

the TAF extension is dead