document.onkeypress not disabled by type-ahead find

NEW
Unassigned

Status

()

Core
Disability Access APIs
--
minor
13 years ago
3 years ago

People

(Reporter: Robin Green, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

13 years ago
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.
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.
OS: Linux → All
Hardware: PC → All

Comment 2

12 years ago
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. ***

Comment 5

12 years ago
This bug seems to be fixed in 1.5
Please verify. thx.
QA Contact: bugzilla → disability.access

Comment 6

10 years ago
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.
Component: Disability Access → Disability Access APIs
Product: Firefox → Core
QA Contact: disability.access → accessibility-apis

Comment 7

8 years ago
Duplicate of/related to SeaMonkey bug 215024?
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody

Comment 9

5 years ago
(In reply to Gavin Sharp (use gavin@gavinsharp.com 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).

Updated

5 years ago
Blocks: 215024
Duplicate of this bug: 215024

Comment 11

4 years ago
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.
(Reporter)

Comment 12

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

Comment 14

3 years ago
(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.
You need to log in before you can comment on or make changes to this bug.