[Bug 25448] Keyboard Event Types (some correct)

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25448

--- Comment #3 from Travis Leithead [MSFT] <travil@microsoft.com> ---
(In reply to spiritRKS1910 from comment #0)
> Keyboard event tables
> (https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#event-
> type-keydown) missing some context info:
> KeyboardEvent.code
> KeyboardEvent.isComposing

I will add these.


> =====
> 
> Target: Document, Element in above tables and in "5.1.1 List of DOM3 Event
> Types" is correct? Any case when Document fits (of course excluding the
> untrusted events)? We have this in description for keyboard event:
> "... If no suitable element is in focus, the event target will be the root
> element."
> 
> Writing "root element" you have means "document element"
> (http://dom.spec.whatwg.org/#document-element)? 

I tested IE11, Firefox and Chrome by adding a keyup event listener on the
document, and then removing the document's documentElement. Then I click on the
page to [maybe?] set focus on it, and then hit a key.
IE11: Responds with a keyup event targeted at the document object.
Firefox: No event is generated (the document can't have focus by itself)
Chrome: No event is generated (the document can't have focus by itself)

I filed the product bug on IE to correct this. :-)

In the spec, I removed "Document" as a trusted event target, and made
references to the root element. I also extended this to the keypress event.


> =====
> 
> I noticed that for some keys not all keyboard events are dispatched. Example
> (all in Win7):
> 
> - F1 firing only keydown event (in Chrome, IE)
> - F3 firing only keydown event (in Firefox, IE)
> - F6 firing only keydown event (in Chrome, IE)
> - F10 firing only keydown event (in Firefox, Chrome)
> - F12 firing only keydown event (in IE)
> - PrintScreen firing only keyup event (in Firefox, Chrome, IE)
> 
> This behavior is to much dependent on the implementation/system/device and
> will not be standardized? Information for such cases would be helpful. Now
> we have different behaviors, even if the browser do similar actions (like
> when press F3 or F6 key).

This is a known issue with "reserved" (or protected) browser application
accelerators. For example, on Windows if the browser app has a "Launch help"
feature setup and plugged into the F1 key (on keydown), then the browser traps
that keystroke and executes it's default action as a result. In the F1 scenario
(and probably all of the above mentioned cases) the default action moves
keyboard focus from the current web application to something else (thus the
matching keyup event is not received by the web application). It is unlikely
that browser implementations will change this behavior--and certain keystrokes
(e.g., Ctrl+L or Alt+D) may always be protected to ensure that users with
accessibility needs can always get to the address bar (for example), and not
have the web application prevent that from happening.

The advice (already in the spec) to get better consistency here is to call
preventDefault in the keydown event handler, which stops the browser from
executing it's default action (when possible). This allows these keys to behave
in more expected manner.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 9 May 2014 21:09:05 UTC