If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Cannot cancel keydown events when key combination is in use by Mozilla, need to cancel keypress instead

RESOLVED FIXED

Status

()

Core
DOM: Events
RESOLVED FIXED
14 years ago
3 years ago

People

(Reporter: Jason Keirstead, Assigned: Oliver Yeoh)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040506 Firefox/0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040506 Firefox/0.8

When catching the keydown event through an event listner, it is impossible to
cancel the event and have it not propegate up to the Mozilla GUI layer, if the
key combination is bound to a Mozilla shortcut. Even though the event *should*
be cancelable ( even e.cancelable is true ), the Mozilla action happens anyway.

This is making it impossible to develop a browser-based application that wants
to make use of any key combinations Mozilla deeps appropriate to commandeer.

I am also constantly having problems with "Find as you type" taking over *every*
kepress. It seems to also be impossble to cancel through the DOM.


Reproducible: Always
Steps to Reproduce:
<html>
<head>
<script>        
window.addEventListener("keydown", function (e) {

    if( e.keyCode == 80 && e.ctrlKey )
    {
        alert( "This should *not* bring up the printer menu, because
e.cancelable == " + e.cancelable );

        e.stopPropagation();
        e.preventDefault();
    }

}, false );
</script>
</head>
</html>

Actual Results:  
Printer dialog appears anyway.

Expected Results:  
The DOM event should be canceled and nothing should happen.
Find as you type can most certainly be prevented by preventing
bubbling/capturing/default action.... (at least in current builds).

For the rest, make sure that this is not a mixup between keyCode and charCode....
Depends on: 234455
(Reporter)

Comment 2

14 years ago
It is not a mix up, I assure you.

Open the sample code in Firefox and try for yourself. If you press CTRL+P, the
alert *does* happen (so we know the code block executes), but the event bubbling
is *not* canceled, in the sense that the Print dialog still appears.

Comment 3

14 years ago
The Print menuitem acually listens for a keypress with a charCode of 112.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
No longer depends on: 234455
Resolution: --- → INVALID
(Reporter)

Comment 4

14 years ago
I do not think anyone even really looked at my problem, however, I somewhat
diagnosed it myself. If I also cancel the kepress event, it blocks the dialog.

What is going on is the dialog is still coming up unless you also cancel the
keypress event, so I guess the mozilla keybindings are bound to keypress not
keydown. But this is totally wrong to me.. if I cancel the keydown event. then
keypress should not even be fired.

Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
(Reporter)

Updated

14 years ago
Summary: Cannot cancel keydown events when key combination is in use by Mozilla → Cannot cancel keydown events when key combination is in use by Mozilla, need to cancel keydown instead

Comment 5

13 years ago
I'm confused by most of this but it seems you are seeing or at least describing
in comment 4 bug 167145.
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
(Reporter)

Comment 7

12 years ago
This bug is still around, test case still fails.

Just posting this so it does not get auto-deleted.

Updated

11 years ago
Assignee: events → oliver_yeoh

Comment 8

11 years ago
Created attachment 251814 [details]
HTML test file to capture keyevents via onkeydown and try to cancel

Comment 9

11 years ago
I have an additional example where I can not cancel some keystrokes caught via
the keydown event.   This attached file tries to catch ctrl-pageup and
ctrl-pagedown before Firefox changes to another tab. Returning false from the
onkeydown event handler does not work. Neither does event.stopPropagation() nor
event.preventDefault.

User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1)
Gecko/20061204 Firefox/2.0.0.1
The title of this bug is a bit confusing to me: "Cannot cancel keydown events when key combination is in use by Mozilla, need to cancel keydown instead"
Should it be: "Cannot cancel keydown events when key combination is in use by Mozilla, need to cancel keypress instead"? (see comment 4)

Comment 11

10 years ago
Yes, the title should be "Cannot cancel keydown events when key combination is in use by Mozilla, need to cancel keypress instead".

I'm hitting exactly the same problem.

This ought to be fixed together with bug 167145. But it seems that the fix to bug 167145 has only handled the case when using an html event handler with return value = false. The problem's still there when using event.preventDefault() .
Given the fact (as Neil says in comment #3) that FF print listens for a keypress ; and the work done on related bug #167145, this is behaviour is intentional.

Do we want to push for the FF menu bar keypress listener to respect the preventDefault flag?

I'm not sure. 

Comment 13

10 years ago
(In reply to comment #12)
> Do we want to push for the FF menu bar keypress listener to respect the
> preventDefault flag?

How about tab switching with CTRL+1, CTRL+2, etc? These are very common candidates for using as an accelerator in today's AJAX applications. So if I listen to that in the onkeydown event, I have no way to prevent the FF's default tab switching behavoir. This force me to listen to the event in onkeypress, which I think is bad (onkeydown and onkeypress have different meanings and different attributes in their event object).
(Reporter)

Comment 14

10 years ago
(In reply to comment #13)
> > Do we want to push for the FF menu bar keypress listener to respect the
> > preventDefault flag?

Yes we should.
 
> How about tab switching with CTRL+1, CTRL+2, etc? These are very common
> candidates for using as an accelerator in today's AJAX applications. So if I
> listen to that in the onkeydown event, I have no way to prevent the FF's
> default tab switching behavoir. 

Agree. It is very frustrating to be able to make a page behave perfectly in IE and it being impossible to replicate the effect in Firefox due to it not allowing canceling of browser events.

I wonder if making FF menu bar keypress listener respect the preventDefault flag has accessibility implications.

Aaron, was this done to prevent keyboard user lockout?

Updated

10 years ago
Summary: Cannot cancel keydown events when key combination is in use by Mozilla, need to cancel keydown instead → Cannot cancel keydown events when key combination is in use by Mozilla, need to cancel keypress instead

Comment 16

10 years ago
See comment 11. In bug 167145, was to ensure that when a keydown is cancelled that the corresponding keypress/keyup are also cancelled.

If comment 11 is true and that only works via the return value, it's a bug. That fix should also have worked via preventDefault() on the event.

However, I would suggest opening a fresh bug because this one is becoming very unclear. Something like "preventDefault() on keydown should also preventDefault() on corresponding keydown and keypress". Mark this as a dependency, and then point to bug 167145 in the description of the new bug.
QA Contact: ian → events
Starting with 25, Gecko stops dispatching keypress event if keydown event is consumed by a call of preventDefault(). If you still see this bug with some operation, that may be:

1. By design for security reason. E.g., even if Esc key is consumed by JS, dropdown of <select> element should be closed.
2. Just a bug of the function. Some key event handlers in Firefox and Gecko may forget to check preventedDefault value before handling key event.

For the #2 cases, please file bugs separately. Each of them is an independent bug.
According to http://jsfiddle.net/53y19oee/ preventing ctrl-P from printing now works, however in the file attached to this bug ctrl-PgUp and ctrl-PgDown will switch  tabs in Firefox even when the "keydown" capturing element has focus. I'd expect a different result here. Masayuki, what about you?
Flags: needinfo?(masayuki)
(In reply to Hallvord R. M. Steen [:hallvors] from comment #18)
> According to http://jsfiddle.net/53y19oee/ preventing ctrl-P from printing
> now works, however in the file attached to this bug ctrl-PgUp and
> ctrl-PgDown will switch  tabs in Firefox even when the "keydown" capturing
> element has focus. I'd expect a different result here. Masayuki, what about
> you?

That's a case of #1. If key focus is locked by a web page, it's one of the most serious accessibility issue. E.g., imagine, you can use only keyboard, but you cannot switch tabs from keyboard on a page. See bug 1008772.

Web browser is platform of web apps. However, the most important job of web browser is its user's agent. Therefore, if web apps provides some inconvenience to the user, web browser should protect its user from such web page.
Flags: needinfo?(masayuki)
Sorry, following my blog is written in Japanese, but you can see the list of key combinations which ignore KeyboardEvent.defaultPrevented intentionally:
http://www.d-toybox.com/studio/weblog/show.php?mode=single;id=2014061001
Thanks for your comments. A user-agent is a thing that frequently gets into existential crises when a keyboard gets involved :-p
I'l close this - it's half fixed and the rest is by design..

(I've personally sort of shifted my view from "we must protect users from all annoyance" to "sites that annoy the users will loose users and go away anyway, so we might as well enable a little more functionality" but I'll accept that the status quo is the outcome of years of discussion ;))
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.