ドラッグ領域が通常「タイトルバー」に制限されているのはなぜですか？
簡単なダイアログウィンドウを見てみましょう。 
ユーザーは、タイトルバーを使用してウィンドウを画面にドラッグできることを期待します。しかし、なぜそれがこのバーだけに限定されているのですか？
入力要素ではないウィンドウの任意の場所をクリックしてそこからドラッグするだけでウィンドウを移動できるのはなぜ珍しいのですか？
これは、多くの場合、不要なドラッグアンドドロップアクションにつながると思います。たとえば、このウィンドウに小さなスクロールバーがあり、ページの一番下までスクロールして、誤ってスクロールバーを見逃した場合はどうなりますか？ウィンドウを下にドラッグすると、この操作を元に戻す必要がある場合があります。
入力要素ではないウィンドウ内をクリックして、そこからドラッグするだけでウィンドウを移動できるのはなぜ珍しいのですか？
多くの場合、別のウィンドウにドラッグアンドドロップする画像やその他の要素があります。次に、ラベルの近くをクリックしたときにラベルをコピーできる必要がありますが、十分にクリックしたときにウィンドウをドラッグすることもできます。したがって、すべてのユーザーがウィンドウのドラッグが機能することを期待できる場所を定義する必要があります。そして、これは現在タイトルバーです。
タイトルバーは、ウィンドウをドラッグするために使用できる唯一の場所であるとは限りません（最近では、一部のウィンドウは背景の一部によってドラッグできますが、まれです）。それは初期の [〜＃〜] wimp [〜＃〜] UI、70年代と80年代のSmalltalkシステムで始まりました。
上記のウィンドウがどのように設計されているかを調べると、タイトルバー以外にウィンドウをドラッグするためのウィンドウには他にアフォーダンスがないことがわかります。未使用のウィンドウの背景はありませんgrabbed（当時の画面領域ははるかに高価だったことを思い出してください）。すぐにタイトルバーがウィンドウの幅全体に広がり、ウィンドウを長方形にして、より多くのスペースを確保し、画面の更新をより効率的に計算しました。タイトルバーを全幅にすると、ウィンドウ操作のショートカットとして機能するボタンを保持できます。
これは非常に学びやすく、使いやすいシステムであることがわかり、多くの異なるUI（Mac、Windowsなど）によってコピーされました。この条約をやめる正当な理由はありませんでした。それは壊れていなかったので、それを修正する必要はありませんでした、そしてそれはまだ今日生き残ります。
これは実際には常に正しいとは限りません。ほとんどのアプリのデフォルトの動作では、ウィンドウを空のスペースでドラッグできる場合があります。例はKDEです。スクリーンショットを見る：
KDEのデフォルトのOxygenウィジェットスタイルには、ウィンドウの装飾がウィンドウのコンテンツと視覚的にマージされています。したがって、フィールマッチの外観を作るために、テーマではデフォルトですべての空の領域からウィンドウをドラッグすることもできます。デザインの両方の部分はある程度設定可能です。ドラッグウィンドウオプションはスクリーンショットで強調表示されています—無効化または縮小できます。また、アクティブウィンドウのタイトルの輪郭を描いて、装飾がコンテンツと結合しないようにするオプションもあります。
しかし、この機能は一部のユーザーと開発者の間で論争の原因となっています。Marvinの回答で述べたように、ウィジェットハンドルを移動するのではなく誤ってウィンドウをドラッグしたためだけでなく、現在のウィジェットツールキットで完全に実装することはほぼ不可能だからです。 QtやGTK +など。 GTK +（oxygen-gtk内）の場合、いくつかの一般的なアプリケーションや個々のウィジェットをドラッグ操作のトリガーからブラックリストに登録するなど、かなりのハックがあります。程度は低いですが、同様のハッキングが酸素qtに存在します。
Windows OSには、（オプションの）タイトルバーとコントロールボックス、およびOSユーザーがアプリケーションウィンドウを整理する（再配置、最小化、最大化、閉じる）ためのメカニズムが用意されています。
Windows OSの観点から、タイトルバーはこれらの操作のためのユーザーのAPIです。ウィンドウ内の他のすべては、その特定のアプリケーションを開発した人の制御下にある「コンテンツ」です。
特定のアプリケーションの開発者は、プログラムでAPIをトリガーするコントロールを作成することにより、ユーザーが再配置、最小化、最大化、および閉じるための追加の方法を提供する場合があります（つまり、ウィンドウを再配置できるアプリケーションを実装できます）コンテンツの背景をドラッグ）。開発者は、タイトルバーAPIを完全にオフにすることもできます。それは彼らのアプリケーションです。 OSは、（設計上）コントロールの外にあるという理由だけで、コンテンツ領域の内側にドラッグすることによって再配置を強制することはできません。
一貫性とおそらく使いやすさのために、ドラッグはタイトルバーに制限されています。コンテンツ領域をクリックしてウィンドウをドラッグしたり、コンテンツ領域のボタンやテキストなどを操作したりできる場合は、エラーのマージンが非常に高くなります（プログラミングの難しさを推測できます）。
ウィンドウ内のクリックは、コンテンツを操作するために予約されています。サンプルダイアログウィンドウには、そのオプションが存在する場合、クリックしてドラッグするための十分な空白があります。ただし、次のようなウィンドウからエラーメッセージをコピーしたいとします。メッセージをコピーすると、メッセージをGoogle検索に貼り付けて、問題を解決するための詳細情報を取得できます。メインコンテンツ領域をクリックしてドラッグすることもできる場合は、エラーをコピーするのが非常に難しい場合があります。
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
また、おそらく歴史的な理由もあります。カーソルがタイトルバーにあるかどうかを定義することは、NOT(text OR button OR input box OR scrollbar OR ...)にあるかどうかを定義するよりも計算上はるかに簡単な問題です。 1987年に512kBのRAMで購入したマシンのGEMでドラッグ可能なウィンドウを覚えていると思います。確かに、数年後の一部のDOSアプリケーション（テキストモード）でもそうです。これらのどちらの場合でも、コードはシンプルに保つ必要がありました。この慣例を変更せざるを得ない理由がなければ、それは固執した。ウィンドウがより複雑になったため、他の回答の他の理由のいくつかは、この長年の振る舞いから続いていると示唆することもできます。しかし、それは少し行き過ぎかもしれません。
空のスペースをドラッグするオプションがある場合でも、そこに座ってドラッグする場所を選択する人は誰もいないため、問題はほとんど疑わしいものです。 knowが機能する場所にマウスをまっすぐ動かすよりも時間がかかります。
ドラッグ可能な領域をすばやく取得するという点では、ゼロ以上の値があると思います。しかし、一貫性がない場合、それは役に立たず、それが唯一の方法であるように見えますcould一貫性があるのは、ウィンドウの縁がすべて太い場合です。その場合、境界線はドラッグハンドルよりもサイズ変更ハンドルとしてとにかく便利です。
とにかく、私はドラッグ可能な空のスペースにパフォーマンスのペナルティがあるとは確信していません。マウスでクリックすると、システム（OS +アプリケーション）は画面上のすべてのコントロールを検索して、クリックの正しいターゲットを見つけていることを確認する必要があります。クリックがどのコントロール内にもないことが判明した時点で、「OK、ウィンドウのドラッグを開始します」と言っても余分な費用はかかりません。
Mac OS Xでは、ウィンドウコンテンツによるドラッグが可能です。 「つや消しメタル」のウィンドウはすべてこの方法で機能しました。したがって、ウィンドウ本体全体がドラッグ可能な領域であり、実際のコントロールが占める領域のみがドラッグ可能ではありませんでした。このアプローチの問題点（少なくとも私と一部の友人にとって）は、ユーザーがドラッグできる場所とできない場所がユーザーにはっきりと分からないことでした。
明確な境界線がないビューがある場合、これはさらに悪化します。ドラッグ領域は一般にビューごとに指定されるため、グラフィックスが円形であったり、ビューの一部が他より薄い場合でも、ドラッグできない領域は常にビューの周りの長方形でした。
Appleはこれに気づいたようです。 "ブラシをかけられた金属"の一般的な外観が削除されているためです（そのように作成されたウィンドウはまだドラッグできますが、見た目はそれほど異なりません）。 Safariブラウザーウィンドウやメッセージバディウィンドウなどのウィンドウでも、下部のステータスバーなどでドラッグできます。そのため、境界線のないUI要素を持たずに、明確に区切られた領域のみをドラッグできるようになっているようです。