# Input Event path Aura is an abstraction layer used for multiple platforms. The events goes to Aura in the beginning, and then will be passed to views and each platform-dependent implementations. I've read wayland-specific implementations for a while. Now, let's see Aura side. Reading [The Life of an Input Event in Desktop Chrome UI](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/ui/input_event/index.md). ## Overview The event is dispatched and then its target is calculated. Here's the overview. ![](https://hackmd.io/_uploads/ryApzmfR3.png) OS generates a low-level input event and pumps it into a message loop and then delivered to a DesktopWindowTreeHost. Mouse event and Key event goes through slightly different path. Key event path is very simple. Mouse only has a location information and it is handled in EventTargeter, so it goes through WindowEventDispatcher, aura::Window and views. This "WindowEventDispatcher" is for calculates a target which will be described in the next section. On the other hand, the input event requires IME handling. [InputMethod](https://source.chromium.org/chromium/chromium/src/+/main:ui/base/ime/input_method.h;l=48;drc=ef67576ec128379c56c1ee33f2668c3aab615500) is a interface that encapsulates a native input method service. Also the path changes whether key events have an accelerator key. ## Event Targeter ![](https://hackmd.io/_uploads/HJS3GEf02.png) [EventProcessor](https://source.chromium.org/chromium/chromium/src/+/main:ui/events/event_processor.h) receives an event and dispatches it to a tree of EventTargets. EventTargets tree is receusively traversed accordingly to the location info for MouseEvent and cursor position for Key Event. This part is described in the note "[Hit Testing](/Q8eDnTaNQHKdEQOhgMVGZg)".