Re: DOM3 Events Keyflow

On Mar 27, 2008, at 9:04 PM, Doug Schepers wrote:

> I've made a trial schematic to get us started [1].  I've also  
> modeled it in Graphviz, and I've included the Dot format file here  
> (attached). Graphviz is free open source software [2], and the Dot  
> format is really simple to edit.


  I've been looking at the diagram periodically for the last couple of  
weeks, and I finally have some idea about what to say from a point of  
view of someone who has touched this code in WebKit code quite a bit  
recently.

  I think that possibly a better way to characterize event flow would  
be to think of it in terms of default handlers, not state diagrams.  
That would better match what browsers do (we don't really maintain  
much state in WebKit, although some is definitely maintained by the OS).

  A state diagram necessarily
a) could only be valid for a single type of focused element, as they  
all have different default handlers;
b) conflates very different notions of keyboard events and text input;
c) encompasses several layers of functionality (OS and browser);
d) omits important details about the events (e.g. what  
preventDefault() does).

  As I have it in my head, there is really no order for input events -  
e.g. textInput can be dispatched because of a mouse click. You even  
cannot guarantee that  keypress always comes after a keydown that  
caused it! One example: when pressing the key right to "1" on a German  
keyboard layout twice, one gets keydown, keydown, keypress, keypress.  
Also, keydown may be totally missing if text input comes from some  
utility (such as a virtual keyboard, enhanced clipboard manager etc.).  
On Windows, any process that sends a WM_CHAR message to a browser view  
will generate keypress without a keydown.

  I wish I had realized this earlier, when there wasn't so much work  
put into this diagram, sorry about that.

- WBR, Alexey Proskuryakov

Received on Thursday, 27 March 2008 19:16:01 UTC