Find as you type stops working after a while



16 years ago
10 years ago


(Reporter: Kalle.Valo, Assigned: aaronlev)


Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)



16 years ago
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 2.4.19 #1 SMP Wed Jan 22 08:27:30 EET 2003 i686 unknown
unknown GNU/Linux

Comment 1

16 years ago
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
( 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!!!


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

Comment 2

16 years ago
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

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.)
Ever confirmed: true

Comment 3

16 years ago
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. 
brian or aaron, have either of you encountered this?
Keywords: qawanted

Comment 5

16 years ago
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

15 years ago
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

15 years ago
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

15 years ago
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

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

Windows 2000, nightly build 2004030309.

Comment 10

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

Can anyone confirm that this is Linux only?

Comment 11

15 years ago

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
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.


15 years ago
OS: Linux → All
Hardware: PC → All

Comment 12

15 years ago
Cool, I'm able to reproduce the testcase in comment #11.
Priority: -- → P1

Comment 13

14 years ago
Anyone know if this happens with fastfind?
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

14 years ago
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

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

FAYT is broken.

Comment 17

14 years ago
Created attachment 159746 [details] [diff] [review]
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

14 years ago
Created attachment 159748 [details] [diff] [review]
If focused window is in window hierarchy of window that's closing, clear menu flags
Attachment #159746 - Attachment is obsolete: true

Comment 19

14 years ago
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
Attachment #159748 - Flags: superreview?(jst)
Attachment #159748 - Flags: review?(jst)
Comment on attachment 159748 [details] [diff] [review]
If focused window is in window hierarchy of window that's closing, clear menu flags

Attachment #159748 - Flags: superreview?(jst)
Attachment #159748 - Flags: superreview+
Attachment #159748 - Flags: review?(jst)
Attachment #159748 - Flags: review+

Comment 21

14 years ago
Checking in src/nsTypeAheadFind.cpp;
/cvsroot/mozilla/extensions/typeaheadfind/src/nsTypeAheadFind.cpp,v  <-- 
new revision: 1.99; previous revision: 1.98
Last Resolved: 14 years ago
Resolution: --- → FIXED
Keywords: qawanted
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.