Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: LFRon The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Hi @LFRon. Thanks for your PR. I'm waiting for a linuxdeepin member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Reviewer's guide (collapsed on small PRs)Reviewer's GuideThis PR ensures that when a temporary keyboard grab ends, the IME’s own keyboard grab is correctly restored, preventing situations where fcitx5 fails to appear or becomes unusable after other grabs interfere. Sequence diagram for restoring IME keyboard grab after other grab endssequenceDiagram
participant Seat
participant WInputMethodHelper
participant IMEKeyboardGrab
participant OtherKeyboardGrab
Seat->>WInputMethodHelper: notify_keyboard_grab_begin
WInputMethodHelper->>Seat: keyboard_start_grab(OtherKeyboardGrab)
Seat->>WInputMethodHelper: notify_keyboard_grab_end
WInputMethodHelper->>WInputMethodHelper: handleKeyboardGrabEnd()
alt [activeKeyboardGrab and current grab != keyboardGrab]
WInputMethodHelper->>Seat: keyboard_start_grab(keyboardGrab)
end
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅ |
6d84a13 to
f4d41e9
Compare
|
TAG Bot New tag: 0.8.17 |
c7ac3b3 to
60bf411
Compare
51bcb32 to
c676a1f
Compare
|
大佬们有没有好思路修复这个( |
49e9b4a to
502ecd5
Compare
|
TAG Bot New tag: 0.8.18 |
de1839c to
c363b5c
Compare
|
TAG Bot New tag: 0.9.1 |
d6a2f80 to
e95dbde
Compare
9d1ef55 to
6135a3f
Compare
|
TAG Bot New tag: 0.10.0 |
7fcbd2b to
fc61cfe
Compare
5008491 to
2cb9f46
Compare
What this fixes --------------- In WPS Office (and other XEmbed-based X11 apps) the input method is dead in the document editing area while it keeps working in the home/search frame. The editor is not a plain Qt child widget: it is an XEmbed plug window on a separate X client connection, reparented inside the Qt shell top-level. To route text into it the shell legitimately issues XSetInputFocus onto that subwindow, exactly what a real X11 window manager allows. Root cause ---------- xwm_handle_focus_in() guards against cross-application focus stealing: when a FocusIn arrives for a window xwm does not manage and whose pid does not match, it snaps input focus back to the previously tracked top-level. XEmbed plug windows are never xwm surfaces (xwm only tracks managed top-levels), so every legitimate in-client focus move into the plug is misread as a steal and yanked back to the shell. The embedded editor never keeps real X input focus, so input-method activation gated on real X focus (XIM/XIC set-focus) never fires: the input method looks dead even though plain X keys still reach the window. The fix ------- Before refocusing, check whether the window that just gained X input focus is located inside the currently focused surface's X subtree. That is an in-application focus move inside the client's own hierarchy -- what a bare X server and KWin leave alone -- so accept it silently instead of grabbing focus back. Genuine cross-application stealing still falls through to the existing refocus path. The check walks upwards from the newly focused window (XQueryTree parent pointers) with a hard cap of 8 hops, stopping at the root window, so it needs at most a handful of synchronous X queries in every case -- one for a plain top-level, two for a framed window. The previous top-down search visited the focused window's whole subtree, which is unbounded in width, on the compositor main loop for every FocusIn that needed the check. A WLR_DEBUG line (child, parent, queries, result) keeps the runtime cost of focus churn observable. Scope: only windows inside the focused top-level's own subtree are exempted; the same-pid (Steam-type) special case, override-redirect handling, the pointer-detail filter and the focus-serial race guard are untouched.
Combined input-method fix for treeland sessions: the Wayland input-method
stack in waylib, candidate-window anchoring and popup-grab bookkeeping in
treeland, and the session environment that X11-side input methods depend on.
Wayland input-method stack (waylib):
- Route input-method keys through a dedicated WSeat keyboard filter instead
of a synthetic wlr_seat_keyboard_grab. The IM grab object and xdg-popup /
drag grabs competed for one seat grab slot, and a displaced popup grab
left text-input focus, IM activation and keyboard delivery out of sync
(folder rename in dde-file-manager broke; XWayland windows stopped
receiving keys after popup close). Physical key/modifier events now go to
the active input-method keyboard endpoint only while the keyboard focus
surface owns an eligible text input, excluding the IM's own virtual
keyboards and active drags; popup and drag keep their own wlroots grabs
untouched.
- Activation stays strictly text-input driven. It is held on the anchor only
across the momentary null focus of a window switch, so a focus flickering
through null does not tear down and re-create the fcitx5 grab and virtual
keyboard. As soon as focus settles on a concrete surface without an
eligible text input (terminals, XWayland windows, the compositor's own
QML), the input method deactivates: those surfaces must keep their raw keys
so the client-side input-method path (XIM / D-Bus frontends) stays in
charge, and a held activation would leave the candidate window parented to
an unrelated text input. A destroyed or client-disabled anchor still falls
through to normal deactivation.
- Commits never follow the anchor: a commit is delivered only to the text
input exactly matching current keyboard focus. The virtual-keyboard typing
fallback stays as a defensive path for commits that arrive while a held
activation has not been reconciled against the new keyboard focus yet
(latin/symbol keysyms; CJK needs an xwayland-side text-input bridge, out
of scope here); other ineligible commits are discarded with a warning
instead of being typed at the wrong surface, and the synthetic key events
convert the xkb keycode of the keysym lookup back to the evdev keycode
wlr_keyboard_notify_key() expects.
- Text-input enablement follows the protocols again: a compositor-driven
enter/leave is a notification, not a disablement. For text-input-v1 the
client activate record is persistent (cleared only by the client's own
deactivate or the surface's destruction, enter/leave kept paired), so
focus returning to an activated surface re-arms it deterministically. For
text-input-v2 the leave no longer emits disabled(); revocation flows only
through the client disable request or enabled-surface destruction, and
every new enter is preceded by the obsolete leave.
- Attach the IM keyboard endpoint to the keyboard group device when it is
created (fcitx5 recreates its virtual keyboard right before grab
requests), take keyboard-focus enter payloads from the group, restore the
group keyboard when a virtual keyboard dies, guard Qt repeat handling
against invalid keyboards/disabled rates, and re-run instead of dropping
re-entrant focus reconciliations.
- Popup focus tracking (seatsurfacemanager) validates exact
wlr_xdg_popup_grab membership, tracks replacement and end events
separately, restores the concrete pre-popup focus only while the tracked
popup still owns focus, and dismisses the concrete popup instead of
ending an arbitrary seat grab.
- Categorized transition logs (input-method / text-input / popup-focus)
carry object and state identifiers only, never key codes, surrounding
text, preedit or committed user input.
Input-method popup anchoring (waylib + treeland):
- Candidate windows (zwp_input_popup_surface_v2) are anchored to the text
input that currently owns the input-method focus, not to the surface that
happened to be focused when the input method created its panel, so the
candidate window follows one application switching text focus between its
own windows.
* waylib announces the settled focus surface through a new
textInputFocusSurfaceChanged signal, emitted once the focus
reconciliation settled (idempotent, nothing emitted during teardown).
* A popup surface that arrives before any text input is eligible is parked
in a pending list and attached on the next reconciliation. The input
method reuses its panel surface until the panel hides, so dropping the
popup kept the candidate window invisible for that whole period.
* treeland resolves the placement parent of an input popup dynamically
(the current text-input focus surface looked up in the root surface
container, falling back to the popup's own recorded parent), re-parents
the popup to the placement parent's output and re-arranges it whenever
the text-input focus surface changes.
* Input-popup add/remove handling is null-guarded on both sides: a popup
whose anchoring surface is already gone is skipped symmetrically instead
of dereferencing a wrapper that was never created.
XWayland session environment (src/systemd-socket.cpp,
misc/systemd/.../treeland-xwayland.service.in):
- Publish DISPLAY and XAUTHORITY through systemd1.SetEnvironment in addition
to UpdateActivationEnvironment. Transient session units (How apps and
fcitx5 are started via StartTransientUnit) inherit the *manager*
environment, not the activation one, so X-side input methods were blind to
the XWayland display in treeland sessions; dde-session performs this same
call on KWin, which is why it only worked there. UnsetEnvironment and
ExecStop now clear XAUTHORITY alongside DISPLAY.
- Gate unit readiness on the compositor's ActivateWayland business reply: a
successful D-Bus call returning false means the compositor is registered
but not yet ready for this session socket (login handover). Retried in a
bounded ~20s window, then degraded to the historic publish-anyway path so
the session can never hang; this stops advertising WAYLAND_DISPLAY and
autostarting input methods against a socket nobody serves, where they
stayed permanently broken.
Input-method Wayland reconnect (src/systemd-socket.cpp):
- After a successful wayland activation, hand a fresh Wayland connection to
the running input method (fcitx5). fcitx5 opens its Wayland connection once
at startup and never retries, so a compositor restart used to leave it alive
but without its Wayland input-method frontend until it was restarted by
hand. treeland-sd now connects a client socket to the socket it just
activated and calls org.fcitx.Fcitx.Controller1.ReopenWaylandConnectionSocket
over D-Bus, which replaces fcitx5's main connection instead of adding a
second one, so the compositor never sees two input methods. The call is
asynchronous (never delays READY=1), is skipped when fcitx5 is not running
(D-Bus activation stays disabled), is retried at most once, and only logs on
failure. The degraded publish-anyway path never hands over a socket that
nothing is serving.
Stacking robustness (src/surface/surfacewrapper.cpp):
- SurfaceWrapper::stackAfter() falls back to the sub-chain head (validated
as a sibling by the entry guard) when its deepest stacked member lives in
a different QQuickItem container, as X11 transient children may:
QQuickItem::stackAfter() silently rejects non-siblings and aborted the
raise with the stacking bookkeeping left out of sync.
Together with the vendored wlroots XEmbed focus exemption committed
separately, the input method now works in native Wayland clients (folder
rename and others, including across popups and window switches, with the
candidate window following the focused window), in XWayland clients (WPS
Office document editing included), and survives a compositor restart without
fcitx5 having to be restarted by hand.
该问题修复的是由于设置了QT_IM_MODULES, XMODIFIERS等环境变量后, 在treeland运行一段时间后一定会出现的几个问题:
该PR同时修复了上述问题
Summary by Sourcery
Restore robust input-method behavior across popup focus transitions and heterogeneous Wayland/XWayland applications.
Bug Fixes:
Enhancements:
Deployment: