The behavior of IntelliJ IDEA’s Switcher is abnormal

[atty303]

Please fill out the following:

• Scroll Version: 1.13-dev
• Debug Log: https://gist.github.com/atty303/cefc48fccbff70f2e80edf3e4f0550c5
• Configuration File:

exec uwsm finalize SWAYSOCK I3SOCK SCROLLSOCK XCURSOR_SIZE XCURSOR_THEME
exec uwsm app -- ghostty

• Description:
  The expected normal behavior is as follows. This was recorded on KDE Plasma.

1. Press Ctrl
2. Press and release Tab -> the Switcher opens
3. Press and release Tab -> the selection inside the Switcher changes
4. Release Ctrl -> the Switcher closes

_20260404_084907.webm

The behavior on scroll is as follows.

1. Press Ctrl
2. Press and release Tab -> the Switcher opens briefly and immediately closes
3. Press and release Tab -> the Switcher opens
4. Release Ctrl -> the Switcher remains open and does not close
5. Press and release Ctrl -> the Switcher closes

Immediately after launching IDEA, the behavior is normal. However, after focusing another window and then returning focus to IDEA, launching the Switcher reproduces the issue every time.

2026-04-04.09-26-35.mp4

I confirmed the following log in IDEA when the Switcher opens.

2026-04-04 10:28:24,340 [   8290] SEVERE - #c.i.i.p.PluginManager - wl_keyboard_keymap supplied unknown keymap format
java.lang.InternalError: wl_keyboard_keymap supplied unknown keymap format
	at java.desktop/sun.awt.wl.WLToolkit.dispatchEventsOnEDT(Native Method)
	at java.desktop/sun.awt.wl.WLToolkit.lambda$run$0(WLToolkit.java:319)
	at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:323)
	at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:732)
	at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:711)
	at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.kt:720)
	at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.kt:573)
	at com.intellij.ide.IdeEventQueue.dispatchEvent$lambda$0$0$0$0(IdeEventQueue.kt:381)
	at com.intellij.openapi.progress.impl.CoreProgressManager.computePrioritized(CoreProgressManager.java:928)
	at com.intellij.ide.IdeEventQueue.dispatchEvent$lambda$0$0$0(IdeEventQueue.kt:380)
	at com.intellij.ide.IdeEventQueueKt.performActivity$lambda$0(IdeEventQueue.kt:1110)
	at com.intellij.openapi.application.TransactionGuardImpl.performActivity(TransactionGuardImpl.java:106)
	at com.intellij.ide.IdeEventQueueKt.performActivity(IdeEventQueue.kt:1110)
	at com.intellij.ide.IdeEventQueue.dispatchEvent$lambda$0(IdeEventQueue.kt:375)
	at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.kt:415)
	at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:207)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:128)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:117)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:113)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:105)
	at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:92)

When running IDEA with WAYLAND_DEBUG=1, the following output appeared immediately before the exception.

[2695189.094] {Default Queue} wl_keyboard#8.keymap(0, fd 622, 0)
[2695189.123] {Default Queue} wl_keyboard#8.repeat_info(30, 300)
[2695189.127] {Default Queue} wl_keyboard#8.modifiers(4404, 0, 0, 0, 0)

At least it seems certain that the keymap format sent from scroll is 0 (no_keymap), and IDEA cannot interpret it, resulting in the exception. However, I am not sure whether this actually affects the Switcher behavior. For now, I would like to find a way to avoid sending no_keymap and observe whether the behavior changes.

It seems that IDEA currently officially supports only KDE/GNOME, and if I report an issue for another compositor, there is a high chance it will be ignored. I realize this may not be a problem in scroll, and could instead be on the IDEA side or in my environment, so I feel a bit apologetic, but I would really appreciate any advice on how to resolve this somehow.

~/.config/scroll/debug

exec uwsm finalize SWAYSOCK I3SOCK SCROLLSOCK XCURSOR_SIZE XCURSOR_THEME
exec uwsm app -- ghostty

/usr/local/share/wayland-sessions/scroll-debug.desktop

[Desktop Entry]
Name=scroll (debug)
Comment=A scrollable-tiling Wayland compositor
GenericName=Wayland Compositor
Exec=uwsm start -N scroll-debug -D scroll -C scroll -- /home/atty/.local/bin/scroll-debug
TryExec=uwsm
Type=Application

~/.local/bin/scroll-debug

#!/bin/bash
scroll -d -c /home/atty/.config/scroll/debug 2> /home/atty/scroll.log

I am running scroll inside an Arch container on Bazzite (Immutable Fedora). Other than IDEA, everything seems to work fine, but it is possible that the fact it is running in a container is part of the cause.

[dawsers]

Thank you for the detailed bug report. Are you sure you are running IDEA on Wayland? The debug log has lots of references to X11. You can verify this by running scrollmsg -t get_tree and checking whether the IDEA window is of type xdg_shell (Wayland) or xwayland (X11).

If you are running under X, you should try moving to Wayland. As explained in #218, there are lots of bugs in the Jetbrains issue tracker related to XWayland and their migration to Wayland.

I recommend trying to run IDEA in Wayland mode and seeing what happens, mainly because GNOME and KDE apparently don't support X any more, so Intellij will have to fix all the Wayland problems.

(add -Dawt.toolkit.name=WLToolkit to Help | Edit custom VM options and restart IDE)

Edit: There is also a problem with another Java/X11 application, Bitwig Studio and submenus (#244) which could be related. It was fixed in a newer version of Bitwig, but Bitwig doesn't have an option to run in Wayland mode. If I were you, I would first try to run IDEA in Wayland mode. If there is a bug there, I may be able to fix it, bugs on X11 are harder to fix, because we depend on wlroots and xwayland.

[dawsers]

Also, what version of IDEA are you using?

I cannot test Intellij IDEA, because it is a paid application, but I downloaded and installed the latest Pycharm Community Edition (2026.1), arch package pycharm-community-jre. By default it runs in Wayland mode, and I don't have that issue:

pycharm.mp4

[atty303]

Thank you for the reply. I am using IntelliJ IDEA 2026.1 Ultimate Edition, and Wayland became the default starting with this version. I also confirmed in About that WLToolkit is being used. Conversely, this problem does not occur when I launch IDEA with XToolkit/XWayland, so I believe this is a Wayland-specific issue.

I also tried launching PyCharm, which I do not normally use, with its default settings, and the issue reproduces there as well. Since the Wayland-related implementation is done in JetBrains Runtime (JRE), I assume the type of IDE should not matter as long as the JBR version is the same. If you cannot reproduce it on your side, does that mean some setting outside of scroll, such as XKB configuration on the host OS, could be affecting it?

For reference, IntelliJ IDEA provides its core functionality, including Java support, for free, and requires payment only if you want to use the additional Ultimate features. In the past, it was split into the free Community Edition and the paid Ultimate Edition, but it has now been unified.

#14: con "The behavior of IntelliJ IDEA’s Switcher is abnormal · Issue #247 · dawsers/scroll — Zen Browser" (xdg_shell, pid: 8926, app_id: "app.zen_browser.zen", foreign_toplevel_id: "be6a209425392573a8e0334e4ca198ef", sandbox_engine: "org.flatpak", sandbox_app_id: "app.zen_browser.zen", sandbox_instance_id: "3414290147")
#60: con "bazzite-atty – config.toml" (xdg_shell, pid: 1575648, app_id: "jetbrains-pycharm", foreign_toplevel_id: "af537136bb2da604598cbc15a8bfc0b5")
#12: con "~> scrollmsg" (xdg_shell, pid: 7124, app_id: "com.mitchellh.ghostty", foreign_toplevel_id: "33c9d7a53d215b71758e00faa98c5884")
#54: floating_con "Toolbox" (xwayland, pid: 4085, instance: "JetBrains Toolbox", class: "jetbrains-toolbox", X11 window: 0x600007, foreign_toplevel_id: "92eb485231f8e81d6911f6e5d39f9e66")

IDE's about

IntelliJ IDEA 2026.1
Build #IU-261.22158.277, built on March 25, 2026
Source revision: 89c647576f1d2
Licensed to Koji Agawa
Subscription is active until November 23, 2026.
Runtime version: 25.0.2+10-b329.72 amd64137.0.17-261-b65
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Toolkit: sun.awt.wl.WLToolkit
Linux 6.17.7-ba29.fc43.x86_64
Bazzite; glibc: 2.42
Exception reporter ID: 28122533cfdf9a5-ba1c-4c3d-8911-a1aa81b278d4
GC: G1 Young Generation, G1 Concurrent GC, G1 Old Generation
Memory: 2048M
Cores: 32
Vulkan Rendering is ON:
Presentation is ON
AMD Radeon RX 9070 XT (RADV GFX1201) (DISCRETE_GPU), caps=0xc0000006
AMD Ryzen 9 9950X3D 16-Core Processor (RADV RAPHAEL_MENDOCINO) (INTEGRATED_GPU), caps=0xc0000006
llvmpipe (LLVM 21.1.8, 256 bits) (CPU), caps=0xc0000006
Registry:
ide.experimental.ui=true
trace.state.event.service.url=https://api.jetbrains.cloud/trace-status
llm.chat.agent.codex.install.codex.version=0.98.0
llm.chat.agent.codex.install.acp.server.version=0.0.23
Non-Bundled Plugins:
org.jetbrains.junie (261.1218.79)
intellij.jupyter (261.22158.354)
org.jetbrains.plugins.go (261.22158.277)
com.jetbrains.webstorm.web-assembly-plugin (261.22158.185)
org.jetbrains.plugins.go-template (261.22158.185)
com.intellij.ml.llm (261.22158.366)
com.intellij.lang.jsgraphql (261.22158.185)
org.intellij.plugins.hcl (261.22158.185)
net.sjrx.intellij.plugins.systemdunitfiles (242.260401.677)
co.anbora.labs.nushell.community (1.3.3)
com.wakatime.intellij.plugin (16.0.0)
org.mvnsearch.plugins.justPlugin (0.6.36)
dev.kdl (2.2.0)
com.intellij.plugin.adernov.powershell (2.11.0)
mobi.hsz.idea.gitignore (4.5.7)
com.redhat.devtools.lsp4ij (0.19.2)
com.github.bric3.excalidraw (0.4.2)
com.chylex.intellij.inspectionlens (1.6.1)
Docker (261.22158.299)
PythonCore (261.22158.277)
org.jetbrains.plugins.workspace (261.22158.182)
org.intellij.scala (2026.1.16)
com.intellij.nativeDebug (261.22158.180)
com.jetbrains.rust (261.22158.311)
deno (261.22158.185)
org.jetbrains.plugins.remote-run (261.22158.354)
com.jetbrains.plugins.webDeployment (261.22158.299)
com.github.l34130.mise (5.17.0)
com.haulmont.rcb (261.22158.185)
org.jetbrains.android (261.22158.277)
izhangzhihao.rainbow.brackets (2025.3.8)
com.datadog.intellij (1.10.16)
Kotlin: 261.22158.277-IJ
Current Desktop: scroll

PyCharm 2026.1
Build #PY-261.22158.340, built on March 30, 2026
Source revision: 9a4acde0aae49
Licensed to Koji Agawa
Subscription is active until November 23, 2026.
Runtime version: 25.0.2+10-b329.72 amd64137.0.17-261-b65
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Toolkit: sun.awt.wl.WLToolkit
Linux 6.17.7-ba29.fc43.x86_64
Bazzite; glibc: 2.42
Exception reporter ID: 28122533cfdf9a5-ba1c-4c3d-8911-a1aa81b278d4
GC: G1 Young Generation, G1 Concurrent GC, G1 Old Generation
Memory: 2048M
Cores: 32
Registry:
ide.experimental.ui=true
Current Desktop: scroll

[dawsers]

Yes, IDEA and Pycharm should behave in exactly the same way if both are using the Jetbrains-provided JRE, and you and I both are using it.

Now that we know it is not an XWayland issue, and it works for me, I would like to know more about your setup, to see if I can infer some misconfiguration of scroll or the container you are running.

I am running scroll inside an Arch container on Bazzite (Immutable Fedora). Other than IDEA, everything seems to work fine, but it is possible that the fact it is running in a container is part of the cause.

By this, I understand you run scroll inside a podman or docker container inside Fedora. Is there another compositor running inside Fedora (as host for your GUI)? If that is the case, scroll would be a "nested" compositor. A nested compositor uses the host to resolve some of the Wayland messages. For example, if your host compositor had some key bindings assigned that overlap with those of the nested compositor, there could be trouble. Running a nested compositor is usually not recommended except for debugging. I run it all the time to debug issues, but my host is also scroll, and host and nested use a different modifier key so keybindings don't overlap.

If you are running scroll as the host compositor, and your containers only run the applications, then there shouldn't be any issues as long as you import the right environment variables into your container. But if the compositor is running in the container, and it is nested, there could be lots of unexpected issues with keyboard and rendering.

So please, let me know in more detail how your system is configured, what compositor you are running as GUI in Fedora, what container framework you use, how the container is configured, and your scroll configuration (the config file). Please, also verify that the key bindings you use (even the Ctrl+tab) don't do anything in the host compositor.

Edit: An easy way to see if your scroll configuration is good and not having to modify your host if scroll is not your main compositor, would be to create a virtual machine and run scroll in it. That way the compositor is not nested and is the one handling the whole Wayland protocol. That is what I use to debug issues when they are related to rendering or the keyboard, so I don't mix things with the host. I have a GPU passed through to the guest and can debug there.

[atty303]

I think it's very likely that there may be an issue with my scroll container setup. I hadn't been considering debugging in a VM, so from here I plan to check reproducibility with scroll on a VM that is not running in a container. Judging from the situation, I suspect the issue probably will not reproduce in the VM, so I think I may be able to move toward a solution by identifying the differences from the container setup.

I am aware that my container setup is unusual and not something with many examples, and I also understand that installing scroll on the host with rpm-ostree would be the safer option. Still, I want to proceed with this configuration because containerizing the compositor would let me update and switch it without depending on the host.

To clarify first, there is no compositor on the host side; I am running scroll as the root compositor. That scroll itself is running inside Distrobox (podman).

https://github.com/atty303/distrobox-image/blob/95982884953e98f02fb9dfaf5f65f5e5c9d38fc5/arch-toolbox-paru/Containerfile
https://github.com/atty303/distrobox-image/blob/95982884953e98f02fb9dfaf5f65f5e5c9d38fc5/arch-scroll/Containerfile

distrobox-assemble.ini

[scroll]
image=ghcr.io/atty303/arch-scroll
pull=true
# Need this to work with logind
volume=/run/dbus/system_bus_socket:/run/dbus/system_bus_socket
volume=/run/user/1000/X11-unix:/tmp/.X11-unix
# https://github.com/89luca89/distrobox/issues/1961
additional_flags="--userns keep-id:size=65534 --annotation run.oci.keep_original_groups=0"
exported_bins="/usr/bin/scroll /usr/bin/scrollmsg /usr/bin/scrollnag /usr/bin/scrollbar"
# Make some host binaries executable from the container
init_hooks=ln -sf /usr/bin/host-exec /usr/local/bin/uwsm;
start_now=true

Because of Distrobox, almost the entire host environment except for /usr is brought into the container, and on top of that I have added support for the system D-Bus and udev hotplug. As I wrote at the beginning of the issue, the scroll configuration and startup method are exactly as described there: I launch the scroll binary exported by distrobox from SDDM on the host. Only the compositor runs inside the container, while environment variables such as WAYLAND_DISPLAY are written by uwsm into the host's systemd environment, and Wayland clients such as Flatpak apps and IDEs on the host side are launched against that.

I will proceed with verification and debugging in the VM first. Thank you for the advice!

[atty303]

I was able to reproduce the issue on a completely clean Arch VM, and it turned out that fcitx5 was the cause.

First, here is a configuration where the issue does NOT occur:

1. Start from the basic image at https://gitlab.archlinux.org/archlinux/arch-boxes/
2. Install base-devel and paru
3. Run paru -S sway-scroll jetbrains-toolbox kitty
4. Launch scroll from TTY (leave the configuration as default)
5. Start JetBrains Toolbox and install PyCharm
6. Open any directory as a project in PyCharm and view any file
7. Check Ctrl-Tab behavior → no issue

Next, install and start fcitx5:

1. Install with paru -S fcitx5 and start it with fcitx5 (no additional configuration)
2. Check Ctrl-Tab behavior → issue reproduces
3. Quit fcitx5 while PyCharm is still running → issue no longer reproduces
4. Start fcitx5 again while PyCharm is still running → issue reproduces

(*) If only the “Welcome to PyCharm” screen is shown without opening a project, pressing Ctrl-Tab does not trigger the issue. Opening a file in a project is also a necessary condition.

In other words, reproducibility depends solely on whether fcitx5 is running. I always run fcitx5 for Japanese input, and this turned out to be the cause. When fcitx5 is running, scroll logs show “adding virtual keyboard,” and I suspect that this virtual keyboard uses keymap format 0, which leads to the IDE reporting “unknown keymap format.”

I expect that you can reproduce this on your side as well if you start fcitx5—does it happen for you?

[dawsers]

I can reproduce it with fcitx5 installed. Does fcitx5 work well with other applications?

There are many issues with fcitx5 and Jetbrains IDEs. They have just added support for text-input-unstable-v3, and there are still issues.

https://youtrack.jetbrains.com/issues?q=fcitx5

https://youtrack.jetbrains.com/issue/JBR-5672/Wayland-support-input-methods-text-input-unstable-v3

https://youtrack.jetbrains.com/issue/IJPL-232793/Wayland-text-input-unstable-v3-preedit-text-lacks-highlighting

https://youtrack.jetbrains.com/issue/PY-85600/Regarding-the-issue-of-the-input-method-not-working-properly-in-the-Arch-Linux-PyCharm

https://youtrack.jetbrains.com/issue/JBR-9926/Wayland-WLToolkit-Input-method-disabled-in-second-project-of-Pycharm

https://youtrack.jetbrains.com/issue/JBR-9767/text-input-v3-not-work-in-commit-window

https://youtrack.jetbrains.com/issue/IJPL-164667/Cannot-use-fcitx5-inside

https://youtrack.jetbrains.com/issue/JBR-9845/Wayland-ShiftShift-shortcut-does-not-work

https://youtrack.jetbrains.com/issue/JBR-3206/Native-Wayland-support

If disabling fcitx5 works, fcitx5 works well with other applications, and seeing there are still many problems with Jetbrains IDEs and Wayland input, I am inclined to think the bug is in the interaction between fcitx5 and the Jetbrains IDE. It is not a scroll specific issue, as there are also problems in sway and other compositors.

It would be hard for me to help you further, because I don't use fcitx5. I installed it to test, but there are a myriad of configuration options that I don't understand, because I don't use any modules. I simply followed the Arch Wiki

https://wiki.archlinux.org/title/Fcitx5

and set up all the environment variables I thought were appropriate, and tried to see if that fixed the issue, but it didn't.

[atty303]

Adding -Dsun.awt.wl.im.enabled=false to the IDE VM options to disable IME also stopped the issue from reproducing. Since this allows me to disable fcitx5 only for the IDE, it has become a practical workaround for now.

My current understanding is that the key factor here is the text-input-unstable-v3 protocol, and the components directly involved are the IME side (fcitx5) and the receiving side (the IDE), while the compositor mostly just relays between them and is probably not deeply involved. That said, there have been reports of problems in Hyprland and Niri implementations as well, so I do not think we can completely rule out issues in scroll or sway either. Still, I plan to continue debugging with a focus on this protocol first. Since JetBrains also seems to be actively investigating IME-related issues, there is reason to hope that a report about this might get noticed.

Finally, I want to say that I was only able to narrow the problem down this far thanks to your help. I am sorry for taking up your time on an issue that turned out not to be directly related to scroll itself, but your help was extremely valuable. I have recently tried scroll, niri, and hyprland, and scroll is the only one that really fits me, so I definitely want to keep using it. Thank you for such a great project!

[dawsers]

Thank you, and I am sorry I couldn't be of more help. I have no need for more than very simple keyboard input, using two layouts, but always with Latin alphabet, so I don't have much experience in that front.

I am glad you are using scroll and like it. If you have suggestions or insights on how to improve it, please, do not hesitate to open new topics in Discussions or Issues. I always welcome thorough comments or suggestions. Having more users with different needs always enriches the project.

[atty303]

I am reopening this because the later investigation isolated a compositor-side cause in the text-input/input-method relay shared by Scroll and Sway. My earlier conclusion that the compositor was probably not deeply involved was incorrect.

The no_keymap event reported above is a real, independently observable event, but controlled experiments showed that removing it does not fix the Switcher behavior. It is not causal for this issue.

The investigation isolated two distinct defects in the same shared text-input relay, and both affected the behavior reported here. When a client creates a zwp_text_input_v3 object after its surface already has keyboard focus, the new object does not receive enter until another focus change. In IDEA, this can leave the input method inactive on the initial focus, so the first Ctrl+Tab appears to work because no input-method keyboard grab exists yet. After a focus round trip activates the text input, the grab-lifetime defect is exposed and subsequent Ctrl+Tab attempts fail consistently. This explains the original observation that the Switcher initially worked and became broken after focusing away from IDEA and back.

Fixing that initial-focus defect makes the input method active from the correct time, but does not by itself fix the Switcher: without the grab-lifetime fix, it instead makes the Ctrl+Tab failure reproducible immediately. The two fixes therefore address separate defects that interacted in the observed state transition.

The actual Switcher failure occurs while physical Ctrl is still held. IDEA's JetBrains Runtime (JBR) disables IDEA's persistent text-input object and enables a temporary text-input object for the Ctrl+Tab Switcher. Scroll/Sway immediately deactivates the input method between those requests. fcitx5 then destroys its keyboard grab and emits a virtual Ctrl release even though physical Ctrl remains held. Normally, releasing Tab while continuing to hold Ctrl keeps the Switcher open; this unexpected Ctrl release makes IDEA close it immediately. A replacement grab is then initialized with Ctrl depressed but without a corresponding new press.

The same JBR text-input lifecycle works repeatedly under a nested KWin control. KWin keeps Ctrl press, Tab press/release, and Ctrl release as one coherent stream without the intermediate synthetic Ctrl release.

The initial-focus fix synchronizes a newly created text-input object with the seat's current keyboard-focused surface through the existing relay focus path. The grab-lifetime fix tracks only (keyboard, keycode) presses actually forwarded to the current input-method keyboard grab and defers input-method deactivation while those keys remain held. A replacement text-input enable cancels the deferred transition and retains the grab. If there is a genuine transition to a client with no text input, the last release is sent to the old grab first and deactivation is completed afterward.

The two canonical upstream submissions are:

• text_input: focus text inputs created after keyboard focus swaywm/sway#9255 — focus text-input objects created after keyboard focus
• text_input: defer IM deactivation until forwarded keys are released swaywm/sway#9256 — defer input-method deactivation until forwarded keys are released

I also applied both patches to current Scroll master with its vendored wlroots and tested them directly. With fcitx5/Mozc and PersistentVirtualKeyboard=False, repeated IDEA Ctrl+Tab switching works. I also tested the genuine-zero branch by holding Ctrl, focusing a minimal client that never binds text-input, and releasing Ctrl there. The release reached the old grab before deactivation, the fcitx5 virtual keyboard disappeared afterward, and input resumed correctly after returning to IDEA.

The original symptom and additional client-side protocol traces were also reported to JetBrains:

• https://youtrack.jetbrains.com/issue/JBR-10221/Wayland-text-input-unstable-v3-fcitx5-Ctrl-release-event-is-lost-during-Ctrl-Tab-Switcher-after-text-input-disable-enable

I use Scroll as my daily compositor, and I do not know how long the Sway review and merge process may take. If you are comfortable with the approach, I would really appreciate it if Scroll could pick these patches while the Sway PRs are unresolved. If Sway later adopts different implementations, I can align the Scroll patches with them.

This investigation and implementation were performed with assistance from OpenAI Codex. I supervised the work throughout, reviewed and understand the resulting code and reasoning, and personally validated the behavior in the real environments described above.

[dawsers]

Thank you for taking the time to do this. I think I am more comfortable at least waiting to see what sway says about this matter. I made some changes to key binding handling, but this is a much bigger change that would create an important divergence from sway on how he handle a general protocol. Let's wait at least until they give some input, and then we can decide whether to merge those changes here or not.