Bug 64191 – Find in this page operation fails to do anything in Mozilla-1.7.2-r1

• Status: RESOLVED TEST-REQUEST
• Product: Gentoo Linux

[Description David Fellows 2004-09-15 16:53:19 UTC]

Find in this page generates an error window the first time you use it. Subsequent attmpts to use it are no-ops.

Reproducible: Always
Steps to Reproduce:
1. emerge  =mozilla-1.7.2-r1
2. launch mozilla (in GNOME)
3. Go to any URL
4. Select Edit->Find in this page  (or press <ctrl> F)


Actual Results:  
A window labeled Gecko opens containing the following ascii text:
<label value="&findField.label;" accesskey="&findField.accesskey;""
control="dialog.findKey"/>
------------------------^
This is transcribed by hand the window does not support selection.  the text in
<> is all one line. the ^ is under the period between findField and label.

Whether or not  you close the error window, all subsequent Find in this page's
are no-ops.  Mozilla does not hang.

Expected Results:  
Expected the Find in this page dialog window to open to permit entry of a search
term, etc.

Portage 2.0.50-r10 (default-amd64-2004.2, gcc-3.3.4, glibc-2.3.4.20040619-r1,
2.6.7-gentoo-r11)
=================================================================
System uname: 2.6.7-gentoo-r11 x86_64 5
Gentoo Base System version 1.4.16
Autoconf: sys-devel/autoconf-2.59-r4
Automake: sys-devel/automake-1.8.5-r1
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CFLAGS="-O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
COMPILER=""
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref
/usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache"
GENTOO_MIRRORS="ftp://gentoo.risq.qc.ca/ ftp://cs.ubishops.ca/pub/gentoo
ftp://sunsite.ualberta.ca/pub/unix/Linux/gentoo/
ftp://ibiblio.org/pub/Linux/distributions/gentoo/ http://gentoo.mirrored.ca/"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X alsa amd64 apm arts avi berkdb bonobo cdr crypt encode esd foomaticdb
gdbm gif gnome gpm gtk gtk2 gtkhtml guile imlib jpeg kde ldap libg++ libwww
mikmod motif mozilla mpeg mysql ncurses nls nogcj oggvorbis opengl oss pam
pdflib perl png python qt quicktime readline sdl slang spell ssl tcltk tcpd
truetype xml2 xmms xv zlib"

[Comment 1 David Fellows 2004-09-15 17:02:35 UTC]

I previously had mozilla-1.6-r1  emerged and I don't recall that this bug was present in it. I am pretty sure I successfully searched pages.

[Comment 2 David Fellows 2004-09-29 17:50:48 UTC]

I emerged 1.7.3.  I was unable to reproduce the bug in it.

[Comment 3 Ben Jackson 2005-02-25 22:58:09 UTC]

just confirming that i have the same problem on amd64 1.7.2-r1

[Comment 4 Ben Jackson 2005-02-25 23:08:09 UTC]

CORRECTION: i have a similar problem on amd64 1.7.5 - sorry.

the error is now:

XML Parsing Error: not well-formed
Location: chrome://global/content/finddialog.xul
Line Number 1, Column 3:

[strange unrecognisable character]

the effects are identical

[Comment 5 Ben Jackson 2005-02-26 00:07:13 UTC]

this is fixed by reemerging mozilla

[Comment 6 Jakub Moc (RETIRED) 2005-12-22 18:01:46 UTC]

Stale bug, reopen if this is still an issue with up-to-date ebuild versions.