--enable-extensions=typeaheadfind breaks fastFind

RESOLVED WONTFIX

Status

()

Toolkit
Find Toolbar
--
minor
RESOLVED WONTFIX
13 years ago
5 years ago

People

(Reporter: bz, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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

Comment 5

13 years ago
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
Keywords: smoketest
(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.
Blocks: 292964
Depends on: 299186
(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!
Created attachment 192121 [details] [diff] [review]
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

13 years ago
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. ***
(Assignee)

Updated

9 years ago
Product: Firefox → Toolkit
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
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.