User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.9.1b3pre) Gecko/20081215 SeaMonkey/2.0a3pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.9.1b3pre) Gecko/20081215 SeaMonkey/2.0a3pre The new implementation of typeaheadfind has caused a timeout problem. The "Find as you type" is still active after a new webpage is loaded. One has to wait for the default timeout or press the escape key to stop "Find as you type". Reproducible: Always Steps to Reproduce: 1. Load a webpage. 2. Type something which matches a link. 3. Press enter which will load the matched link. 4. After loading the link, type something again which matches a link (within the timeout period) Actual Results: You cannot match the link at the newly loaded page since the previous search hasn't timed out yet and the new search string is appended to the previous search string. "Find as you type" is still active after loading another page. Expected Results: After loading another page, the "Find as you type" should be disabled.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20081220 SeaMonkey/2.0a3pre - Build ID: 20081220000453 I see the same on Linux; but in practice, I see the timeout elapse at step 4 unless the link of steps 2-3 was within the same page (loaded at step 1).
OS: Windows 2000 → All
Version: unspecified → Trunk
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b3pre) Gecko/20081230 SeaMonkey/2.0a3pre Something related (not sure if there's a bug on this already): Activate type-ahead find, press ^L (or ^T to open a new tab) to focus the location bar, try to type something in there. All the keystrokes are still going to FAYT.
The timeout counter is still active even a new page or new window is opened. You have to explicitly press ESC key to stop that FAYT.
Is this bug still present with a current SeaMonkey trunk (1.9.1) build? I actually think that Bug 466994 solved this bug here as the patch in that bug stops FAYT as soon as the user leaves the current page.
I can still see this bug with 2009-03-07-00 comm-central build.
Hm, seems to wfm with a current comm-central build, stopFind gets called as soon as I leave a page. The webpage you used for testing, did the link there load in the same tab/window or in a new one?
Let me rephrase... Steps to Reproduce: 1. Load the webpage (http://www.seamonkey-project.org/) 2. Type "new" (to match the "News" link) 3. Press enter, which will load the "SeaMonkey Project News" page 4. Type "down" (to match the "Download & Releases" link) 5. You will see a "Link not found: "newdown"" error message at the status line. The key is, if you wait long enough before typing at step 4 to let the FAYT time out, you can match the "Download & Releases" link successfully. Otherwise, the old FAYT query string will be concatenated by the new FAYT query string, causing the bug. Hope this helps clarifying things a bit.
Ah, on that page I can reproduce. I tried to reproduce the bug on another page (http://www.heise.de) and there I could not reproduce.
This fixes it. See https://developer.mozilla.org/En/Using_Firefox_1.5_caching#New_browser_events for details on the pagehide event.
Yeah, that was my fault, the old typeaheadfind used unload and I didn't think.
Pushed to comm-central, changeset d12dee2e9db1.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.