In Japanese, Enter confirms the kanji. Your app may treat it as Send.

A user types あした, presses Enter to turn it into 明日 (tomorrow), and your chat sends 明日 on its own before the rest of the sentence exists.

Japanese is typed through an input method editor (IME). You type the sound, pick the kanji, then press Enter to confirm. A keyboard handler that ignores this treats that Enter as send, search, select or save. Browsers report it differently, so a guard that works in Chrome can still fail in Safari. I check how your web app handles Japanese typing and send a patch and a test for each defect I find.

What the check covers

1. Enter that confirms a conversion and also sends, submits, saves or selects. Chat composers, search boxes, comboboxes, tag inputs and inline rename fields are the usual places.
2. Safari's confirm Enter. Its keydown arrives with keyCode 229 and isComposing false, so a guard that only reads isComposing lets it through.
3. Guards that read isComposing from a framework's synthetic event. In React it is undefined there; the value lives on event.nativeEvent.
4. Flags set on compositionstart and cleared on compositionend. Chrome fires the confirm keydown before compositionend, Safari fires it after, so the same flag guards one browser and not the other.
5. Esc that cancels a conversion and also closes the dialog, drawer or menu around it.
6. Search-as-you-type that sends a request or rebuilds the result list on every unconverted keystroke, or moves focus and drops the conversion.
7. Controlled inputs that rewrite the value during composition (trimming, formatting, max length), which breaks the conversion or duplicates characters.
8. Validation and character counters that run on text still being converted: errors that flash mid-word, and limits that cut the conversion off.
9. Chat send settings: Enter to send, Shift+Enter for a new line, Ctrl/Cmd+Enter, and whether each mode respects composition.

What you get

• A report listing each defect: the input, what happens, steps to reproduce with the exact keys, the browser, and how serious it is. Inputs that pass are listed too, so you can see what was tried.
• A patch for each defect, as a diff against your code, or as a pull request if you give me access to the repository. If I can't see the code, you get the guard to drop into the handler and a note on where it goes.
• A regression test for each defect in the setup you already use (Vitest, Jest, Testing Library or Playwright), written so it fails without the patch.
• One round of follow-up questions by email after delivery.

See a sample report. It is built from two fixes of mine that were merged into open-source UI libraries.

How I test

I type with the Microsoft Japanese IME in Chrome, Edge and Firefox on Windows, on your live app or a staging copy. Safari on macOS is covered by reading the handlers and by the tests (item 2 above), not by typing in Safari. If you need Safari tested by hand, tell me before ordering.

What it excludes

• Translation, copy review and other localization work.
• Native mobile apps and phone keyboards (iOS, Android).
• Chinese and Korean IMEs. They raise the same composition events, so most patches carry over, but I only test with Japanese.
• Merging and deploying. You review and ship the patches.
• More than 10 inputs or more than one app. Ask for a quote.

How it works

1. Pay with the button above and enter the app's URL at checkout.
2. Within 1 business day I email you to agree on the inputs and, if they sit behind a login, to ask for a test account.
3. The report, patches and tests arrive by email within 5 business days of getting access.

If I can't reach the inputs (for example, no test account arrives within 10 business days), the payment is refunded in full.

Public fixes, merged upstream

These are open-source projects, not clients. Each fix is the kind of defect this check looks for, and each one was reviewed and merged by the project's maintainers. Fifteen such fixes were merged as of 7 October 2026; eight are listed here.

• payloadcms/payload #17138The admin SearchInput ran its search on the Enter that confirmed a conversion. The guard now reads nativeEvent.isComposing.
• CopilotKit/CopilotKit #5764The Angular chat input submitted mid-composition. Guarded on isComposing and keyCode 229.
• misskey-dev/misskey #17646With "Enter to send" on, the chat sent half-converted text and cleared the box.
• udecode/plate #5048The floating link editor submitted on Safari's confirm Enter, where isComposing is false.
• vuetifyjs/vuetify #22974VAutocomplete swallowed the confirm Enter and, with auto-select-first, picked an item using the unconfirmed search text.
• twentyhq/twenty #22270Renaming an AI chat thread or an attachment saved the half-typed name.
• rsuite/rsuite #4585InputPicker selected the highlighted option on the confirm Enter. Includes a regression test.
• Tencent/tdesign-vue-next #6756Esc that cancelled a candidate also closed the drawer. Includes a regression test.

All merged IME pull requests by mahirhir on GitHub

Questions

We already check isComposing. Is that enough?

Not in Safari, where the confirm Enter arrives with isComposing false and keyCode 229. In React, also check that the guard reads event.nativeEvent.isComposing, not event.isComposing.

Do you need our source code?

Not to find the defects. To send a diff or a pull request against your code, yes: read access to the repository, or to the components involved. Without it you get the guard and a test to adapt.

Can you open the pull request yourself?

Yes, if you add the GitHub user mahirhir to the repository. Otherwise the patches come as diff files.

What if you find nothing?

You get the test matrix: every input, browser and key sequence I tried, with the result. The payment is not refunded in that case.

Who does the work?

Mahiro Hirakawa, a developer who types Japanese every day. I wrote the fixes listed above.

How do I ask something before ordering?

Email mahirohirakawa@glovrex.com.

日本語のEnterは「確定」です。あなたのアプリは「送信」と読んでいないでしょうか。

「あした」と打ってEnterで「明日」に確定した瞬間、チャットが「明日」だけを送ってしまう。日本語を打たないチームには見えにくい不具合です。

原因は、IMEの変換確定に使うEnterを、キーボード処理が送信・検索・選択・保存として扱ってしまうことです。ブラウザごとに確定時のイベントの出し方が違うため、Chromeで直っていてもSafariでは再発することがあります。この診断では、Webアプリ1つの入力欄（最大10か所）を日本語入力で確認し、見つかった不具合ごとに修正パッチとテストをお渡しします。

確認する項目

1. 変換確定のEnterで、送信・保存・選択まで走ってしまう（チャット、検索、コンボボックス、タグ入力、名前の変更欄など）
2. Safariの確定EnterはisComposingがfalse、keyCodeが229で届くため、isComposingだけのガードをすり抜ける
3. Reactなどの合成イベントからisComposingを読んでいる（Reactではevent.nativeEvent側にしかない）
4. compositionstart・compositionendで立てたフラグに頼っている（確定キーとの発火順がChromeとSafariで逆）
5. 候補を取り消すEscで、ダイアログやドロワーまで閉じてしまう
6. インクリメンタル検索が未確定の文字ごとにリクエストを送る、または一覧を作り直して変換が途切れる
7. 入力中に値を書き換える制御コンポーネント（trim、整形、文字数制限）で変換が壊れる、文字が重複する
8. 入力途中の文字にバリデーションや文字数カウンターが反応し、エラーが点滅する、変換が途中で切られる
9. チャットの送信キー設定（Enter送信、Shift+Enter改行、Ctrl/Cmd+Enter）が変換中を考慮しているか

お渡しするもの

• 不具合ごとの報告：対象の入力欄、起きること、キー操作つきの再現手順、ブラウザ、重大度。問題がなかった入力欄も記載します。
• 不具合ごとの修正パッチ：コードに対するdiff、またはリポジトリへのアクセスをいただければプルリクエスト。コードを見られない場合は、ハンドラに入れるガードと入れる場所の説明。
• 不具合ごとの回帰テスト：お使いの環境（Vitest、Jest、Testing Library、Playwright）で、パッチがないと失敗するもの。
• 納品後、メールでの質問に1往復お答えします。

報告書は英語が基本です。日本語版が必要な場合はお申し付けください。サンプルレポートは、オープンソースのUIライブラリにマージされた自分の修正2件から作っています。

確認の方法と範囲

Windows上のChrome・Edge・FirefoxでMicrosoft IMEを使い、実際に打って確認します。macOSのSafariはハンドラのコードとテストで確認し、実機では打ちません。Safariでの実機確認が必要な場合は、申し込み前にご相談ください。

含まれないもの：翻訳や文言の確認、ネイティブのスマホアプリとスマホのキーボード、中国語・韓国語IMEでの確認、パッチのマージとデプロイ、11か所以上の入力欄や2つ目のアプリ（別途お見積り）。

流れ

1. 上のボタンからお支払い、決済画面でアプリのURLを入力。
2. 1営業日以内に、対象の入力欄の確認と、ログインが必要な場合はテスト用アカウントのお願いをメールでお送りします。
3. アクセスできるようになってから5営業日以内に、報告・パッチ・テストをメールで納品します。

入力欄にアクセスできない場合（10営業日以内にテスト用アカウントが届かない等）は全額返金します。不具合が見つからなかった場合は、確認した入力欄・ブラウザ・キー操作の一覧をお渡しし、返金はいたしません。ご質問：mahirohirakawa@glovrex.com

特定商取引法に基づく表記