---
# System prepended metadata

title: Input Event path
tags: [Chromium-Graphics, elkurin-daily-note]

---

# 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)".