User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 If you're browsing a text-only page with no links present, type ahead find should be disabled. Also, on large text files hitting a key by mistake stalls the whole browser (and all child windows) for a looong time. Reproducible: Always Steps to Reproduce: 1. Go to http://db.gamefaqs.com/console/ps2/file/kingdom_hearts_h.txt for example. 2. Press the "a" key. 3. Wait ten seconds for the timeout.
The testcase url is not very useful as it deosn't allow external linking. But I can confirm that type ahead find does stall on this page for a long time (several seconds) as no links are present, making Mozilla unresponsive. The correct solution is probably: Disable searching for links on mime type that do not support links (having text search in text/plain is still useful) Make Mozilla responsive whilst typeahead find is operating. Reporter please move this bug to the Keyboard: Find as you type component under browser.
Thanks James, recategorizing this.
Component: Browser-General → Keyboard: Find as you Type
Assignee: asa → aaronl
QA Contact: asa → sairuh
I could reproduce the freeze: CPU: PIII 833 MHz, 128 MB RAM OS: Microsoft Windows 2000 Professional URL: ftp://sailor.gutenberg.org/pub/gutenberg/etext92/timem11.txt If I still see the misbehavior after I have updated my machine to the latest nightly build of Mozilla, I will confirm this bug.
Confirming on Win32, trunk build 2003011508 Enjoy "The Time Machine" by Wells ;-)
Status: UNCONFIRMED → NEW
Ever confirmed: true
how odd, i cannot repro this at all using 2003.01.15 trunk bits on win2k, linux rh8.0 or mac 10.2.3.
sairuh: It's not a permanent hang (requiring C-M-del to break) but just a temporary state where Mozilla doesn't recognize any input. Try opening timem11, pressing F, and then immediately clicking the Back button. You should get a several second delay before Back registers. If you don't, you're probably using a 2000 MHz computer.
okay, now i understand this bug. damian, thanks for the explanation --now i see what you're describing. the delay is definitely annoying when viewing long text pages, like the test url! i'm curious, however: shouldn't find as you type work on plaintext pages if you're in text mode? (ie, hit / then type a search string.) unfortunately, cannot test that aspect due to bug 189228.
Text search should still work according to the users prefs. Either / first, or automatically if that's your start pref.
i'm guessing the default (links only searching) is on in this particular issue. a text file (files of type text/plain) would not contain links. i don't think the link-searching aspect of Find as you Type should "turn on" in such a case.
Summary: Type ahead find should not listen for keystrokes on text/plain pages → Don't spend any time looking for links in text only page
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
hrm, this seems only partially fixed --the bug still crops up the first time i load a text page. tested on win2k, linux rh8.0 and mac10.2.3, 2003.02.11 comm trunk (with default find as you type prefs). reopening. here's a test which would exhibit this: 1. open a new browser window (i used Accel+N). 2. in the URLbar, paste in the location of a big text file --what i did was copy ftp://sailor.gutenberg.org/pub/gutenberg/etext92/timem11.txt, went to the urlbar via Accel+L, then pasted it with Accel+V. 3. load the urlbar, and wait for it to finish loading --make sure the status bar says 'Done.' 4. hit the 'a' key (no quotes, of course). 5. wait a few seconds. results: the find as you type notification (not found) sound beeps, and the status bar says 'Link not found: "a" repeated'
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Created attachment 114150 [details] [diff] [review] Make sure to check GetAutoStart() when document changes
Comment on attachment 114150 [details] [diff] [review] Make sure to check GetAutoStart() when document changes sr=Henry
Attachment #114150 - Flags: superreview?(Henry.Jia) → superreview+
Attachment #114150 - Flags: approval1.3? → approval1.3+
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago → 16 years ago
Resolution: --- → FIXED
looks good with 2003.02.18 comm trunk bits. thanks for fixing that last case!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.