292904 - --enable-extensions=typeaheadfind breaks fastFind

Status: RESOLVED WONTFIX

(Toolkit :: Find Toolbar, defect)

Description

[Boris Zbarsky [:bzbarsky]]

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]

Comment 1

[Brendan Eich [:brendan]]

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

Comment 2

[Peter van der Woude [:Peter6]]

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

WFM

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 4

[Mike Connor [:mconnor]]

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.

Comment 5

[Benjamin Smedberg]

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.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(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.

Comment 7

[Christian Persch (GNOME) (away; not receiving bug mail)]

(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).

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 9

[Christian Persch (GNOME) (away; not receiving bug mail)]

Attachment: rename typeaheadfind extension

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?

Comment 10

[Benjamin Smedberg]

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.

Comment 11

[Christian Persch (GNOME) (away; not receiving bug mail)]

(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...

Comment 12

[:Gavin Sharp [email: [e-mail]]]

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

Comment 13

[Serge Gautherie (:sgautherie)]

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

Comment 14

[Boris Zbarsky [:bzbarsky]]

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

Comment 15

[:Gavin Sharp [email: [e-mail]]]

the TAF extension is dead