Closed Bug 102975 Opened 23 years ago Closed 23 years ago

Find dialog is horked sometimes (Find in Page doesn't work)

Categories

(SeaMonkey :: UI Design, defect, P3)

Product:
SeaMonkey
Component:
UI Design
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME
Milestone:
mozilla0.9.9

People

(Reporter: tingley, Assigned: bugs)

References

(
URL
)

Details

(Keywords: qawanted, regression)

Attachments

(2 files)

The broken Find dialog I have
44.03 KB, image/jpeg
Details
Another image of the Find dialog
25.17 KB, image/jpeg
Details 
2001100308 trunk linux.

The find dialog appears to be totally broken -- it opens, but will not focus
itself (a fix for which supposedly went in a couple days ago).  Searches don't
do anything.  

The js console prints a rather disturbing error when I open the dialog, and
again every time I type a letter into the textfield:
  Error: dialog.find has no properties
  file:  chrome://global/content/finddialog.js   Line 140

When I push 'OK', I get:
  Error: onAccept is not defined
  file:  chrome://global/content/bindings/dialog.xml#dialog.fireButtonEvent() 
Line 10

People on #mozillazine using windows don't seem to see this bustage, though
there was a report of seeing slightly less severe errors in the console.

I don't have a recent tree handy.  I'll go poke around in lxr...
Actually, the error on load is at finddialog.js line 84 -- the line 140 is only
when typing.

Could this have something to do with hewitt's recent checkin for bug 70750?

this is bad! i also see this

here's what i see:

1. launch browser, go to http://mozilla.org.
2. bring up Find in Page dialog [either accel+F or Search > Find in Page].
3. in the dialog, enter "mozilla" [no quotes] into the field and select "wrap
around". interestingly, i didn't need to click to bring the field into focus, so
that issue seems resolved
4. hit Enter key.
result [sometimes]: nothing happens, the string, which obviously exists on this
page, isn't found. which is what tingley sees, i believe, yes?
5. or, click the Find button.
result: the string is found, but the dialog goes away, rather than persisting.
now *that* is definitely a regression, imho!
Keywords: mozilla0.9.5, regression
OS: Linux → All
Hardware: PC → All
whups, i managed a fragment there: meant to say that i see this using today's
trunk builds on linux, winnt and mac os 9.x.
works for me with 10/03 windows build
To clarify, I'm also seeing two different behaviors now that I try this again
with my cvs build.  The cvs build exhibits the second problem that sairuh
mentions -- the find dialog disappears when I hit <return>, although the search
does go off.

Earlier today, in a nightly (opt) build, I was seeing sairuh's first problem --
I'd click OK or hit return and *nothing* would happen.  No search would take
place, and there would be no indication of failure other than the js console
errors.  These js errors, incidentally, don't occur in the debug build.




i filed bug 103061 to cover the case of the Find in Page dialog not persisting.

modifying summary here to reflect what tingley and i see, if that's okay...
URL: http://mozilla.org
Summary: Find dialog is totally horked → Find doesn't successfully find existing string
->joe?

interesting observation: using a linux mozilla debug from last night [20:11
pull], i see this when using the classic theme, but not with modern.

JavaScript error: 
chrome://global/content/finddialog.js line 48: moveToAlertPosition is not defined

JavaScript error: 
chrome://global/content/finddialog.js line 111: gFindInst has no properties

then i restarted my profile w/the classic theme...and it started working. so,
perhaps it's not the theme, but maybe the first session of a profile [after a
new build or installation]? just a guess...
Assignee: blakeross → hewitt
the focus issue was supposedly fixed in bug 96843...however i sometimes notice
that [on the trunk, not with 0.9.4 branch so far] Find in Page occaisionally
doesn't focus the textfield --a recent bug was filed on this, bug 103484, which
i will reopen...
*** Bug 103828 has been marked as a duplicate of this bug. ***
I see this on both Classic and Modern on 2001100903 trunk Win2K. JavaScript
console also shows the forementioned errors in finddialog.js line 48 and 111.
I'll attach an image of the dialog as requested by Alex Bischoff.
Sorry, can't create attachment, because suddenly the dialog started working
(after I just opened a new browser and loaded a bug page to it). Now there are
the correct buttons "Find" and "Cancel" also. How would this be possible?  
Just a clarification: I meant that all I did to get a working dialog was open a
new browser window, no restarting of Mozilla etc. 
->hyatt, while joe is away...
Assignee: hewitt → hyatt
Okay, I'll attach images from my home computer where it still doesn't work.
Attached image The broken Find dialog I have — 

    
    

    
  
In the attached images you can see that the button that should be Find is Ok. 
Also, when the dialog is brought up initially, the Ok button is enabled. When I 
type in something and clear it, the button will be disabled. When Ok button is 
disabled, the Cancel button doesn't do anything though...

Hey, I just found out how to fix it :) Open the JavaScript Console. After that 
it works fine! Well, at least for me, but this is probably what happened to my 
work computer also. In the console there were also the previously mentioned 
errors, but now when it works it doesn't cause them anymore.

    
    

    
  
I wonder if this is the bug with two different builds sharing fastload files from 
your profile dir.


    
    

    
  
I only have one build at a time if that matters. See bug 103828 for the tests
I've done before (namely unstalling, deleting files, reinstalling, creating new
profile).
http://bugzilla.mozilla.org/show_bug.cgi?id=103828

    
    

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

    
    

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

    
    

    
  
"I wonder if this is the bug with two different builds sharing fastload files from 
your profile dir."

for me it is bug 105357 (dup of this one),
I've shared the same profile with different builds (0.9.5, trunk, 0.9.4)
I've just deleted XUL.mfl and restarted and the bug is gone !!

so you might want to try that also...




    
    

    
  
Two different builds will not share the FastLoad file if those builds use
different chrome directories (as I believe they must, unless all the chrome
scripts are compatible with both builds).  Do the builds use different chrome
directories?  Jar files, or unjarred?  Have you tried a trunk build?

/be

    
    

    
  
I meant bug 105307 ...

"Do the builds use different chrome directories?"
yes
"Jar files, or unjarred?"
jar files
"Have you tried a trunk build?"
yes

but wait...
since then I've installed 0.9.5 on another machine for the first time
(I've had 0.9.3 on that machine). I created a new profile. Guess what ?
At one time I used "Find in this page..." and it didn't work ! This 
build doesn't use fastload file (there's no XUL.mfl). I had errors in the
javascript console (gFindInst has no properties l 111 IIRC).
I restarted moz and I tried again. Now it works !
I've started moz several times and for the moment it's still working (and no
errors in the console). I tried with and without the new tab control with no success

Maybe someone should look closer at the errors in the js console (according to
reporters there are several of them)







    
    

    
  
i hit ctrl + f and the find dialogue comes up. i type in a string that is
obviously on the page and hit "ok" and nothing happens.

    
    

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

    
  
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0.1

    
    

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

    
    

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

    
    

    
  
Hyatt, This bug effectively breaks the Find in page feature for any normal user.
We cannot release a 1.0 product with this feature broken.
There is a workaround in that you can use the "Find Again" option to find the
text you were originally searching for, but the fact that NOTHING happens when
you click find is extremely nervewracking. 

If worse comes to worse, and this cannot be fixed by 1.0 (Like the target
Milestone currently says), This feature should be removed from the menu. I would
hope however that it doesn't come to that
Keywords: mozilla0.9.7, 
          
            mozilla1.0

    
    

    
  
This bug is getting no attention because we haven't got a good reproducible case. 
The find dialog is working for 99% of people; we need some steps to get into this 
weird state before we can debug it.

Summary: Find doesn't successfully find existing string → Find dialog is horked sometimes.

    
    

    
  
You are right... I didn't mean to sound nasty. :-)

I didn't realize until now that this isn't completly broken all of the time.
Apparently it is just broken when *I* want to use the dialog. :-) 

Adding qawanted, and I'll try to figure out how I always seem to get this
worthless dialog.
Keywords: qawanted

    
    

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

    
    

    
  
I'm seeing this bug as well with Mozilla 0.9.5 (build 2001101117) on Windows
2000 with Multizilla 1.1.03.  Before anyone says anything, I've tried it without
MultiZilla, with the same effect.  This is a brand new machine, with no previous
builds or profiles on it.  
I don't have a XUL.mfl file and when I switched from the Modern theme to
Classic, nothing happened.

However, when I switched from Classic back to Modern, the "OK" button in the
dialog box was replaced with "Find", and it worked again.

When it wasn't working, I get the following error when I first bring up the Find
dialog box:
moveToAlertPosition is not defined (in chrome://global/content/finddialog.js)

and then when I type something into the find dialog (the text box doesn't have
focus by default, by the way) and press return (or click the mouse on the OK
button) I get the error:
gFindInst has no properties (in the same file).

I've been trying to reproduce the bug without success, but I hope that this
extra information has helped somewhat.

    
    

    
  
It started working for me after opening the Java Console.  All I had to do was
open the console once, then close it again.  I was using the classic theme at
the time.  Later, during that same session, I changed to the Modern theme, then
closed Mozilla.  On opening, I was given an error message that I wish I would
have written down.  I clicked Ok, and nothing happened.  So, I tried to open
Mozilla again, and it worked great.  I haven't had the find problem since.

So, you may be able to reproduce this problem by installing it on a Win2k
machine with SP2.  Do not open the Java Console.  I don't know if it will mess
up with the Modern Theme.  I also had installed Netscape 4.78 prior to Mozilla.

Hope this helps!

    
    

    
  
I just installed the latest nightly (2001110603) on a Windows 98 SE machine.  No
other version of Mozilla or Netscape has ever been installed on this PC.  The
first time I ran Mozilla, I had the same issue regarding the Find Dialog.  The
button said "Ok" instead of Find.  Clicking Ok didn't do anything.  The "Find
Next" workaround did work though.  I simply closed the program, then re-opened
it.  The next time, it worked fine.  So, it could have to do with changes made
after the first time Mozilla is closed.  Hope this helps.

    
    

    
  
I am using 0.9.5 [Build ID: 2001101117].
The button always said "Ok" instead of Find,
opening Java Console or changing theme doesn't
help. JavaScript Console say:

Warning: reference to undefined property this._mStrBundle
Source File: chrome://global/content/bindings/dialog.xml#dialog.mStrBundle (getter)
Line: 1
---
Error: moveToAlertPosition is not defined
Source File: chrome://global/content/finddialog.js
Line: 48



    
    

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

    
    

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

    
    

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

    
    

    
  
As Simon said in comment #30, we need an always reproducible testcase. From bug
106655 and some comments in this page (e.g. comments #7 and #35), a 100%
reproducible test case could be derived:
1. Create a new profile and start browser with it. Do not touch any preference. 
2. Wait until http://www.mozilla.org/start (which is always loaded on the first
time a new profile is used) is loaded.
3. Use Find in This Page dialog. Note that it has "Ok" button, instead of
"Find". Search the loaded page for something common. It fails.
4. Subsequent runs of the new profile always display "Find" button and they
don't fail. 

I don't claim this testcase covers all other instances of bug 102975 but it
might share a common cause with them. Investigate this one and you might fix all
the others as well.

    
    

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

    
    

    
  
chatted w/some ppl on irc y'day: as a possible workaround, does removing your
component.reg make Find work?

    
    

    
  
Component.reg doesn't seem to make any difference. I did some digging and 
testing and found out a way to reliably fix/break it (at least in the tests I 
did). When a new profile is created and the dialog doesn't work, move it a 
little, close and open again. Now it works. Somehow this seems to be the key, 
because it can be broken again by closing Mozilla and removing lines concerning 
finddialog and it's position from localstore.rdf. So, I think that my previous 
report about opening JavaScript console somehow affecting this was probably 
just because I happened to move the dialog.

    
    

    
  
> move it a little, close and open again. Now it works. 
Absolutely correct. That explains why it's so difficult to reproduce after using
Mozilla a few times.

    
    

    
  
Please correlate your observations with any JS errors that you see in the 
JavaScript console (Tools->JS Console).


    
    

    
  
Simon, I thought you had enough of these identical js logs (see comment #7, for
example). Anyway, here is it (when using the steps I described above):
Error: moveToAlertPosition is not defined Source File:
chrome://global/content/finddialog.js Line: 48
Error: gFindInst has no properties Source File:
chrome://global/content/finddialog.js Line: 111

Second error is repeated every time I click "Ok" on the same Find in Page dialog
box.

    
    

    
  
Confirm. Same errors, as previously reported. 2001112104.

    
    

    
  
since we now have a method of reproducing this, [i'm not a programmer]...
programmers :: how hard would it be to fix this bug?

since target: mozilla1.0.1 doesn't quite seem like a ideal date.
why? because shipping mozilla1.0 with this [simple*] bug would look BAD and
because it's a major component.
(please DO correct me if i'm wrong ;)  )

*simple in terms of functionality of find tool

btw: build 20011125 ... find is _completely_ broken.

    
    

    
  
->ben p3/0.9.9
Assignee: hyatt → ben
Status: ASSIGNED → NEW
Priority: -- → P3
Target Milestone: mozilla1.0.1 → mozilla0.9.9

    
    

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

    
    

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

    
    

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

    
    

    
  
Changing summary from "Find dialog is horked sometimes" to "Find dialog is
horked sometimes (Find in Page doesn't work)" in order to reduce dupes a bit.
Summary: Find dialog is horked sometimes. → Find dialog is horked sometimes (Find in Page doesn't work)

    
    

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

    
    

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

    
    

    
  
works pretty good in build 12-17-03 in w2k.  It was horked for sometime for sure
about a week ago.. now it seems to be working ok.

    
    

    
  
Works for me on W32 Build 20011221508.

    
    

    
  
Worksforme, suing #2001121703 on Win98, didn't work before.

    
    

    
  
has worked for me on WinME for several weeks now

    
    

    
  
I was going to resolve and mark wfm.. per comments., 

Chase, are you still seeing this problem?



    
    

    
  
I haven't seen this in a while either.



    
    

    
  
I'm going to resolve this as works for me now.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME

    
    

    
  
mass verification of WorksForMe bugs: to find all bugspam pertaining to this,
set your search string to "IfItWorksForSlappyTheSquirrelThenItWFM".

if you think this particular bug is *still* an open issue, please make sure of
the following before reopening:

a. that it's still a problem with ***recent trunk builds*** on the all
appropriate platform[s]

b. provide clear steps to reproduce (unless a good test case is already in the
bug report), making sure it pertains to the original problem (avoid morphing as
much as possible :)
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite

    
  
Component: XP Apps: GUI Features → UI Design

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: