191871 - Find as you type stops working after a while

Status: RESOLVED FIXED

(SeaMonkey :: Find In Page, defect, P1)

Description

[Kalle Valo]

Find as you type suddenly stops working once in a while. This might happen
almost instantly after the mozilla is started or it might work for 30 minutes. I
can't provide a test case or a way to reproduce it. I don't normally press '/'
before typing. But when this bug occurs pressing '/' just shows status bar shows
"Starting -- find text as you type" but even then nothing happens . I use Find
as type with it's default settings. 

I use CVS trunk compiled with gcc 3.2 on Debian sid. I have disabled debugging
and enabled optimization. This has happened for few weeks now. Does anyone else
see this?

Linux litku.dyndns.org 2.4.19 #1 SMP Wed Jan 22 08:27:30 EET 2003 i686 unknown
unknown GNU/Linux

Comment 1

[Charles McLaughlin]

This happens to me too.  I can't seem to identify why/when this happens -- it
just seems to stop working after a while.  Sometimes visiting the find as you
type website
(http://www.mozilla.org/projects/ui/accessibility/typeaheadfind.html) in a 
seperate browser window fixes it -- but not always.  Sometimes I have to
completely restart Mozilla.

When it is working, it is a wonderfull feature!!!

Thanks,
Charles

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030430 Debian/1.3-5

Comment 2

[David A. Madore]

I observe this bug, too: it happens regularly.  Currently on a trunk build near
1.4beta.  I've just spent hours trying to determine the exact circumstances
which trigger it, but to no avail - it's hopelessly elusive.  But it definitely
exists (I have testimony from some other users, too, though nobody was able to
understand when it happens).  I don't think time (as in "after a while") is the
problem, though; I thought that trying to type-ahead search on a page that
hadn't finished loading would cause the bug, but it seems to be more subtle than
that.

I have one clue, though, which possibly might help determine the cause of the
bug: whenever I observe the bug (viz., I click on the canvas to give it focus,
then type '/' and some word I want to search for), a blinking line cursor
appears where I clicked, as though I were in caret mode (F7), although I did
*not* activate caret mode.  So is it some weird interaction between type-ahead
and caret mode?  (The blinking cursor appears where I click, but only after I
initiate type-ahead, not just when I click on the canvas.)

Comment 3

[Kareem Dana]

I observe this bug also. I just want to confirm that it is happening to more
people. I am using  mozilla 1.3.1 binary.  I am wondering if the bug has
anything to do with text input boxes that appear on pages. Perhaps they try and
take focus and type ahead find does not work?

Also, I have observed that type ahead find will also suddenly start working
again. It has happened a few times where it suddenly stops working and I
continue browsing as normal, and it will suddenly start working fine again later
in the day. 

Comment 4

[sairuh (rarely reading bugmail)]

brian or aaron, have either of you encountered this?

Comment 5

[Aaron Leventhal]

I am encountering this sometimes.

Recently when it happened, I tried to scroll using the arrow keys and
pageup/pagedn, and could not do so. This seems to indicate is a focus bug.

So I tried to tab back to the URL bar and then back to content to see if I could
get focus back. I still couldn't arrow. Very strange.

Comment 6

[Stefan Magdalinski]

I'm seeing this too.

I'm currently using FAYT to access webmail at work, and I don't use a mouse. I 
guess I see it once every 30 minutes or so. it usually comes back after a 
little while, but I can't figure out what triggers, or cures it.

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030813

I'll try and be a bit more observant and report back here.

Comment 7

[Stefan Magdalinski]

Ok. here's a possible lead. This seems to start happening if a link that has
been triggered after discovery with FAYT takes a very long time to load, or
times out.

and I often see javascript: void(0) in the status bar at the same time. Of
course, this might be completely unrelated, but I'm just posting this here just
in case it rings bells for anyone else.

Is there any logging I can switch on to help diagnose the cause?

Comment 8

[Stefan Magdalinski]

Some support for the focus bug theory:

It seems that when FAYT breaks, if I have another mozilla window with the
acrobat plugin displaying a pdf, then that breaks too. But possibly not all
keys: scrolling up and down seems to be ok, but ALT-leftarrow, ALT-rightarrow
don't work.

and then it mysteriously comes back a few minutes later (possibly often after
I've accessed a page with a FORM in it)

not particularly illuminating I know, but I'm going to dump everything I can
think of here in the hope it rings bells. 

Is there someone who knows a lot about focus that we could CC in here?

Can we track where those lost keystrokes are ending up?

Comment 9

[Daniel Convissor]

Count me in as well.  Notice it happens after I do view source.

Windows 2000, nightly build 2004030309.

Comment 10

[Aaron Leventhal]

Still looking for a detailed set of steps or a testcase of some kind.

Can anyone confirm that this is Linux only?

Comment 11

[Daniel Convissor]

Aaron:

As mentioned in the comment above yours, it's not Linux only.  I'm on Windows
2000.  Current Mozilla build is 2004051009.

Creating a test case is hard, since it's strangely intermittent.  It seems to
come up often after doing a View, Page Source.

Here's a test case that works for me at this moment, though I can't guarantee
it'll work 100% of the time, but it might...

1) Go to http://pear.php.net/
2) Type in "ne" ("News" link will become selected)
3) Hit ESC
4) ALT-V, o (to view source)
5) ALT-F, c (to close)
6) Type in "ne" again and find as you type no longer works

Hope that heplps.

Comment 12

[Aaron Leventhal]

Cool, I'm able to reproduce the testcase in comment #11.

Comment 13

[Aaron Leventhal]

Anyone know if this happens with fastfind?

Comment 14

[sairuh (rarely reading bugmail)]

hm, the test case in comment #11 doesn't seem to work for me in firefox
(2004070308-0.9 bits on linux; with FAYT enabled via the prefs UI or not) --so I
cannot say (yet) whether this issue also affects the Find Toolbar (fastfind). if
I see it, I'll add to this report.

Comment 15

[Aaron Leventhal]

Simpler test case with Seamonkey/FAYT:
1. View Source
2. Close window with Alt+F C (must be closed this way)
3. Try FAYT, it won't work

There's something about Alt+F C !!

Comment 16

[Aaron Leventhal]

Another major hint:
1. Launch any page
2. Ctrl+B for bookmarks
3. Alt+F C

FAYT is broken.

Comment 17

[Aaron Leventhal]

Attachment: Clear menu state flags when a window closes

Fixes the problem, but ... something's wrong

Ideally I would only clear these flags when the currently focused window is a
child of the window reported by domwindowclosed.

However, this is not happening when the window is closed from Alt+F C. Any
other way of closing the window gives me the expected result.

Comment 18

[Aaron Leventhal]

Attachment: If focused window is in window hierarchy of window that's closing, clear menu flags

Comment 19

[Aaron Leventhal]

Comment on attachment 159748 [details] [diff] [review]
If focused window is in window hierarchy of window that's closing, clear menu flags

Seeking r+sr = jst

Comment 20

[Johnny Stenback (:jst)]

Comment on attachment 159748 [details] [diff] [review]
If focused window is in window hierarchy of window that's closing, clear menu flags

r+sr=jst

Comment 21

[Aaron Leventhal]

Checking in src/nsTypeAheadFind.cpp;
/cvsroot/mozilla/extensions/typeaheadfind/src/nsTypeAheadFind.cpp,v  <-- 
nsTypeAheadFind.cpp
new revision: 1.99; previous revision: 1.98
done