Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 215024 - Conflict between FAYT (Find As You Type) and javascript (key events)
: Conflict between FAYT (Find As You Type) and javascript (key events)
Status: RESOLVED DUPLICATE of bug 276295
: helpwanted
Product: SeaMonkey
Classification: Client Software
Component: Find In Page (show other bugs)
: Trunk
: All All
: -- normal with 5 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
Depends on: 276295
  Show dependency treegraph
Reported: 2003-08-04 08:18 PDT by Vincent Lefevre
Modified: 2014-08-13 03:27 PDT (History)
12 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---


Description Vincent Lefevre 2003-08-04 08:18:40 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.5b) Gecko/20030803
Build Identifier: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.5b) Gecko/20030803

Characters typed during a type ahead find are also seen as key events by
javascript; this may lead to unwanted behavior.

Reproducible: Always

Steps to Reproduce:
1. Open the above URL.
2. Type "/r" (to search for a word containing a "r").
Actual Results:  
As soon as "r" is typed, the web page is opened, because the
original web page has a JS function that opens web pages on some key presses
(this is what I guess after looking at the source).

Expected Results:  
As typing "r" occurred in a FAYT context, this event shouldn't have been passed
to javascript code, i.e. Mozilla should behave as if there were no JS.
Comment 1 Oliver Klee 2003-08-04 08:31:11 PDT
Confirming on 2003080304 WinXP.
Comment 2 Aaron Leventhal 2003-08-04 09:10:24 PDT
You have to call event.preventDefault() on key events you don't want FAYT to get.

See the testcase attachment in bug 167921

*** This bug has been marked as a duplicate of 167921 ***
Comment 3 Vincent Lefevre 2003-08-04 09:55:57 PDT
Reopening: I want the opposite. I complain because a web page is stealing
keypresses for FAYT. Mozilla shouldn't allow this.
Comment 4 Aaron Leventhal 2004-06-10 13:27:50 PDT
(In reply to comment #3)
> Reopening: I want the opposite. I complain because a web page is stealing
> keypresses for FAYT. Mozilla shouldn't allow this.

Yes it should. Web apps need to be able to decide what happens to their
keystrokes. We're just following the DOM by support event.preventDefault().

Comment 5 Vincent Lefevre 2004-06-10 16:28:15 PDT
No, look at what Mozilla does. When the user types '/', FAYT operation is
entered. If the user types '/a', Mozilla searches for 'a' (the first 'a' is
selected). Here, nothing else occurs. If the user types '/r', the first 'r' is
selected, but the 'r' is also used by Javascript. Using the 'r' for two
different operations at the same time is definitely a bug.

If the user wants the web application to process the 'r', he can just type 'r',
not '/r'. (Now, there should be an option to prevent web applications from
getting key events, and also a way to indicate that the default key events may
no longer be taken into account, i.e. the user needs to know what will happen
when he does something, but this is another problem.)
Comment 6 Aaron Leventhal 2004-06-11 05:45:03 PDT
Perhaps the fix is something like: 
Don't let the web page see keysrokes once find as you type has been started. If
they want to use preventDefault() to keep Find As You Type from starting in the
first place, that's okay. But if thy're going to let / or ' or anything else
start FAYT, then FAYT would keep going.

This might be hard to fix -- we have to see the key events before they do, once
FAYT has begun. However, we only want to look at the keypress after they do if
we're determining whether we should start FAYT.

Comment 7 Vincent Lefevre 2004-06-11 06:25:02 PDT
I agree, and yes, this would need to interpret key presses at two different
places, depending on the context. BTW, an improvement of the event processing
could have other benefits (I've noticed some race conditions in the focus
change, particularly annoying when the machine is very loaded).
Comment 8 Aaron Leventhal 2004-06-11 13:34:40 PDT
I would approve of a fix that did what comment 6 said, as long as we were very
careful about regressions. FAYT is fairly stable these days.
Comment 9 Scott Gifford 2004-10-15 13:51:47 PDT
Still seeing this in 20041013, on a similar citeseer page.  Strangely, CTRL-F
works fine, even though it brings up the same search bar working in almost the
same way in this version of Firefox.
Comment 10 Steve Bennett 2005-11-19 01:12:57 PST
User comment: I'd like this to be an option.  It would be great if I could disable FAYT for gmail (so that 'C' does compose new mail etc).  But I can see that in other cases, FAYT should take precedence.
Comment 11 Vincent Lefevre 2005-11-19 02:43:01 PST
Steve, for what you want, you can already disable FAYT when you start typing; then it will start only after some hotkey. See
Comment 12 timeless 2006-02-24 15:44:09 PST
i'm not actually volunteering, but i agree w/ the reporter, and pages that do this (gmail) bother me. my choices are either turning off their feature (as i did for gmail) or not using the pages.

(i might actually do this, i need to talk to people and figure out how it might be done.)

bz: should this be as simple as changing the order of event dispatch so that taf is earlier (i.e. before content)?
Comment 13 Boris Zbarsky [:bz] (still a bit busy) 2006-02-24 15:50:37 PST
taf should generally be after content.  As in, content should be able to prevent taf.
Comment 14 Tristan Miller 2012-02-13 02:29:13 PST
Possible duplicate of/related to Bug 276295.
Comment 15 Philip Chee 2012-02-13 10:31:38 PST
> Possible duplicate of/related to Bug 276295.
Probably. Thanks for the heads up.

*** This bug has been marked as a duplicate of bug 276295 ***

Note You need to log in before you can comment on or make changes to this bug.