WM_TAKE_FOCUS
The ICCCM protocol that, together with one flag in WM_HINTS, gives four different answers to who decides where keyboard focus goes — the application, the window manager, or nobody at all.
Keyboard focus in X is a single window, and XSetInputFocus can be called by anyone. ICCCM had to regulate who does it when the user clicks a window, and the answer became a matrix. The input field in WM_HINTS says whether the application wants the window manager to give it focus; listing WM_TAKE_FOCUS in WM_PROTOCOLS says whether it wants to be told. Four combinations: No Input, for xclock and xload, which never want the keyboard; Passive, where the window manager simply sets focus on the top-level window and the application is content, like xterm; Locally Active, where the window manager sets focus and additionally sends the message so the application can pass focus on to the right text field among its own subwindows; and Globally Active, where the window manager never touches focus but only sends the message and lets the application decide for itself.
The message carries a timestamp, and the application must use it rather than CurrentTime in its own call, or an older click can beat a newer one. The models explain a whole genre of bug reports. Motif and Xt programs are Locally Active, as are GTK and Qt. Java's AWT chose Globally Active and takes focus through a proxy window of its own, which is one reason Java applications struggled for years to get the keyboard in tiling window managers like dwm and xmonad. Window managers that ignore the matrix and just set focus usually work — until they meet a program that took ICCCM seriously.