the find toolbar in 1.0pre is broken pretty badly for me when compiling from source, it's fine in firefox-bin however. I think it's because the mozilla.eclass is putting typeaheadfind in the extension list with this line: myext="cookie,inspector,negotiateauth,pref,transformiix,typeaheadfind,universalchardet,webservices,xmlextras,xml-rpc" and causing this: http://bugzilla.mozilla.org/show_bug.cgi?id=251543 however I won't know for another 40 to 50 minutes. (recompiling without typeaheadfind now)
my guess was correct, removing typeaheadfind from the extensions has fixed this problem. Perhaps firefox needs it's own eclass?
I also noticed this. I was trying to use type ahead find without that silly toolbar, and it correctly highlights the first term, but using Accel-G (find next) doesnt work. Works fine with the -bin ebuild.
see also bug 64263 Find toolbar in Firefox 1.0 PR doesn't work http://bugs.gentoo.org/show_bug.cgi?id=64263
pretty sure that's a dupe of this bug.
I just rebuilt Firefox with this option left out, and although it seemed to fix a few problems with the find toolbar, type as you find is completely broken.
I had thought find as you type was no longer included however it is, though when I upgraded firefox it disabled it for some reason. Are are you sure it's enabled at preferences>advanced>accessibility>find as you type? You can also use /searchterm now, which is what I do. I never used find as you type although I had it enabled before the upgrade, and thus noticed it was disable after it. I could be mistaken though...
Yeah, it's definitely enabled. I even checked in about:config to make sure. Also when I use find as you type (in the original build), the find toolbar doesn't show up, but no text is shown in the status bar. I'm not sure if this is related at all, though.
I also had to remove compreg.dat from my profile to get it to work again.
a quick workaround is to change myconf="${myconf} \ --with-default-mozilla-five-home=/usr/lib/MozillaFirefox \ --enable-single-profile" to myconf="${myconf/typeaheadfind/-typeaheadfind} \ --with-default-mozilla-five-home=/usr/lib/MozillaFirefox \ --enable-single-profile" in mozilla-firefox-1.0_pre.ebuild
according to the bug at mozilla many people needed to completely wipe their build folder to fix this, as for wiping pieces of your profile, I would have no idea, but I would try moving it out of the way temporarily if the problem is still occuring to see if it fixes it....you can see in the mozilla bug it took a few people multiple tries before finally getting this to go away...
also, a simpler fix then the one above would be just using ${myconf/typeaheadfind,/} typeaheadfind won't be added on by anything else so you don't need to put -typeaheadfind in the list.
*** Bug 64263 has been marked as a duplicate of this bug. ***
Confirmed with Comment #10. see my comment at the end of Bug #64263
RE #11 > according to the bug at mozilla many people needed to completely wipe their > build folder to fix this, as for wiping pieces of your profile, I would have no as mentioned in #8 all that needs to be removed is compreg.dat from your profile. > idea, but I would try moving it out of the way temporarily if the problem is > still occuring to see if it fixes it....you can see in the mozilla bug it took a > few people multiple tries before finally getting this to go away... they probably did not remove compreg.dat
I can confirm that I had to remove compreg.dat to get the find bar working after a recompile
Same here. I had to remove the typeahead and recompile and delete compreg.dat and now it is working as it should.
*** Bug 64546 has been marked as a duplicate of this bug. ***
The reason it took the mozilla people multiple tries is they usually have a build dir around which they update from cvs, then only build the changed bits (no "make clean" or equivalent). Since portage starts from scratch every time you merge, that doesn't apply here. I don't know what bits of profile are affected, but it seems to be only compreg.dat here.
Portage doesn't always start from scratch. You must have autoclean enabled and be using emerge. I was using ebuild to merge this when I was working on it so in my case I did need to wipe my build dir before proceeding. However I'm perfectly aware most people won't run into this. I also didn't have to wipe compreg.dat, not sure why. So I was making some guesses about it... Eitherway the solution to this bug has been found so I assume it'll be fixed soon...
So this serious bug got into stable because nobody at Mozilla bothered to try a fresh recompile before releasing? Makes one wonder about the overall stability of firefox.
Is that a bug in mozilla's firefox sources? because then how come the bin works well? I thought it's a problem in the ebuild that makes the compiled binary work that way, and as such it should have been maybe fixed by now
Created attachment 40053 [details, diff] patch to fix the problem here's a patch
I can confirm that the patch in #22 works fine. Can a real -r1 release be issued? No type-ahead find is *super* annoying for those who are used to it.
typeaheadfind should work fine though, it does for me once I enable it. It's part of the find toolbar now so the extension option isn't needed anymore.
While the patch in #22 mostly fixes the find toolbar, I found a couple of problems. 1) The highlight button doesn't do anything. No big deal. 2) Firefox built with this patch is very flakey when trying to submit bug reports here. Big deal. It took me about 7 or 8 tries to create a new bug report because Firefox kept crashing (/usr/bin/firefox: line 388: 2535 Segmentation fault $mozbin "$@") when I clicked in the various edit boxes. I finally had to create my bug report in emacs and then cut n paste it into the various boxes. I don't know if the problem is related to this patch or if it is a general 1.0pre problem, because I haven't done any major form filling with 1.0pre up until now.
I tried to apply the patch from #22 by changing the src_unpack portion of the ebuild to include an epatch line like this: ----- src_unpack() { unpack firefox-${MY_PV}-source.tar.bz2 || die "unpack failed" epatch /usr/portage/net-www/mozilla-firefox/files/mozilla-firefox-1.0_pre-r1.ebuild.patch cd ${S} || die "cd failed" # alpha stubs patch from lfs project. # <taviso@gentoo.org> (26 Jun 2003) use alpha && epatch ${FILESDIR}/mozilla-1.3-alpha-stubs.patch } ----- I get a patch failed message when trying to re-emerge and the *.out file says this: ----- can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? ----- Should I have done something differently? - Grant
Here's what you need to do to apply this patch (please verify all these commands before you blindly type them in; I'm typing from memory here): 1) Make sure your portage overlay is turned on. vi /etc/make.conf [or whatever editor you prefer] PORTDIR_OVERLAY="/usr/local/portage" [find this line; uncomment it if necessary] 2) Make a place for your new ebuild. mkdir -p /usr/local/portage/net-www 3) Copy over the old ebuild dir. cp -pr /usr/portage/net-www/mozilla-firefox /usr/local/portage/net-www 4) Clear out the stuff you don't need. cd /usr/local/portage/net-www/mozilla-firefox rm mozilla-firefox-0* files/digest* files/firefox-0* 5) Save the attachment from #22. vi files/r1-patch [make sure you're still in /usr/local/&c] [paste in the text of the attachment; save and exit] 6) Patch the ebuild and rename it. patch <files/r1-patch [still in /usr/local/&c] mv mozilla-firefox-1.0_pre.ebuild mozilla-firefox-1.0_pre-r1.ebuild 7) Create your digest. ebuild mozilla-firefox-1.0_pre-r1.ebuild digest 8) Now you should see the new ebuild as an update possibility: emerge -ua mozilla-firefox That should do it. I'm emerging mine now, so we'll see how it goes ...
Ignore the segfault described in comment #25. It happens with and without the patch from #22. I will open a new bug later (if I can). Some odd behavior I noticed when I downgraded to firefox built without patch #22: the find toolbar was still working even though I was running a broken version of firefox. I moved the compreg.dat file out of the way and restarted firefox. Now the broken find toolbar is back. Although there are lots of differences between the two versions of the compreg.dat file, I found a few that seem relevant. The dat file with a working find toolbar is the <, while the broken one is the >. 368a370 > {46590685-bc00-4aac-abed-2c10a5b945a4},,,,rel:libtypeaheadfind.so 1330c1332 < @mozilla.org/typeaheadfind;1,{e7f70966-9a37-48d7-8aeb-35998f31090e} --- > @mozilla.org/typeaheadfind;1,{46590685-bc00-4aac-abed-2c10a5b945a4} 1809a1812 > app-startup,Type Ahead Find,service,@mozilla.org/typeaheadfind;1
I found a third difference: > rel:libtypeaheadfind.so,1096043818000,libgkgfx.so libxpcom.so libplds4.so libplc4.so libnspr4.so libpthread.so libdl.so Unfortunately, simply removing the three extra references to typeaheadfind in the dat file did not fix the find toolbar problem.
Confirm that the patch from #22 works for me. I think this should be incorporated into the ebuild ASAP. Possibly the current one should be marked unstable.
*** Bug 64569 has been marked as a duplicate of this bug. ***
Patch from #22, installed according to comment #27 did work, "find as you type" now works as before (i.e. correctly). But there seems to be another problem, the following happens: - The extensions window seems to be empty, none of my extensions show up. - I can't install new extensions: when I try to install a new one, I get the dialog if I really want to install it, and the next window (usually showing the progress) just hangs - Nonetheless, the extensions still are loaded, they have their menu entries, mouse gestures work and I still can block ads. I was quite happy that with the new firefox (1.0pre) I didnt have to reset all my settings (~/.mozilla/firefox/...). Anyone here who can confirm this strange behaviour?
PS: My problem (#32) also happens with the .mozilla directory removed/renamed.
Alright this bug is being stretched out a little long for something with such an easy fix, is there anything preventing this from getting into portage? what's the hold up? All of the other problems people were having listed in this bug ended up being separate issues. I don't know if the patch's method of simply wiping the compreg.dat out of /home/*/.mozilla/firefox/*/ is portage-friendly, however the basic methods proposed in this ebuild to remove typeaheadfind out of the configuration are quite simple, and don't seem to break anything. Even if compreg.dat isn't removed or fixed by the ebuild, at least firefox won't need to be rebuilt. So if anything gets in to porage, that should, to prevent having to rebuild firefox over a trivial issue. I don't mean to be pushy but this is a real annoying bug that effects quite a lot of people.
indeed this is a very annoying bug, i doubt this ebuild should be marked x86 stable. in an case the compreg.dat thing does not seem to help. i actually emerged this version of firefox over new install and cleaned the configuration several times. what i did not try is the patch, but i believe there's no fix without recompiling. and this is getting too long and should already be fixed in portage.
I can confirm the same problem with the patch as in #32. My extensions and theme windows are both empty, but it seems like new extensions will still install and be configurable. Of course, this makes it impossible to change to a new theme though. I uninstalled the source build and am installing the binary package now. I wouldn't bring the patch into portage until this issue is fixed.
those two problems don't happen to be because you're using old extensions and don't have the "show old extensions" extension installed do they?
The highlight problem I mentioned in comment #25 was fixed by deleting the file .mozilla/firefox/default.*/chrome/chrome.rdf.
Do upstream know about this bug? Are they going to fix it, or is it up to us to make sure there is working sources available for firefox?
Please, release a working ebuild ASAP. The browser is next to unusable without any working search methods. :-(
Even with the broken find toolbar, you can still enable find-as-you-type: Edit -> Preferences -> Advanced -> Accessibility -> Use Find As You Type. You'll need to restart the browser, but find-as-you-type will work afterwards. HOWEVER, I agree: A fixed ebuild needs to be marked stable ASAP!
@Jordan (#37): The problem with the extensions window not working (#32) and new extensions not being installed happen also when there is no ~/.mozilla directory, I hope this answers your question. I am using the patched (http://bugs.gentoo.org/attachment.cgi?id=40053&action=view) version of firefox, that is "mozilla-firefox-1.0_pre-r1" From the output of emerge: <snip> Building mozilla-firefox-1.0_pre-r1 with the following configuration --disable-activex --disable-activex-scripting --disable-calendar n/a on mozilla-firefox --disable-debug -debug --disable-installer --disable-jsd n/a on mozilla-firefox --disable-ldap -ldap --disable-ldap-experimental -ldap --disable-mailnews n/a on mozilla-firefox --disable-pedantic --disable-svg n/a on mozilla-firefox --disable-tests -debug --disable-xinerama -xinerama --disable-xpctools n/a on mozilla-firefox --enable-crypto --enable-default-toolkit=gtk2 +gtk2 --enable-elf-dynstr-gc x86 optimized build --enable-extensions=cookie,inspector,negotiateauth,pref,transformiix,typeaheadfind,universalchardet,webservices,xmlextras,xml-rpc,gnomevfs --enable-freetype2 +truetype --enable-freetypetest +truetype --enable-gnomevfs +gnome --enable-ipv6 +ipv6 --enable-mathml --enable-oji --enable-old-abi-compat-wrappers building with >=gcc-3 --enable-optimize=-O2 mozilla fallback --enable-reorder -debug --enable-strip -debug --enable-strip-libs -debug --enable-xft gtk2 with xft2 (+gtk2 -moznoxft) --enable-xprint +xprint --enable-xterm-updates --with-pthreads --with-system-jpeg --with-system-png --with-system-zlib --with-x --without-system-nspr </snap> @Dan Noe (#41) Does the F3/Ctrl+G also work with this method? And does the find toolbar actually find something?
The find toolbar does not work at all for me (its entirely useless). AFAIK Ctrl-G does not work to fint-next-as-you-type. Really, its just a workaround. Regular find needs to be fixed!
Just my $0.02 to Comment 41: Dan, thanks for the tip, but this does not solve the main problem - I need to change focus on the page when searching thru the page, i.e. to move to the first and subsequent occurences of the expression in the page. CTRL+G is not working at all. :( Also I think that the whole idea of replacing the standard CTRL+F search dialog with the find bar at the bottom of the browser window is fundamentally flawed, since (even had it worked) it would not allow moving between subsequent occurences of the expression without using mouse to click on previous/next. But this is most probably outside the scope of Gentoo Bugzilla. :(
There are keyboard shortcuts for Find. Open Help > Help Contents > Keyboard Shortcurs.
From what I've read firefox 1.0pre changed keybindings a bit and now use the gnome defaults or what not instead of "emacs-like" bindings. So you have to change your gnome bindings if you want it back the previous way, or you can just use the new bindings. For comment 42: --enable-extensions=cookie,inspector,negotiateauth,pref,transformiix,typeaheadfind,universalchardet,webservices,xmlextras,xml-rpc,gnomevfs that line is clearly showing "typeaheadfind", that should not be there. The pathc is supposed to remove it. Your other problems with the extensions and such, as far as I can tell, aren't part of this bug. Being as typeaheadfind is now an outdated extension option on firefox 1.0pre (as it breaks everything) it should work fine without it. However from what you've shown above it's still there, so I have no idea what's going on...
This patch works great for me. The way that it finds the profiles feels a bit dirty to me, but it did the job without causing any issues. Gentoo Base System version 1.4.16 Portage 2.0.50-r11 (gcc34-x86-2004.2, gcc-3.4.2, glibc-2.3.4.20040808-r0, 2.6.8) ================================================================= System uname: 2.6.8 i686 AMD Athlon(tm) XP 2600+ ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=athlon-xp -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -pipe" DISTDIR="/mnt/hda1/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="ftp://gentoo.ccccom.com http://gentoo.seren.com/gentoo ftp://206.75.217.180/ ftp://gentoo.netnitco.net/pub/mirrors/gentoo/source/ ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/mnt/hda1/portage/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X aalib acpi alsa avi berkdb bitmap-fonts bonobo cdr crypt cups dedicated doc dvd encode esd evo foomatic foomaticdb gdbm gif gnome gnomedb gpm gstreamer gtk gtk2 gtkhtml guile imlib java jfs jikes jpeg junit ldap libg++ libwww mad mikmod mmx mng motif mozilla mpeg mysql nas ncurses offensive ogg oggvorbis openal opengl oss pam pdflib perl png python qt quicktime readline reiserfs ruby samba sdl slang spell sse ssl svga tcltk tcpd tetex tiff truetype usb x86 xml xml2 xmms xosd xprint xrandr xv zlib"
ok, fixed in mozilla.eclass I bumped firefox to 1.0_pre-r1 to carry out the change. Also mozilla-launcher-1.20 has a fix to kill existing compreg.dat when firefox is updated. We can't do this in an ebuild because we're not going to go routing through home directories at merge-time... 1.0pre-r1 depends on mozilla-launcher-1.20 Thanks for all the valuable input in this bug.
I can confirm that #48 solves all of the above problems, i.e. - Find-as-you-type and F3/ Ctrl-G and - the extensions window. Thanks a lot!
