Closed Bug 245571 Opened 21 years ago Closed 10 years ago

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

Categories

(Core :: DOM: Events, defect)

Product:
Core
Component:
DOM: Events
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jason, Assigned: oliver_yeoh)

Details

Attachments

(1 file)

HTML test file to capture keyevents via onkeydown and try to cancel
2.51 KB, text/html
Details
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
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.
The Print menuitem acually listens for a keypress with a charCode of 112.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
No longer depends on: 234455
Resolution: --- → INVALID
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 → ---
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
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/
This bug is still around, test case still fails. Just posting this so it does not get auto-deleted.
Assignee: events → oliver_yeoh
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)
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.
(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).
(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?
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
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
Closed: 21 years ago → 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: