Bug 506095

I have experienced the same situation with these specs:
SOFTWARE/OS VERSIONS
Linux: openSUSE Tumbleweed 6.15.4-1
KDE Plasma Version: 6.4.0 - 6.4.2
KDE Frameworks Version: 6.15.0
Qt Version: 6.9.1

My discovery is that, while Electron apps are most messed up, the bug could be seen in ANY APPLICATIONS running on XWayland. When running a lot of them, the bug is occurred in random apps in a random manner (temporal), and could only be mitigated by restarting the affected application or waiting for an extensive time period. Seems no significant issues are from the fcitx side (by using packages from both the distro and flatpak).

(In reply to Sam Duan from comment #1)
> I have experienced the same situation with these specs:
> SOFTWARE/OS VERSIONS
> Linux: openSUSE Tumbleweed 6.15.4-1
> KDE Plasma Version: 6.4.0 - 6.4.2
> KDE Frameworks Version: 6.15.0
> Qt Version: 6.9.1
> 
> My discovery is that, while Electron apps are most messed up, the bug could
> be seen in ANY APPLICATIONS running on XWayland. When running a lot of them,
> the bug is occurred in random apps in a random manner (temporal), and could
> only be mitigated by restarting the affected application or waiting for an
> extensive time period. Seems no significant issues are from the fcitx side
> (by using packages from both the distro and flatpak).

Further supplements:
1. The situation is more severe (i.e. mostly if not all) in the Electron-based applications on XWayland.
2. There are sometimes, whilst rare, when the word selector appears on both XWayland Electron app's input widgets, and the upper left corner of the desktop.

Same issue.  Also found that:
- The issue occurs regardless of whether fcitx is started via "Fcitx5" or "Fcitx5 Wayland Launcher" in the "Virtual Keyboard" settings.
- When the issue occurs, focus on a non-XWayland window (alacritty in my case), switch the input method back and forth, then refocus on the problematic XWayland window, the issue usually goes away.

I encountered the same issue, so I conducted various experiments.

# Conclusion: **This is not an issue with fcitx5, Its caused by KWin's XWayland support flow**.  
There is some inconsistency in the XWayland support flow within KWin that is causing the problem.

Wayland input works only when KWin directly launches and manages fcitx5.
In such cases, however, KWin does not properly support X11 input through the usual methods.

But standaloon fcitx5 always supports and integrity with XWayland application.

# First, let me describe my environment:
1. Arch Linux (latest)
2. KDE Plasma 6.4.3
3. Wayland
4. xterm (for testing via XWayland)
5. fcitx5-mozc (Japanese input)

# Here are the experiments I conducted:
1. Attempted to input text in an XWayland application using the usual method.

This was completely non-functional. I was unable to input anything in xterm.  
The fcitx5 candidate window appeared at the “top-left corner beyond all displays,” and regardless of the method used to confirm the input, all attempts failed.

2. Manually launched fcitx5 using `fcitx5 -r`

With this, I was able to input text in xterm via XWayland without any issues.  
However, input via native Wayland applications became impossible.

In practice, this is the expected behavior, as KWin needs to launch fcitx5 itself to handle Wayland input properly.

# Conclusion
Ultimately, the conclusion is that **KWin is the root cause**.  

However, since Fcitx5 launched via KWin is at least able to display the IME switch indicator for XWayland applications, it appears that they are being recognized.
It's not that KWin is poorly designed or anything; it's just that some part of the mechanism isn't fitting together properly at the moment.

# Remarks
Simply concluding that "it doesn't work" with applications running via XWayland and leaving it at that is an act of abandoning a permanent hardship. Therefore, I will add some workarounds.

# Ways
1. Migrate to Wayland  
This is a desirable option for the future.  
In practice, if the application is based on Electron, it can be resolved by using OzonePlatform and similar methods.

2. Modify the application's source code to support Wayland  
In theory and principle, this is possible. However, it takes time.

3. Temporarily switch to X11  
This is based on the assumption that, since Fcitx5 can handle X11 natively, switching to X11 may resolve the issue.

4. Launch Fcitx5 as a standalone process only for applications running via XWayland  
This is possible, but it is not suitable for multitasking.  
Incidentally, when switching back to the Wayland environment, you need to first kill the standalone version, then turn off the virtual keyboard from the KDE Plasma settings app, switch to "Fcitx5 Wayland", and finally open the input method settings — this resolves the issue.  
The logic behind this is unclear, but it actually works. Why simply opening the input method settings automatically launches Fcitx5 is unknown, but it is likely a reset triggered by the virtual keyboard change.

5. Switch to the GitHub master version (untested)  
It is unknown whether anything will change by using the master version.  
However, there is a possibility that the issue is resolved in the master version. This is not an assumption but a speculation.

6. Use copy and paste  
In KDE Plasma, some widgets (such as the search bar) allow text input.  
You can open such a widget temporarily using a shortcut key, input the desired text there, copy it, close the widget, return focus to the target application, and paste the text — this is a realistically feasible procedure.  
This is the exact method I personally use. It is the simplest and most realistic one — though it is laborious and stressful.

7. While temporarily resolving the issue using one of the above methods, continue investigating the root cause and contribute to the KWin development team, thereby accelerating the solution  
What is critically important is this: even if we complain, it contributes nothing to solving the problem.  
I myself have never seen the KWin source code; I simply inferred the root of the issue at low cost by gathering various pieces of information.  
Only the KWin developers — those who know the source code and can efficiently trace and fix the logic — can actually perform the fix.  
Therefore, wouldn't it be most desirable for us to provide those developers with information gained through trial and error in real usage scenarios, as our current contribution?

# Remarks
To add a supplement to this: the UX is significantly degraded, so this is truly undesirable.  
It is reasonable to conclude that this is something that **needs to be resolved**.  
The existence of workarounds must not justify leaving the problem unaddressed.  
Workarounds are not solutions — and problems exist in order to be solved.  
Issues and bugs are **never** merely items on a to-do list. This is important.

To avoid confusion, I should mention that this issue does not consistently occur just because an application runs via XWayland.
The real issue lies in how the input from the IME is received.
Therefore, as long as the access path to Wayland is properly established, it is "principally", "theoretically", and "practically" possible for specific applications to receive input from the IME.

For example: Obsidian, Electron Application

Same issue started occuring for me with 6.4.
To add to the ways this can be reproduced: 
This seems to happen when you alt tab between a xwayland and a wayland application with an active text input and use the ime in both. In my case mostly a browser window with an active text field and a konsole terminal. It is not 100% consistent but i can trigger it in a few tries.
Steps:
1. Open xwayland and wayland application
2. Be in active text input field in both applications
3. Try switching and back and forth while switching the input method on and off in between. 
4. Should get broken input state

Created attachment 183532 [details]
Example video of IME breaking

The situation is a little better on Plasma 6.4.4 judging from these situations:
1. The Xwayland applicaton seems to be working longer than before until the IME gliches;
2. The bug can be eliminated by switching windows for less than 10 times (on my side, this was impossible and I have to restart the bugged application).

Weird. For me, I cannot switch input method at all in all xwayland applicaiton windows after 6.4.4 (lot of upgrades, not sure what triggers this new issue).

(In reply to leodream2008 from comment #10)
> Weird. For me, I cannot switch input method at all in all xwayland
> applicaiton windows after 6.4.4 (lot of upgrades, not sure what triggers
> this new issue).

Incorrect. Found that it still works in Chrome and Visual Studio Code, but not in Jetbrains apps(like IDEA, Pycharm) nor Steam.

I can confirm that I have also encountered this issue with Fcitx5 in XWayland applications under a Wayland session. The core problem appears to be an input method desynchronization between the Wayland session and the XWayland server, as you've correctly pointed out.

My specific experience closely mirrors the one described in the original report, but with a few additional details that may be helpful:

The Trigger: I've found a consistent way to trigger this bug. When I switch the input focus from an XWayland window to a native Wayland window, activate the input method in the Wayland window, and then switch back to the XWayland window, the issue occurs.
The Symptom: When I press `Ctrl+Space` to switch the input method in the XWayland window, the candidate box appears in the top-left corner of the screen, and I'm unable to type in Chinese.
Affected Applications: This bug affects almost all my XWayland applications, including VSCode, QQ, and WeChat. While VSCode can run natively on Wayland, WeChat cannot, which makes this bug particularly disruptive for me.
Workaround: The only reliable way I've found to temporarily fix the issue is to close the affected XWayland window and reopen it.
Configuration: I've followed the input method configuration instructions from the Arch Linux wiki and tried various environment variables like `QT_IM_MODULE` and `QT_QPA_PLATFORM`, but none of them have resolved the problem. It's possible I've missed a minor configuration detail.
A Strange Observation: The Fcitx5 candidate box border in the problematic XWayland windows seems much thinner than in the native Wayland windows. I'm not sure if this is relevant, but I haven't observed this on my other machine that isn't experiencing the bug.

I have a second computer running Manjaro with the same software and configuration, and it did not exhibit this behavior. However, after upgrading its KDE packages (including KWin) from version 6.3.6 to 6.4.4, the bug was successfully reproduced, strongly suggesting a regression in a recent KWin update. I've attempted to downgrade packages like `kwin`, `kwin-x11`, and `aurorae` but ran into a black screen issue with SDDM.

Any help would be appreciated. This seems to be a significant regression in a recent KDE update, and I'm very concerned about it since it affects essential applications like WeChat.

I hope this provides more clarity and helps in narrowing down the cause of this frustrating bug.

Additionally, here is a link to the discussion on the Arch Linux CN community where we've been discussing this issue: https://forum.archlinuxcn.org/t/topic/14640/2

I have used Chrome with ozone Wayland backend for weeks to mitigate the issue, and have consistent observation that occasionally, input method indicator (e.g. [拼] square) will appear on the left top corner (maximized window, so have no idea if it's screen corner or window corner), just like the glitched behavior in XWayland windows. Fortunately since it's still a native Wayland window, the input method indicator will still successfully follow the text cursor and submit typed characters as I'm typing.

I imagined that there might be some kind of problem occurring in the XIM compatibility implementation. I have no proof.

It turns out that xterm goes through XIM because it runs on X11.  
However, input cannot be performed in xterm, and this occurs consistently in X11 applications.  
Therefore, if this is also happening in an environment limited to XIM, it can be inferred that XIM is responsible, and thus the reasoning itself does not bring about any inconsistency.

I would appreciate it if you could contribute any reasoning, hypotheses, or inferences that adhere to logic with consistency.
By narrowing down the possible causes of these issues through such reasoning, it will become possible to pursue the bug more efficiently.

It currently goes fcitx -> xim directly. We're not involved at a KDE level.

Can you file a bug with fcitx with all your findings and drop a link here

Because I wrote a long and detailed reasoning, it is highly likely that a misunderstanding has arisen between you and me.  
My latest reasoning is as follows: “When fcitx5 is started via KWin Wayland, IME input does not work in applications that use XIM+X11; however, when fcitx5 is started directly from the command line, IME input works in applications that use XIM+X11. Therefore, to maintain a consistent explanation of this phenomenon, it must be considered an issue with KWin’s XWayland support flow, not with fcitx5.”  

If this issue were reported to fcitx5, following the current latest reasoning, it could cause unnecessary trouble for the fcitx5 developers (i.e., it would impose wasted investigation on the fcitx5 development team). Therefore, at present, it is not appropriate to do so.  

If your suggestion can still be considered correct under this premise, I would like to hear that reasoning. Otherwise, I propose that further refining the reasoning to minimize debugging efforts would lead to a more desirable outcome.

With recent KDE updates (and possibly fcitx5) things got changed.

- When one X11 window goes out of sync, seems that it won't affect other X11 windows now.
- X11 electron apps tend to go out of sync more frequently, but seems to fix itself more easily after toggling IME on and off with switching to other windows.
    - I use Chrome with Wayland backend now, so don't know if it also applies to Chrome itself with X11 backend.

Versions in use now:
- Plasma: 6.4.5
- Frameworks: 6.18.0
- Qt: 6.9.2
- Kernel: 6.16.7
- Fcitx: 5.1.14
- XWayland: 24.1.8

(In reply to gray-aids-swear from comment #17)
> Because I wrote a long and detailed reasoning, it is highly likely that a
> misunderstanding has arisen between you and me.  
> My latest reasoning is as follows: “When fcitx5 is started via KWin Wayland,
> IME input does not work in applications that use XIM+X11; however, when
> fcitx5 is started directly from the command line, IME input works in
> applications that use XIM+X11. Therefore, to maintain a consistent
> explanation of this phenomenon, it must be considered an issue with KWin’s
> XWayland support flow, not with fcitx5.”  
As David said, KWin is not involved in any way. Report this to fcitx.

Hi, fcitx dev here.

No, such issue can only be triggered by kwin.

Here's the things:
1. while there's on/off from user point of view, it's always "on" in the sense whether the key event flows to input method.
2. The behavior, as shown in video, seems to be kwin send zwp_input_method.activate() to fcitx and fcitx placed a keyboard grab.

While this should be managed together with the keyboard focus, it seems (at least from the video, since I didn't reproduce it, maybe it requires certain app?) that kwin fails send deactivate input method when xwayland window get focused.

I think the reporter probably want to open a terminal and run fcitx5 with WAYLAND_DEBUG=1 fcitx5 and focus on the zwp_input_method , so we could see the interaction between kwin & fcitx & window focus change.

1. quit/kill all fcitx5 process
2. Run `WAYLAND_DEBUG=1 fcitx5 2>&1 | grep zwp_input_method` in a terminal, keep it visible while recording
3. Select Fcitx5 Wayland launcher (instead of fcitx5) in systemsettings, so it can use the fcitx5 started by (2) instead of starting a new one
4. Try to reproduce the issue your describe.

When you focus into a non wayland app, if it's normal, you should see:

```
[ 681741.584] {Default Queue} zwp_input_method_v1#14.deactivate(zwp_input_method_context_v1#4278190081)
```

Created attachment 185010 [details]
reproduce bug with WAYLAND_DEBUG=1 fcitx5 2>&1 | grep zwp_input_method logs

reproduce bug with WAYLAND_DEBUG=1 fcitx5 2>&1 | grep zwp_input_method logs

(In reply to Weng Xuetian from comment #20)
> Hi, fcitx dev here.
> 
> No, such issue can only be triggered by kwin.
> 
> Here's the things:
> 1. while there's on/off from user point of view, it's always "on" in the
> sense whether the key event flows to input method.
> 2. The behavior, as shown in video, seems to be kwin send
> zwp_input_method.activate() to fcitx and fcitx placed a keyboard grab.
> 
> While this should be managed together with the keyboard focus, it seems (at
> least from the video, since I didn't reproduce it, maybe it requires certain
> app?) that kwin fails send deactivate input method when xwayland window get
> focused.
> 
> I think the reporter probably want to open a terminal and run fcitx5 with
> WAYLAND_DEBUG=1 fcitx5 and focus on the zwp_input_method , so we could see
> the interaction between kwin & fcitx & window focus change.
> 
> 1. quit/kill all fcitx5 process
> 2. Run `WAYLAND_DEBUG=1 fcitx5 2>&1 | grep zwp_input_method` in a terminal,
> keep it visible while recording
> 3. Select Fcitx5 Wayland launcher (instead of fcitx5) in systemsettings, so
> it can use the fcitx5 started by (2) instead of starting a new one
> 4. Try to reproduce the issue your describe.
> 
> When you focus into a non wayland app, if it's normal, you should see:
> 
> ```
> [ 681741.584] {Default Queue}
> zwp_input_method_v1#14.deactivate(zwp_input_method_context_v1#4278190081)
> ```

Hello,

I have finished the recording as requested. The video is attached to this message.

Here are the steps I followed and my key observations:

**Setup:**
1.  In System Settings, I first set the virtual keyboard to "None" to ensure no IM was running.
2.  I ran `killall fcitx5` to terminate any lingering processes.
3.  I started fcitx5 in a terminal with the debug command: `WAYLAND_DEBUG=1 fcitx5 2>&1 | grep zwp_input_method`.
4.  I then went back to System Settings and set the virtual keyboard to "Fcitx 5 (Wayland launcher)".

**Reproduction Steps & Observations:**
1.  I opened a Konsole window (a native Wayland app). Typing in Chinese worked as expected, and I could see the `zwp_input_method` logs appearing in the debug terminal.
2.  I opened an `xterm` window (an Xwayland app). I was able to type in Chinese correctly. **Importantly, during this initial interaction, no new logs related to `zwp_input_method` were generated.** This seems to be the correct behavior, as it's likely using a different protocol for Xwayland.
3.  I switched focus back to the Konsole window. Input continued to work correctly, and the Wayland logs were generated as expected.
4.  I then switched focus back to the `xterm` window. **At this point, the bug occurred.** I was unable to input any characters into `xterm`. The fcitx5 candidate window appeared incorrectly in the top-left corner of the screen.
5.  Most critically, while trying to type in the broken `xterm` window, **`zwp_input_method` logs started appearing in the debug terminal.** This seems to confirm that the Wayland input method protocol is being incorrectly activated for an Xwayland window, causing the input to be intercepted.

**Additional Finding:**
I also discovered a very specific condition to trigger this bug: the input failure in `xterm` only seems to happen **after the `xterm` window loses and regains visibility** (e.g., it is covered by a larger window and then re-exposed). If I keep the `xterm` window on top of all other windows, the bug does not seem to occur. This might suggest an issue with how window state changes (like occlusion) are handled.

I am not an expert, so I hope the logs are clear enough in the video. If needed, I can easily reproduce this again and save the full log output to a file and upload it.

Thank you for your help.

> I also discovered a very specific condition to trigger this bug: the input
> failure in `xterm` only seems to happen **after the `xterm` window loses and
> regains visibility** (e.g., it is covered by a larger window and then
> re-exposed). If I keep the `xterm` window on top of all other windows, the
> bug does not seem to occur. This might suggest an issue with how window
> state changes (like occlusion) are handled.

Sorry, that is not correct. The bug occurs only after the window has been minimized. I check logs and try to find sth like "activate". It seems that "deactivate" happens when focus changes but not happen when recover a minimized window. 

This may from a reasonable mistake in kwin. pls check what should happen while recovering a minimized window.

I see. It may be becoming possible to organize the information more clearly.  
First, the primary point is that for XWayland windows, KWin + Fcitx5 may fail to input text when using XIM.  
Next, however, for applications that support other input methods, such as Electron, input works correctly.  
Moreover, it seems that under certain conditions, such as window switching, input may fail.  

From these three points, what can be confirmed is that there is an inconsistency in determining which input method to use to start the input protocol for the target window.  
In other words, there is a clear inconsistency in the algorithm that actually selects the input method in practice.  

Considering this, the first thing that comes to mind is that logically, some kind of incorrect use of variables, unnecessary variables, or a coding mistake in the process is occurring.  
This is because, logically, processing involves manipulating variables or modifying memory states, so it is certain that this issue is related to variables.  
Furthermore, since the behavior appears to be consistent rather than probabilistic, it indicates that this occurs because some specific processing is clearly happening.  

In other words, I infer that it should be possible to further identify the exact conditions under which this behavior occurs.

As an additional note: even if the process description itself is correct, if the content of the variables is not compatible with the process, the process may produce unexpected behavior. In other words, it will likely be necessary to also consider investigating how the variables are obtained and the consistency of their values.

https://github.com/samduanx/glossaries/raw/refs/heads/main/fcitx.mp4
https://github.com/wold9168/Pictures/blob/main/video/2025-09-18%2016-39-12.mp4

In the two videos here, what's abnormal is that, when using Xwayland application, the zwp_input_context is still active and fcitx is getting key events. Now I can relatively easy to reproduce this issue.

https://bugs.kde.org/show_bug.cgi?id=506095#c23 Comment 23 gives a very useful clue. Here's the exact step:

1. open xterm, and minimize it.
2. Focus on to any text input client, e.g. kwrite. I tried firefox, not reproducing it. Maybe text-input-v2 client is more likely to reproduce..
3. Use Alt+Tab to switch to xterm.
4. From fcitx side, it is getting zwp_input_context.activate, thus it placed a keyboard grab.

For step 3, if xterm is not minimized and use mouse click to switch focus, the zwp_input_context.deactivate is correctly called, which shows that the "activate" in this bug is not intentional.

The issue on kwin side is that "zwp_input_context.activate" shouldn't happen.

Some update on the step, minimize is not required, what's really required is that when doing the Alt+Tab , Alt need to be hold until the alt+tab effect(the kwin's default one, didn't try other effect) is shown.

So the exact step would be 
1. open xterm
2. open kwrite
3. focus in kwrite's text box
4. alt+tab, hold alt until alt+tab effect kicks in.
5. switch to xterm

Git commit 2a4cdfe47b6bc91b299f8b619c33a932c711a474 by Weng Xuetian.
Committed on 19/09/2025 at 06:01.
Pushed by xuetianweng into branch 'im-focus'.

Fix a few potential missing opportunity that input method active state is not synced.

1. InternalInputMethodContext::setFocusObject(nullptr) should still notify
   enabledChanged (no focus -> disable).
2. InternalInputMethodContext::update(Qt::ImEnabled) should notify
   enableChanged.
3. KWin's QPA may missing setFocusObject(nullptr) when destroy window,
   try to monitor destroyed signal as a last resort.
4. Call refreshActive() again on seat's focused text input surface
   change.

The direct root cause to 506095 is caused by 3. Both 3 & 4 could fix
it.

M  +6    -3    src/inputmethod.cpp
M  +20   -3    src/internalinputmethodcontext.cpp
M  +3    -0    src/internalinputmethodcontext.h

https://invent.kde.org/plasma/kwin/-/commit/2a4cdfe47b6bc91b299f8b619c33a932c711a474

.. not sure why non-master push would mark it fixed..

(In reply to Weng Xuetian from comment #28)
> .. not sure why non-master push would mark it fixed..

That's because the branch name isn't starting with work/

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/8135

Git commit 8139550d447c5b4d60ffed5bdbae5542b5313293 by Xuetian Weng, on behalf of Weng Xuetian.
Committed on 19/09/2025 at 18:59.
Pushed by xuetianweng into branch 'master'.

Fix a few potential missing opportunity that input method active state is not synced.

1. InternalInputMethodContext::setFocusObject(nullptr) should still notify
   enabledChanged (no focus -> disable).
2. InternalInputMethodContext::update(Qt::ImEnabled) should notify
   enableChanged.
3. KWin's QPA may missing setFocusObject(nullptr) when destroy window,
   try to monitor destroyed signal as a last resort.
4. Call refreshActive() again on seat's focused text input surface
   change.
5. inputMethodAccepted should be considered as part of isEnabled
   condition. In Qt, having focus object is not equilvalent to allow input
   method.

The direct root cause to 506095 is caused by 3 & 5. Both 3 & 4 & 5 could fix
it.

M  +6    -3    src/inputmethod.cpp
M  +20   -3    src/internalinputmethodcontext.cpp
M  +3    -0    src/internalinputmethodcontext.h

https://invent.kde.org/plasma/kwin/-/commit/8139550d447c5b4d60ffed5bdbae5542b5313293

Git commit a60a0a686dd7c02be4a9a10cb5f6d75a15a28d5b by Xuetian Weng.
Committed on 19/09/2025 at 20:11.
Pushed by xuetianweng into branch 'Plasma/6.5'.

Fix a few potential missing opportunity that input method active state is not synced.

1. InternalInputMethodContext::setFocusObject(nullptr) should still notify
   enabledChanged (no focus -> disable).
2. InternalInputMethodContext::update(Qt::ImEnabled) should notify
   enableChanged.
3. KWin's QPA may missing setFocusObject(nullptr) when destroy window,
   try to monitor destroyed signal as a last resort.
4. Call refreshActive() again on seat's focused text input surface
   change.
5. inputMethodAccepted should be considered as part of isEnabled
   condition. In Qt, having focus object is not equilvalent to allow input
   method.

The direct root cause to 506095 is caused by 3 & 5. Both 3 & 4 & 5 could fix
it.


(cherry picked from commit 8139550d447c5b4d60ffed5bdbae5542b5313293)

Co-authored-by: Weng Xuetian <wengxt@gmail.com>

M  +6    -3    src/inputmethod.cpp
M  +20   -3    src/internalinputmethodcontext.cpp
M  +3    -0    src/internalinputmethodcontext.h

https://invent.kde.org/plasma/kwin/-/commit/a60a0a686dd7c02be4a9a10cb5f6d75a15a28d5b

thx for you all! I'm eagerly awaiting the 6.5 update

Git commit 7926c65c663af4cd415c29816a8575f72f6a8720 by Xuetian Weng.
Committed on 20/09/2025 at 15:38.
Pushed by xuetianweng into branch 'Plasma/6.4'.

Fix a few potential missing opportunity that input method active state is not synced.

1. InternalInputMethodContext::setFocusObject(nullptr) should still notify
   enabledChanged (no focus -> disable).
2. InternalInputMethodContext::update(Qt::ImEnabled) should notify
   enableChanged.
3. KWin's QPA may missing setFocusObject(nullptr) when destroy window,
   try to monitor destroyed signal as a last resort.
4. Call refreshActive() again on seat's focused text input surface
   change.
5. inputMethodAccepted should be considered as part of isEnabled
   condition. In Qt, having focus object is not equilvalent to allow input
   method.

The direct root cause to 506095 is caused by 3 & 5. Both 3 & 4 & 5 could fix
it.


(cherry picked from commit 8139550d447c5b4d60ffed5bdbae5542b5313293)

Co-authored-by: Weng Xuetian <wengxt@gmail.com>

M  +6    -3    src/inputmethod.cpp
M  +20   -3    src/internalinputmethodcontext.cpp
M  +3    -0    src/internalinputmethodcontext.h

https://invent.kde.org/plasma/kwin/-/commit/7926c65c663af4cd415c29816a8575f72f6a8720