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
