macOS Tahoeのウインドウサイズ変更問題、なお続く話

 (noheger.at)
1 ポイント 投稿者 GN⁺ 2026-02-13 | 1件のコメント | WhatsAppで共有
  • macOS 26.3のウインドウサイズ変更バグ修正の有無を検証するため、テストアプリケーションを作成
  • ピクセル単位のスキャンによってウインドウ角付近のクリック反応領域を分析し、色ごとに反応状態を可視化
  • 修正されたRC版では、角の半径に沿う曲線状の領域へ変更され、改善されたことを確認
  • しかし、垂直・水平専用の調整領域の厚みが7ピクセルから6ピクセルに減少し、操作精度が低下
  • 最終リリースでは修正が完全に削除され、以前の長方形領域に復帰し、リリースノートでも「Resolved Issue」が「Known Issue」に変更

macOS 26.3 RC版の変更点

  • macOS 26.3 RCのリリースノートには、以前のブログで指摘されたウインドウサイズ変更問題の解決が明記
    • これを受けて、実際の変更内容を検証するためテストアプリケーションを作成
  • テストアプリは、ウインドウ右下の角周辺をピクセル単位でスキャンし、マウスクリックへの反応を色で表示
    • 赤: クリック反応あり
    • 緑: サイズ変更可能
    • 黄: 垂直または水平のみ変更可能
    • 青: マウスイベントなし
  • その結果、ウインドウサイズ変更領域が長方形ではなく角の曲線に沿う形へ変更され、視覚的一貫性が向上
  • しかし、黄色の領域の厚みが3ピクセルから2ピクセルに縮小し、全体の厚みが7ピクセルから6ピクセルに減少
    • これは約14%の減少であり、ユーザーが調整領域を外す確率が高まる

macOS 26.3 最終リリースでの後退

  • 最終版で同じテストを再実行した結果、RC版の修正が完全に取り除かれていた
    • ウインドウサイズ変更領域は再び従来の長方形形状に戻った
  • Appleのリリースノートでも、この問題の状態は**「Resolved Issue」から「Known Issue」へ変更**
    • つまり、問題解決は撤回され、依然として認識済みのバグとして残っている

関連記事

1件のコメント

 
GN⁺ 2026-02-13
Hacker Newsのコメント

  • 最初に Linux の ウィンドウマネージャー（WM） に触れたときから、ウィンドウの移動とサイズ変更はそれぞれ super+lmb/rmb の組み合わせが最も効率的だと信じている。
    もうヘッダーや角をピクセル単位で狙い合わせる必要がないのが最高。
    関連する議論は Reddit スレッドでも見られる

    • 昔 Sawfish ウィンドウマネージャーを使っていたが、メンテナンスが止まるまでは本当に良かった。
      なかでも、どんなウィンドウでも 自由にサイズ変更できた点がいちばん恋しい。
      縦長モニターを使っていると、固定サイズのモーダルウィンドウに不要なスクロールバーが付いているのが残念に感じる
    • Linux では閉じる／最小化／最大化のショートカットまで覚えれば、ウィンドウの枠線とタイトルバーを取り除くことすらできる。
      画面領域を完全に確保できるわけだ
    • macOS では Control+Command の組み合わせでウィンドウドラッグを有効にできる。
      defaults write -g NSWindowShouldDragOnGesture -bool true コマンドで設定でき、3本指ドラッグと一緒に使えば、境界線でのリサイズ問題はほとんどない
    • Linux を初めて使ったときからこの機能を見て、なぜ他の OS はこれを そのまま真似しなかったのか 不思議だった
    • 最近仕事用に新しい Mac を使うようになったが、Hyprland から移ってくると適応は簡単ではなかった。
      Aerospace と Karabiner-Elements でワークフローの大半は再現したものの、いまだに super+右クリックでリサイズする機能が恋しい。
      それでも ctrl+cmd+左クリックでウィンドウ移動ができるのはかなり良い

  • 画面はどんどん大きくなるのに、UI 要素はむしろ小さくなってクリックしづらくなっている気がする。
    昔の Macintosh 640x480 の時代は、ウィンドウコントロールが明確で押しやすかった。
    関連する回顧は このブログ記事でも見られる

    • 昔の EGA 620x200 の時代から、ウィンドウ操作領域のピクセルサイズはほとんど変わっていないように思う。
      今では ppi が 200 以上のディスプレイも多いのに、いまだに同じピクセル単位のままなのは非効率だ。
      いっそ タイル型ウィンドウマネージャーに戻って、キーひとつでサイズ変更自体をなくしたほうがいいのかもしれない
    • 1994年の System 7 時代から Mac を使ってきたが、Snow Leopard（10.6） の頃が安定性と速度の両方で最高だったと感じる。
      とくにブラックの MacBook 時代のトラックパッドとキーボードの品質は素晴らしく、マルチモニター対応も優秀だった。
      旧 MacOS のデザイン哲学が現代のハードウェアと組み合わさったら、どんな結果になるのか気になる
    • 4K モニターを使う UX デザイナーが、実際には 2K 解像度まで落として作業しているのを見ると、「大きい画面なのに小さく見える」という問題は本物だ

  • ピクセルの太さが 7 から 6 に減れば 14% 減る計算になるが、実際に クリック失敗率がきっちり 14% 増えるわけではない。
    ユーザーのクリックは一様分布ではなく中央寄りに偏っているからだ

    • ただ、分布が分からない以上、むしろ失敗率がもっと高い可能性もある
    • 逆に、クリックイベントが ウィンドウマネージャーに横取りされず アプリケーションに渡る確率は上がるかもしれない
    • 自分も同じことを考えたが、あまりにも揚げ足取りな人に見えそうで言わなかった

  • 最近の Apple のアップデートは、macOS、iOS、iPadOS 全般で より多くのバグを持ち込んでいるように感じる。
    社内にユーザー利益より組織の論理を優先するグループがいるように見える。

    1. 外部モニター接続時にディスプレイの再配置が毎回必要になる
    2. AirDrop が理由もなく動かなくなる
    3. デバイス間のコピー＆ペーストが不安定
    4. PDF をスクロールすると Preview アプリがクラッシュする
      こうした問題が新たに起きているのを見ると、Apple の内部品質管理は深刻に揺らいでいる
    • Ethernet ケーブルを挿した状態で Wi‑Fi を有効にすると、macOS が 完全にクラッシュして再起動する。
      警告メッセージもなく、そのまま落ちる
    • Microsoft のように、Apple も社内で AI の使用を強制しているのだろうか

  • 今回の変更は RC 版で修正されたあと、最終リリースで差し戻された。
    何らかの回帰や副作用があったようだが、正確にどんな問題があったのか気になる。

    • 一部の NSWindow スタイルが壊れたという報告があった (Apple Developer フォーラム)
    • 技術的な理由かもしれない。
      たとえば 2 つのウィンドウの角が重なるとき、単純に bounding box で処理していたものを実際のグラフィックマスクで計算しなければならなくなる状況が生じたのかもしれない。
      あるいは単なる バグやクラッシュだった可能性もある
    • もしかすると Apple が 丸い角のデザインをやめる計画を持っていて、それで戻したのかもしれない
    • おそらく公開テストで ユーザーの反応が良くなく、保留にした可能性が高い
    • こんな単純な修正ですら Apple 社内で展開しにくいのを見ると、組織構造の複雑さを感じる。
      むしろ、なぜこのバグがそんなに早く処理されたのかのほうが興味深い

  • UI の ヒットテスト（hit testing） は数十年前から解決済みの問題なのに、いまだに議論があるのは驚きだ。
    丸い角でさえ技術的には難しくないのに、社内で デザイナーと開発者の対立があったのではないかと推測してしまう。

    • Mobile Safari のタッチヒットテストはとくにひどい。
      コントロールの近くをタッチすると、見当違いの要素が反応することが多い。
      CSS で タップ領域（tap zone） を制御できればよいのだが、今は HTML 要素を追加したり onclick ハンドラーを無理やり入れたりしなければならない。
      iOS 26 Safari ではタップイベントを 横取りする新たな問題も起きている

  • 数か月のあいだ理由もなくウィンドウサイズを変更できないバグがあったが、原因は 2 台のモニターにまたがったウィンドウだった。
    ウィンドウが 2 つの画面に数ピクセルでもまたがると、リサイズできなくなる。

    • macOS の 外部モニター管理は本当に混乱している。
      ウィンドウ位置が保持されたり、見当違いの画面へ移動したり、さらには 見えない領域に現れたりもする。
      Apple がウィンドウをタイルやフルスクリーンでしか使わせたくない理由が分かる気がする。
      Windows や Linux よりもさらに不安定だ
    • 設定のどこかでこの機能を無効にできるが、実際に切ってみるとむしろその状態のほうが快適だった
    • super+矢印でウィンドウを モニター境界にぴったり合わせるショートカットを使えば、こうした問題は避けられる。
      今ではマウスで直接ドラッグすることはほとんどない

  • 完璧ではないが、BetterTouchTool で 3 本指ダブルタップによりリサイズモードをトグルできる。
    Yabai を使えば SIP を完全に切らなくてもよく、HYPER キーで ウィンドウ移動もできる。
    カーソル移動でウィンドウを調整し、キーを離せば即座に止まる

  • Mac でウィンドウリサイズアプリをいくつも試したが、Windows PowerToys の FancyZones ほど良いものはなかった。
    複雑なショートカットやホットコーナーは求めていない。
    自分が欲しいのは 2 つだけだ。

    1. 事前定義された領域
    2. 2 つのウィンドウの 共有境界線のリサイズ
      サブスクリプションなしでこうした機能を提供するアプリがあればいいのにと思う
    • 有料ではあるが Rectangle Pro が最も近い解決策だ。
      ただ、自分は Hammerspoon を入れて Lua でスクリプトを書いた。
      1440p モニター 2 台向けのカスタム設定なのでコードは単純で、修正もしやすい。
      Hammerspoon 公式サイト と 自分のスクリプト例 を参照できる
    • Swish は複数ウィンドウを同時にリサイズでき、BentoBox は FancyZones に着想を得ている。
      Lasso はグリッドベースのレイアウトを提供し、MacsyZones はオープンソースとして類似機能を提供する。
      Swish, BentoBox, Lasso, MacsyZones
    • PowerToys は良いが、1.17GB の容量を占めるのはやりすぎだ

  • 標準の Gnome のほうがマシだと感じるレベルなら状況は深刻だ。

    • 最近 KDE Plasma に移ったが、再び 角張ったウィンドウの角を使えるようになって満足している
    • Fedora の Gnome 実装が好きだ。
      Mac に戻ると、なぜ Spotlight と Mission Control が別々に存在するのか理解できない
    • Windows や Gnome の ウィンドウスナップ機能が恋しい。
      Win キーでのアプリ一覧、半画面整列、フルスクリーンではない最大化などは、macOS よりずっと直感的だ