Clipboard copy in code-server on iPad is unreliable with dragged/keyboard selections

Comece reproduzindo as etapas de seleção por arraste, cópia e colagem no code-server no iPadOS nos navegadores listados, comparando seleções do fim para o início e do início para o fim com controles de clique duplo e triplo. Rastreie o caminho da área de transferência do navegador usado pelo VS Code web editor; considera-se concluído quando seleções arbitrárias chegam de forma confiável à área de transferência do iPad, preservam as quebras de linha e não se tornam URL-encoded.

Is there an existing issue for this?

• I have searched the existing issues

OS/Web Information

• iPadOS: 26.0.1
• code-server: 4.105.1 (811ec6c1d60add2eb92446161ca812828fdbaa7f)
• VS Code (web): 1.105.1
• Browsers on iPad: Safari, Safari PWA (Add to Home Screen), Brave, Chrome
• Access: Tailscale with HTTPS (valid certs; no warnings)
• Host: code-server running in WSL2 on Windows 11 (Ubuntu)

Steps to Reproduce

1. Open code-server in Safari
2. Open a file (I used .py)
3. Select code by dragging with mouse/trackpad from end to beginning
4. Press ⌘C to copy.
5. Press the position you want to paste
6. Press ⌘V to paste.

Note on selection direction: If I select from the beginning to the end of the text, copy tends to work more often, but I then hit separate encoding issues (details below). If I select from the end to the beginning (which is common in real use), copy fails much more frequently. Details and diagnostics are in later sections.

Expected

Copy should reliably place the selected text into the iPad system clipboard, regardless of how the selection was created. Pasting should paste the just selected text.

Actual

The pasted text is often not the selection; it pastes whatever was previously on the clipboard.
Because this is intermittent, try the above a few times if it works once; failures are common but not 100%.

Logs

When selecting text (end to beginning), pressing **⌘C** (fails), and pasting (pasted previously copied text, not the new text):

[18:36:01] File action: writeFile /mnt/c/Users/<user>/<working_directory_path>/temp.py
[18:36:01] [File Watcher (node.js)] [raw] ["change"] temp.py
[18:36:01] [File Watcher (node.js)] [CHANGED] /mnt/c/Users/<user>/<working_directory_path>/temp.py
[18:36:01] [File Watcher (node.js)]  >> ignored (not included) /mnt/c/Users/<user>/<working_directory_path>/temp.py
[18:36:01] [File Watcher (node.js)] [raw] ["change"] temp.py
[18:36:01] [File Watcher (node.js)] [CHANGED] /mnt/c/Users/<user>/<working_directory_path>/temp.py
[18:36:01] [File Watcher (node.js)]  >> ignored (not included) /mnt/c/Users/<user>/<working_directory_path>/temp.py
[18:36:01] [File Watcher ('parcel')] [CHANGED] /mnt/c/Users/<user>/<working_directory_path>/temp.py
[18:36:01] File action: writeFile /home/<user>/.local/share/code-server/User/History/-5a5bb3a7/entries.json
[18:36:01] [File Watcher ('parcel')] [CHANGED] /mnt/c/Users/<user>/<working_directory_path>/temp.py
[18:36:01] [File Watcher ('parcel')]  >> normalized [CHANGED] /mnt/c/Users/<user>/<working_directory_path>/temp.py

Screenshot/Video

https://github.com/user-attachments/assets/defdc0fb-6442-484e-a772-f1914b6b16e7

Does this bug reproduce in native VS Code?

This cannot be tested in native VS Code

Does this bug reproduce in GitHub Codespaces?

I did not test GitHub Codespaces

Are you accessing code-server over a secure context?

• I am using a secure context.

Notes

Additional observations

A) Selection direction vs. encoding artifacts

• Selecting begin → end tends to copy more reliably (always so far), but small selections that include certain punctuation (quotes, commas, colons) can paste as URL‑encoded text.
  • Code line: print("Torch version:", torch.__version__)
  • Example selected: n:", to
  • Pasted: n:%22,%20to
• When selecting larger spans or multiple lines, the URL‑encoding doesn’t appear.
• When pasting multiple lines that were copied during these “encoded” cases, they paste as one line instead of preserving line breaks.

B) Selection method that always works (diagnostic)

• If I select by double-click (word) or triple-click (entire line) and then copy, copy/paste always works and I do not see the encoding issue.
• This is useful as a control, but it’s not how users typically select arbitrary ranges in day-to-day editing.

---

What I’ve tried

Copy mechanisms

• ⌘C / ⌘V (default) → unreliable with drag/Shift+Arrow selections.
• right‑click → Copy → same behavior.

Keybindings

• Custom binding of editor.action.clipboardCopyAction to Ctrl+Shift+C → still unreliable with drag selections.
• Default ⌘C left in place to match typical usage; same results.

Browsers

• Safari, Safari PWA, Brave, Chrome on iPad → identical behavior (expected; all are WebKit).

Selection variants

• End → begin selection → fails more frequently.
• Begin → end selection → succeeds always (in the short time I've tried it), but introduces URL‑encoded paste for short spans containing punctuation.
• Double/triple‑click selection → always succeeds, no encoding issue.
• Multiple lines / larger blocks → encoding issue not observed.

---

Impact

Frequent copy failures and occasional encoding artifacts make normal editing (moving code, refactoring snippets, copying short substrings) unreliable on iPad. The Begin → end selection is a usable workaround for now, and for the encoding issue I can select more text and delete the extra parts, but it does impact my productivity.

On a side note, this is my first issue on a public repository, so feedback on what I could do differently in the future is always welcome :)