As you said, it's impossible to tell whether or not the first keypress is for FAYT. There just isn't any way to get around that. This bug is therefore most likely WONTFIX.
This bug is not unique to Firefox; it also occurs with Mozilla. I am using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041220 and the CiteSeer site is a continual source of annoyance for me. Would someone with the appropriate access please change the Product field? Also, I don't believe that this bug should be marked WONTFIX. At the very least, there should be some configuration option to allow type-ahead find to override document.onkeypress.
*** Bug 295712 has been marked as a duplicate of this bug. ***
*** Bug 309903 has been marked as a duplicate of this bug. ***
This bug seems to be fixed in 1.5 Please verify. thx.
It seems that Yahoo has recently changed some code that triggers this bug (or one very similar to it; this was the closest thing I could find in a fairly thorough search). See, for instance: http://finance.yahoo.com/q/bc?s=AAPL&t=3m&l=on&z=m&q=l&c= Any keypress while focus is in the content area itself causes focus to be transferred to the "Get Quotes" text field at the top left of the page. This JS effectively makes type-ahead find/FAYT useless on any Yahoo Finance pages. Changing product to Core, since I see this on Camino too.
Duplicate of/related to SeaMonkey bug 215024?
Mass un-assigning bugs assigned to Aaron.
(In reply to Gavin Sharp (use firstname.lastname@example.org for email) from comment #1) > As you said, it's impossible to tell whether or not the first keypress is for > FAYT. There just isn't any way to get around that. This bug is therefore most > likely WONTFIX. I think that only a part of the bug might be WONTFIX if not implemented by an option (perhaps the feature that makes an arbitrary key start FAYT). For instance, I've configured the key '/' to start FAYT, but on some pages (e.g. Twitter with its new interface), it is affected by the same problem (see bug 215024). The workaround Ctrl-F might not work either on all pages. But now I think that this can be a more general problem. For instance, accesskeys override shortcuts, as said in bug 555400. IMHO, if a key (shortcut) has been defined/configured at the browser level, it should have the precedence over its use at the document level (there could also be an option to give the choice).
Tina: That is a different issue. This bug is about the opposite problem: keypresses being sent to the site instead of type-ahead find.
(In reply to Robin Green from comment #0) > Admittedly, there is a difficulty in terms of what you do with the first > keypress, when you don't know if it's meant to be a type ahead find or not. I > suggest, assume it is unless it can't be. > > Workaround is to press CTRL+F before a find. This workaround suffers from the same problem. Firefox allows Web pages to hijack Ctrl F. Google Books does that, for example. See bug 380637.