チャットアプリ内蔵ブラウザや一部のモバイルWebViewを主要ターゲットにするWebアプリでは、window.prompt()・alert()・confirm()などのブラウザネイティブダイアログAPIを主要機能（例: ノード作成時のテキスト入力）に使うと、その環境ではダイアログ自体が抑制され（表示されない・JS実行がブロックされるなど）、ユーザーに何のエラーも見せずに機能が並発する。実機の内蔵ブラウザで初めて発見されやすく、デスクトップChromeでの検証だけでは見つからない。

適用条件: 主要ターゲット環境が自社で完全に制御できない埋め込みブラウザ（チャットアプリ内蔵・SNSアプリ内蔵・LINEブラウザ等）である場合に重要。自社ネイティブアプリのWebViewや、通常のデスクトップブラウザ向けなら優先度は低い。

対処方法: テキスト入力などの入力取得は、promptではなくページ内のinline編集UI（contentEditable相当なinput/textareaをその場で表示しblur/Enterで確定）に置き換える。確認ダイアログ（confirm相当）も同様に、ページ内のモーダル・ツールバーの確認ボタンに置き換える。

確認方法: 実際の主要ターゲットブラウザ（実機または同等のWebView）で当該機能を実行し、ダイアログが表示されるかを確認する。自動テストではPlaywrightのpage.on('dialog', ...)で自動応答するテストはデスクトップChromium上のテストでしかなく、埋め込みWebViewの抑制挙動を再現しないので、「テストがPASSする」だけでは本番環境での動作を保証しないことに注意。

教訓: 「Web標準APIなのでどこでも動くはず」という直感は、ポリシーでブロックされうるブラウザネイティブダイアログ系 API（prompt/alert/confirm）では成り立たない。主要ターゲットが自社で制御できない埋め込みWebViewなら、設計段階でこれらのAPIを候補から外す。