Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[iOS] Soft keyboard: first letter of every Pinyin (IME) composition is sent to the remote while still composing

オープン 初心者向け
  • 何か問題がありますか？
#16,632 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
74/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
dart, flutter, ios
領域
mobile

調査の方向性

flutter/lib/mobile/pages/remote_page.dart の _handleIOSSoftKeyboardInput から始めて、inputChar() が入力を送信する前に、変換中のテキストがどのように処理されるかを追ってください。issue の nihao の並びを手がかりに、最初のキー入力時と部分確定時の動作を確認してください。変換中のテキストがローカルにとどまり、確定済みのテキストだけが送信されれば完了です。payload にはテストファイル名を含めません。

索引モデルが issue の本文から書いたものです。

説明

Bug Description

Keyboard mode: N/A (mobile soft keyboard, no mode switch on mobile).

When typing Chinese with the iOS system Pinyin keyboard in the iOS client, the first letter of every new composition is sent to the remote host immediately, while it is still marked (composing) text on the phone. The rest of the composition is held back correctly. English input with the iOS English keyboard is not affected.

When a candidate is committed, the client sends VK_BACK to remove the leaked letter and then sends the committed characters. So in the simplest case the final text is right, but the host sees a stray letter for every word, and anything on the host that reacts to that letter (autocomplete popups, shortcuts, terminal apps, a host-side IME) gets out of sync with the follow-up backspace. In practice this shows up as garbled or dropped characters when typing Chinese.

Root cause — flutter/lib/mobile/pages/remote_page.dart, _handleIOSSoftKeyboardInput (line 257 at tag 1.4.5, line 351 on master as of 2026-10-20):

if (_textController.value.isComposingRangeValid) {
  final composingLength = _textController.value.composing.end -
      _textController.value.composing.start;
  if (composingLength > newStr.length) {
    _value = oldValue;
    return;
  }
}

On the first keystroke of a composition the composing range is exactly the new string (composingLength == newStr.length == 1), so 1 > 1 is false and the letter falls through to inputChar().

Trace for typing nihao and picking 你好:

keystroke composing text guard sent to host
n n 1 > 1 → false n
i ni 2 > 1 → true nothing
h, a, o nihao true nothing
pick 你好 (none) not composing VK_BACK, then 你好

From reading the code (not verified separately on device), the same guard also leaks on a partial commit: committing 你 while hao is still composing gives newStr = "你hao" (length 4) vs composingLength = 3, so 你hao is sent and corrected later with three VK_BACKs.

How to Reproduce
  1. Connect from the iOS client to a Linux host (X11).
  2. Focus a text field on the host and open the soft keyboard.
  3. Switch the iPhone keyboard to Chinese (Simplified) Pinyin and type n.
  4. The letter n shows up on the host right away, although it is still underlined (composing) on the phone. Typing more letters sends nothing until a candidate is picked.
Expected Behavior

Nothing should be sent while the text is composing; only committed text should be sent. On a partial commit, only the committed part (the text before composing.start) should be sent.

Operating system(s) on local (controlling) side and remote (controlled) side

iOS -> Ubuntu 22.04 (GNOME on X11, IBus)

RustDesk Version(s) on local (controlling) side and remote (controlled) side

iOS app (App Store) -> 1.4.5; the code above is unchanged on master

Screenshots

N/A - code-level analysis; the table above shows the event sequence.

Additional Context

Suggested fix direction: changing > to >= would stop the first-letter leak but not the partial-commit case. A more complete fix is to diff only the committed part of the text: when isComposingRangeValid, use text.substring(0, composing.start) as the new value and never send the composing part.

Related: #16527 (single committed CJK characters go through the raw key path). That is a different root cause, and its proposal keeps the composing guards unchanged, so it does not cover this one.

Host side ruled out: on the Linux X11 host, English and Chinese text injected with xdotool (the same libxdo calls key_sequence / key_click use) arrives intact with and without IBus, so the problem is on the client side.

主要言語
Rust
スター
126k
フォーク
19.7k
平均マージ
1日 14時間
マージ済み PR（30日）
74

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

rustdesk/rustdesk のほかの issue

rustdesk/rustdesk の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。