Closed
Bug 191871
Opened 22 years ago
Closed 20 years ago
Find as you type stops working after a while
Categories
(SeaMonkey :: Find In Page, defect, P1)
SeaMonkey
Find In Page
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: Kalle.Valo, Assigned: aaronlev)
Details
Attachments
(1 file, 1 obsolete file)
2.67 KB,
patch
|
jst
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
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•21 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 (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•21 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 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
Comment 3•21 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.
Assignee | ||
Comment 5•21 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•21 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•21 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•21 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•20 years ago
|
||
Count me in as well. Notice it happens after I do view source. Windows 2000, nightly build 2004030309.
Assignee | ||
Comment 10•20 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•20 years ago
|
||
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.
Assignee | ||
Updated•20 years ago
|
OS: Linux → All
Hardware: PC → All
Assignee | ||
Comment 12•20 years ago
|
||
Cool, I'm able to reproduce the testcase in comment #11.
Priority: -- → P1
Assignee | ||
Comment 13•20 years ago
|
||
Anyone know if this happens with fastfind?
Comment 14•20 years ago
|
||
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.
Assignee | ||
Comment 15•20 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 !!
Assignee | ||
Comment 16•20 years ago
|
||
Another major hint: 1. Launch any page 2. Ctrl+B for bookmarks 3. Alt+F C FAYT is broken.
Assignee | ||
Comment 17•20 years ago
|
||
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.
Assignee | ||
Comment 18•20 years ago
|
||
Attachment #159746 -
Attachment is obsolete: true
Assignee | ||
Comment 19•20 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 20•20 years ago
|
||
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
Attachment #159748 -
Flags: superreview?(jst)
Attachment #159748 -
Flags: superreview+
Attachment #159748 -
Flags: review?(jst)
Attachment #159748 -
Flags: review+
Assignee | ||
Comment 21•20 years ago
|
||
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
Closed: 20 years ago
Resolution: --- → FIXED
Updated•16 years ago
|
Product: Core → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•