Closed Bug 292904 Opened 15 years ago Closed 7 years ago
--enable-extensions=typeaheadfind breaks fast
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.
Summary: Find doesn't work → --enable-extensions=typeaheadfind 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.
Severity: blocker → minor
(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
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.