重要な送信操作を拡張機能から補助するとき、送信元の通信を理解せずクリックだけを自動化すると、意図しない登録や二重送信につながります。調査、確認、結果の記録を段階に分けます。
最初に通信を送らず挙動を調べる
調査用コードでfetch、XHR、sendBeacon、WebSocket、フォーム送信などを観測し、操作順と送信内容の関係を整理します。外部へ送信しないことを確かめるには、DevToolsのOffline状態などを使い、隔離した検証環境で試します。リクエスト本文やCSRF値をログや共有資料へ出さないでください。ページの通信関数を差し替えると正常動作しなくなる場合があります。検証後はタブを閉じてから通常接続へ戻します。
捕捉フェーズで確認を挟む
ページ読み込みの早い段階でcapture listenerを登録し、対象の送信クリックに対してpreventDefaultとstopImmediatePropagationを使い、元のハンドラーへ到達する前に確認画面を出します。Shadow DOMのパネルなど、ページUIと区別できる表示を用意します。
利用者が続行を選んだ場合だけ、一回限りの許可フラグを立て、元のボタンを再クリックします。再クリックを一度だけ通す仕組みにすると二重実行を管理しやすくなります。ページ遷移後の再注入では、古いリスナーが残らないよう登録済み状態を管理します。
ネイティブconfirmは狭く扱う
同期的なwindow.confirmの結果を後から検出する方式では、ダイアログ表示中にイベントループが止まり、利用者がOKを押した後に予約済み処理が再開する挙動を利用できます。タイマー後にページがpagehideになったかなどを記録する方法は、特定の同期confirmと画面遷移に対する補助的な手掛かりです。非同期モーダルや独自確認UIには適用できません。
検出結果からさらに送信処理を自動実行せず、記録や状態表示に留めます。キャンセル、通信失敗、画面遷移の違いを実ブラウザーで確認します。
まとめ
送信を安全に補助するには、まず通信を理解し、次に明示的な確認を挟み、結果検出は限定的な補助として使います。送信抑止と再クリックには二重実行防止と手動復旧手段を用意しましょう。