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
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
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.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
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?
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.
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.
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?
Count me in as well. Notice it happens after I do view source. Windows 2000, nightly build 2004030309.
Still looking for a detailed set of steps or a testcase of some kind. Can anyone confirm that this is Linux only?
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.
Cool, I'm able to reproduce the testcase in comment #11.
Priority: -- → P1
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.
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 !!
Another major hint: 1. Launch any page 2. Ctrl+B for bookmarks 3. Alt+F C FAYT is broken.
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.
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 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 on attachment 159748 [details] [diff] [review] If focused window is in window hierarchy of window that's closing, clear menu flags r+sr=jst
Checking in src/nsTypeAheadFind.cpp; /cvsroot/mozilla/extensions/typeaheadfind/src/nsTypeAheadFind.cpp,v <-- nsTypeAheadFind.cpp new revision: 1.99; previous revision: 1.98 done
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.