The workarounds added in #2498 and #2437 fixed stuck key/modifier bug
caused by wlroots commit e218990. But now that the commit was reverted in
0.19, the workarounds are no longer needed.
Removing the workarounds also fixes a minor regression with Fcitx5+Firefox
that pressing Ctrl+Enter in an input box causes stuck modifier.
683f67b7 introduced another regression that the modifier state (Ctrl) is
stuck when Ctrl+F is pressed in some applications like Firefox while
Fcitx5 is running. This caused mouse scrolls to zoom in/out the UI.
Let me explain the cause in detail. When Ctrl+F is pressed, an input box
is opened in the application and Fcitx5 creates a new virtual keyboard
(VK), whose initial modifiers is empty. Then prior to 683f67b7, the
key/modifiers events flowed like this:
- The compositor detects F key-release
- Modifiers (Ctrl pressed) are notified via _set_keyboard()
- F key-release is forwarded to IM
- IM sends modifiers (Ctrl) back to the compositor via VK
- **The modifiers on VK is updated (empty->Ctrl)**
- **Modifers (Ctrl) are notified to the app**
- IM sends F key-release back to the compositor via VK
- F key-release is notified to the app
- The compositor detects Ctrl key-release
- Ctrl key-release is forwarded to IM
- Modifiers (empty) are forwarded to IM
- IM sends Ctrl key-release back to the compsitor via VK
- Ctrl key-release is notified to IM
- IM sends modifiers (empty) back to the compositor via VK
- **The modifiers on VK is updated again (Ctrl->empty)**
- **Modifiers (empty) are notified to the app**
Thus, the final modifiers (empty) is notified to the application as
expected. However, after 683f67b7, the key/modifiers events flowed like
this:
- The compositor detects F key-release
- F key-release is directly notified to the app
- The modifiers (Ctrl) is also notified to the app
- The compositor detects Ctrl key-release
- Ctrl key-release is directly notified to the app
- Modifiers (empty) are forwarded to IM
- IM sends modifiers (empty) back to the compositor via VK
- **Modifier on VK is not updated (empty->empty)**
- **The compositor ignores it**
So the final modifier (empty) is never notified to the application, which
causes stuck Ctrl modifier.
This commit fixes this by not forwarding the modifiers when it hasn't been
updated since it was forwarded previously. So after this commit, the
key/modifiers events flow like this:
- The compositor detects F key-release
- F key-release is directly notified to the app
- The modifiers (Ctrl) is also notified to the app
- The compositor detects Ctrl key-release
- Ctrl key-release is directly notified to the app
- The modifiers are directly notified to the app because the modifiers
(empty) are the same as the last forwarded modifier (empty).
After commit e2189903 in wlroots, when ctrl-f is pressed in firefox with
a IME client running, the following key-release event for "f" is not
sent, thus "f" is repeated like "ffffffffff..." in the input box of
firefox. This is because the key-release event for "f" is firstly
forwarded to the IME client and then sent via the virtual keyboard created
by the IME client while the key-press event is sent via physical
keyboard, and with e2189903, key-release events without a corresponding
key-press event on the same keyboard is not emitted to the compositor.
So this commit fixes this problem by not forwarding the key-release event
to the IME client unless the corresponding key-press event was also
forwarded.
We didn't support multiple IME popups since input-method-v2 protocol
has no way to position them individually, but we should support it to
provide IME developers with more programming flexibility.
