276295 - document.onkeypress not disabled by type-ahead find

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[Robin Green]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20041227 Firefox/1.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20041227 Firefox/1.0+

If the preference "Begin finding when you begin typing" is enabled, and you use
type ahead find, document.onkeypress events will still be generated, which might
cause you to unexpectedly navigate to a new page.

Reproducible: Always

Steps to Reproduce:
1. Visit URL above
2. Type "lec"

Actual Results:  
I am immediately forwarded to the "Correct: Type Classes with Functional
Dependencies - Jones" page, which is not what I wanted.

Expected Results:  
Should not have passed the key event both to the type ahead find handler and to
the javascript code on the first page. As a rule, keys are never supposed to do
two (mutually contradictory!) things at once. Should instead mask the key event
from the javascript code.

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.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

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.

Comment 2

[Tristan Miller]

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.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

*** Bug 295712 has been marked as a duplicate of this bug. ***

Comment 4

[:Gavin Sharp [email: [e-mail]]]

*** Bug 309903 has been marked as a duplicate of this bug. ***

Comment 5

[Stefan Geisseler]

This bug seems to be fixed in 1.5
Please verify. thx.

Comment 6

[Chris Lawson (gone)]

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.

Comment 7

[zug_treno]

Duplicate of/related to SeaMonkey bug 215024?

Comment 8

[David Bolter [:davidb] (NeedInfo me for attention)]

Mass un-assigning bugs assigned to Aaron.

Comment 9

[Vincent Lefevre]

(In reply to Gavin Sharp (use [e-mail] 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).

Comment 11

[Tina]

I am also having problems with this. I have a small javascript online experiment and use keybindings to only allow input from certain keys on the keyboard. However the "Find as you Type" feature overrides my keybindings (onkeydown) and transfers them to the browser search box. Of course the user can turn off the "Find as you Type" feature, but that's not something that users would know or even want to do. If would be nice if the browser prefered the keybindings of the site, rather than its internal settings.

Comment 12

[Robin Green]

Tina: That is a different issue. This bug is about the opposite problem: keypresses being sent to the site instead of type-ahead find.

Comment 14

[Nicolas Barbulesco]

(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.

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S4. However, the bug has 4 duplicates.
:Jamie, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 16

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.