78194 - Find in This Page no longer works

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Dimitrios]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.8.1+) Gecko/20010429
BuildID:    2001042908

Not much to say, summary talks for itself.

Reproducible: Always
Steps to Reproduce:
1. Try to open the Search->Find dialog in browser

Comment 1

[Stephen Moehle]

I see the same problem on Linux with the 4/28 trunk build.

Comment 2

[Matthias Versen [:Matti]]

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

Comment 3

[Matthias Versen [:Matti]]

confirming based on the dupe and the comment from [e-mail]
(OS WIN98->All)

Comment 4

[Jacek Piskozub]

Bug found in 2001042822 & 2001042910 Win32 installer builds while in 2001042714
(I use the FTP catalog names here) it still worked - in case that helps pinpoint
the offending checking. 

Comment 5

[R.K.Aa.]

dup of bug 78011 ?

Comment 6

[Stephen Moehle]

Not in my case since I saw bug 78011 and tried deleting component.reg.  It did
not help.

Comment 7

[R.K.Aa.]

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

Comment 8

[Aleksander Adamowski]

Confirming: Linux Build 2001042921
Removing component.reg doesn't help

Comment 9

[kinmoz]

Is there a specific page or URL that people are using to see this problem? It
seems to be working fine in my Win32 build which is in sync with today's trunk.

This should go to sfraser.

Comment 10

[Simon Fraser [no longer active]]

Need more info. Is there any console output? Does deleting the components.reg and 
rerunning really not help?

Comment 11

[PTRourke]

Reporter of 78196 saw this on a fresh install of Windows 98SE, no previous 
versions of Moz or NS6 had been installed since repartition. Simply no response 
to Ctrl-f or menu item.

Reporter of 78196 sees on all pages, including http://www.mozilla.org/ . Build 
is 2001042908.  Will check an April 30 build later. 

Comment 12

[PTRourke]

Closing Moz, deleting Component.reg, and reopening Moz does not resolve.

Comment 13

[Jacek Piskozub]

Confrming the bug existence with Win32 installer build 2001043004. You need not
open any page (that changes nothing). The Ctrl-F shortcut and Search | Find menu
entry have no result whatsoever (no Find window, no error, hang, crash, just
nothing).

Comment 14

[PTRourke]

Sorry, when I referred reporter of 78196, I meant 78200.  Is this perhaps 
related to the fix for bug 68307 ?

Comment 15

[Simon Fraser [no longer active]]

I think I'm missing a new .xpt file.

Comment 16

[Simon Fraser [no longer active]]

Attachment: Fixes to packaging files

Comment 17

[Simon Fraser [no longer active]]

r/sr please?

Comment 18

[Martin Heusel]

this is the console output on build 2001042921 on linux

JavaScript error: 
 line 0: uncaught exception: [Exception... "Could not convert JavaScript
argument (NULL value can not be used for a C++ reference type) arg 0
[nsIInterfaceRequestor.getInterface]"  nsresult: "0x8057000b
(NS_ERROR_XPC_BAD_CONVERT_JS_NULL_REF)"  location: "JS frame ::
chrome://global/content/xulBindings.xml#browser.webBrowserFind (getter) :: onget
:: line 0"  data: no]

hth

Comment 19

[R.K.Aa.]

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

Comment 20

[Travis Ogdon]

I'm only seeing this as broken in the mozilla-i686-pc-linux-gnu-sea.tar.gz, but
find is working in the mozilla-i686-pc-linux-gnu.tar.gz for the 01-May-2001
08:38 builds.

Comment 21

[Simon Fraser [no longer active]]

Leaf let me check in the package files already.

Comment 22

[Alec Flett]

r/sr=alecf

Comment 23

[Alec Flett]

oops, too late :)

Comment 24

[sairuh (rarely reading bugmail)]

no 5/2 comm bits for win32 yet, but this is working now using 2001.05.02.08
linux [stub installer] and 2001.05.02.09 mac [blob installer] bits. so, vrfy.

Comment 25

[PTRourke]

Working well in 2001050204, Windows installer build.