| Erik Chen | 6e4c8b5 | 2021-09-03 17:54:54 | [diff] [blame] | 1 | The terms "activation" and "focus" are often used in the chromium code base with |
| 2 | different semantics depending on platform [windows, macOS, etc.] or component |
| 3 | [e.g. views, blink]. For legacy reasons, sometimes even in a given component |
| 4 | [e.g. views] the semantics are unclear. |
| 5 | |
| 6 | The goal of this document is to outline the intended definition of these terms. |
| 7 | This is not a one-size fits all solution. It fails to capture some |
| 8 | platform-specific nuances -- e.g. key vs main windows on macOS -- but it |
| 9 | provides a common lexicon for discussion. |
| 10 | |
| 11 | Activation: Only applies to windows - boundary that applies to focusable |
| 12 | elements. |
| 13 | |
| 14 | Focus: Only applies to leaf controls - Keyboard focus is sent and generally |
| 15 | processed by the targeted leaf element. |
| 16 | |
| 17 | Activation and focus are not interchangeable. Windows are required to managed |
| 18 | focus within themselves (adjusting as necessary, even when not activated!). |
| 19 | Likewise, each tab/web-contents remembers its focused leaf control, even when |
| 20 | the tab is not showing because it's backgrounded. |
| 21 | |
| 22 | Focusing a window is not a valid concept -- usually the intention is activation. |
| 23 | |
| 24 | Focusing a control within a window is fine, and will also activate the window. |
| 25 | |
| 26 | Activating a window brings it to the front, and gives the window priority [but |
| 27 | not exclusivity] for handling input events. |
| 28 | |
