テキストボックスでのスクロールは、ページのスクロールにオーバーフローする必要がありますか？
ブラウザのテキストボックスにテキストの長いセクションを入力する場合（Gmailやこのようなサイトを使用する場合など）、そのテキストボックス内をスクロールすることができます。
ただし、テキストボックスの極端な部分に到達すると、テキストボックスのスクロールの動作は、ユーザーが直接入力しなくても変化します。テキストボックス内でのスクロールからへのスクロールから、ページのスクロールへと変化します。その結果、ブラウザで画面の上部または下部にスクロールするのと同じように、ブラウザでテキストボックスの上部または下部にすばやくスクロールすることができません。
これは、私が作成した textbox scroll overflow の記録で確認できます。
UXに関してはこれは貧弱であると私は思いますが、ブラウザに広く適用されているようです。その背後にある理由は何ですか、そしてこの行動を裏付ける研究はありますか？
私はこれを裏付ける研究を見つけることができなかったので、誰かが私が主張しようとしていることを証明または反証する何かを知っているなら、コメントを追加してください。
この動作に関する私の仮定は、スクロールのルールは階層的であり、ブラウザーにはブラウザーからスクロールメッセージを受信する「レスポンダー」のチェーンがあることです。ブラウザーがスクロールすると、イベントはユーザーのフォーカスによって定義されたスクロールチェーンにメッセージが送られ、DOMを介して外側に進みます。
この例では、最初のレスポンダはテキストボックスです。スクロールメッセージを受信すると、スクロール位置を確認し、それに応じてインクリメント/デクリメントします。 max/minに達していない限り、最終的にそのスクロールメッセージがブラウザウィンドウのスクロールバーに受信されるまで、親のスクロール可能なオブジェクトにスクロールメッセージが渡されます。
（質問で明らかなように）その欠点にもかかわらず、最初のコンテナの「外」へのスクロールを許可することは、フォーカスされた要素内でのみスクロールするという代替策よりも優れています。
[〜＃〜]理由[〜＃〜]これは実際に優れたUXです。これは、平均的なユーザーがスクロールの暗黙的な階層を理解できず、テキストボックスで「トラップ」される可能性があることです。
唯一の方法は、要素をクリックまたはタブでタブを外してテキストボックスのフォーカスを外すことです。これは簡単に見つけることができず、要素のフォーカスを外すとページ全体のスクロールが可能になることを示すためにどのアフォーダンスを与えることができるかわかりません。
スクロールの階層は、問題がありますが、ユーザーを制限しません。ブラウザーは、ユーザーのスクロールをメタレベルから適切なUXに延期することを「上司だ」というアプローチを取っています。
編集して追加：ただし、CTRL +スクロールまたはその他のキーボードコードを使用できるようにすると、パワーユーザーがフォーカスされた要素にスクロールを制限できます（コードはスクロールメッセージを要素にフォーカスし、要素のスクロール位置が最大/最小の場合にメッセージがツリーから押し上げられるのを防ぎます）。
はいといいえ。テキストボックスはスクロールしないでください。現在のコンテンツに応じて拡大します。テキストボックス+他のコンテンツがブラウザウィンドウの高さよりもさらに拡大すると、スクロールバーが右側に表示されます。
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
編集する
テキストボックス内のスクロールが唯一のオプションである固定リッチテキスト編集フィールドなどの技術的な制限がある場合、動作は状況依存である必要があります。テキストボックス内でスクロールしている場合-最後に到達した場合、別のコンテキスト（ページ全体）でスクロールを続けないでください。
これは、テキストボックスの代わりにページを下にスクロールするコントロール全体を失うのではなく、慎重にスクロールする必要があるユーザーに認知的負荷をもたらします。この動作の問題は、ユーザーはコントロール内に（技術的）フォーカスを持っていますが、コントロールはユーザーには見えないことです。ユーザーが入力を続けると、テキストボックス内で変更が行われ、ユーザーには表示されません。
テキストボックスの末尾に移動するCTRL + Endやテキストボックスの先頭に移動するCTRL + Homeなど、他の通常使用されるコントロールは、期待どおりに機能します。
コンテキストが有効なコントロールは、少なくともMicrosoft Office 2007にリボンが導入されてから存在しているため、このアイデアは新しいものではありません。しかし、実装は、ユーザーが何をしているのかを（視覚的およびコンテキストで）管理できるように変更する必要があります。
あなたの質問に答える、その背後にある推論は難しいです。しかし、おそらくその背後にある実際の設計論はありません。それはたまたま起こりました。設計上の選択がある場合、CTRL + EndとCTRL + Homeは同じように動作しますが、動作しません。これはおそらく、Webページ全体ではなく、狭すぎる焦点を絞った設計（コントロール）に基づく一連の偶発的なエラーの作業です。
私がこれについて考えることができる「プロ」の理由は、テキストボックスの最後に到達したときに、ナビゲーションの観点から、テキストボックスの下にあるページの次のエンティティに移動することです。したがって、ボックスの一番下までスクロールすると、ページ内をスクロールし続けます。
煩わしさは、さらに進むのではなく、戻りたいときに発生します。
煩わしさを解決するためのいくつかの提案：-ボックスの最後に達した後、下にスクロールするのに遅延を追加します。 -上記と同じ線に沿って、スクロールにスナップ重力効果を追加します。ボックスの最後まで自由にスクロールし、ページをスクロールするには、さらにスクロールする必要があります。
編集1
シナリオ1：長いテキストボックスを下にスクロールして、前に読んだ特定の文を見つけます。私はかなり高速にスクロールしていたため、テキストボックスの最後を逃してしまい、ページのスクロールを続けていました。テキストボックスまでスクロールして戻り、ボックス内でスクロールして検索を再開します。
ボックスの最後に達したときに遅延があった場合、スクロールが停止し、もう一度上にスクロールして検索を再開できます。
ここでは遅延がセーフティネットとして機能します。 「元に戻す」エクスペリエンスを必要とするのではなく、遅延により、ユーザーはそもそも「間違い」を犯すことがなくなります。
ユーザビリティドメインで遅延を使用する例を見つける必要があります。しかし、人々は彼らが理解するには速すぎると動作するシステムを信頼していないため、信頼係数を誘導するために遅延を使用する例はたくさんあります。例： http://danariely.com/2010/12/15/locksmiths/
テキストボックスの使用方法に応じて、ページの設定を正当化します。たとえば、フォームを作成していて、ユーザーがテキストボックスフィールドに入力している場合、フィールドと列のサイズを小さくします。そうすれば、ユーザーはページを何度もスクロールし続けることはありません。
テキストボックス内の列と行の設定の例 
小さいサイズには、ユーザーが入力した情報のすべてを広いスペースで表示できないため、欠点があります。ただし、ページスクロールはより制限されています。テキストボックスを拡張することも解決策となります。
このテーマに関する資料については、この行動を研究的にサポートすることはあまりありません。