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.
Before this commit, a popup surface was placed at (0,0) on its creation.
So if the popup surface is already mapped on its creation, the popup was
shown at (0,0) then quickly moved to the input-rect on surface commits
or input-rect updates.
Before this commit, scene-nodes for IME popup were destroyed when
the bound wl_surface is destroyed. However, this caused a bug that
multiple popup nodes are shown when input_popup_surface_v2 is recreated
with the same wl_surface.
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.
When Fcitx5 is activated, it creates a virtual keyboard to send keycodes to
applications, then creates a keyboard grab to capture keycodes the user typed.
Before this commit, we set keyboard grab's modifiers to that of currently
active keyboard, which is the virtual keyboard created in the case described
above. However, since the modifiers of the virtual keyboard is empty at first,
we actually set empty modifiers, even when the user is pressing modifiers.
Then, Fcitx5 assumes no modifiers is pressed and redirect the modifier state
back to the compositor via the virtual keyboard. As a result, when the focus
is switched between windows by workspace-switcher, the workspace-switcher is
immediately terminated.
To fix this issue, with this commit, the modifier state of the currently active
keyboard is not set to the keyboard grab if the keyboard is a virtual keyboard
created by the same input-method client.
Fcitx5's commit below is also required to fix the issue.
b2924bd361
