Problem mit der Fenstergrößenänderung in macOS Tahoe: Die Geschichte geht weiter

 (noheger.at)
1 Punkte von GN⁺ 2026-02-13 | 1 Kommentare | Auf WhatsApp teilen
  • Es wurde eine Testanwendung erstellt, um zu überprüfen, ob der Bug bei der Fenstergrößenänderung in macOS 26.3 behoben wurde
  • Durch einen Scan auf Pixelebene wurde der klickempfindliche Bereich rund um die Fensterecken analysiert und der Reaktionsstatus farblich visualisiert
  • In der korrigierten RC-Version zeigte sich eine Verbesserung: Der Bereich wurde zu einer gekrümmten Zone entlang des Eckenradius geändert
  • Allerdings wurde die Dicke der ausschließlich vertikalen bzw. horizontalen Anpassungszonen von 7 auf 6 Pixel reduziert, wodurch die Bediengenauigkeit sank
  • In der finalen Veröffentlichung wurde die Korrektur vollständig entfernt und zum vorherigen rechteckigen Bereich zurückgekehrt; auch in den Release Notes wurde „Resolved Issue“ zu „Known Issue“ geändert

Änderungen in der macOS-26.3-RC-Version

  • In den Release Notes zu macOS 26.3 RC wurde ausdrücklich erwähnt, dass das im vorherigen Blog angesprochene Problem bei der Fenstergrößenänderung behoben sei
    • Daraufhin wurde eine Testanwendung erstellt, um die tatsächlichen Änderungen zu verifizieren
  • Die Test-App scannt den Bereich um die rechte untere Fensterecke pixelgenau und markiert die Reaktion auf Mausklicks farblich
    • Rot: Klickreaktion vorhanden
    • Grün: Größenänderung möglich
    • Gelb: Nur vertikale oder horizontale Größenänderung möglich
    • Blau: Kein Mausereignis
  • Das Ergebnis: Der Bereich zur Fenstergrößenänderung wurde von einem Rechteck in eine Form geändert, die der Eckenkrümmung folgt, was die visuelle Konsistenz verbessert
  • Allerdings wurde die Dicke des gelben Bereichs von 3 auf 2 Pixel reduziert, sodass die Gesamtdicke von 7 auf 6 Pixel sank
    • Das entspricht einer Verringerung von etwa 14 %, wodurch die Wahrscheinlichkeit steigt, dass Nutzer den Anpassungsbereich verfehlen

Regression in der finalen Veröffentlichung von macOS 26.3

  • Beim erneuten Ausführen desselben Tests in der finalen Version zeigte sich, dass die Korrektur aus der RC-Version vollständig entfernt wurde
    • Der Bereich zur Fenstergrößenänderung kehrte wieder zur bisherigen rechteckigen Form zurück
  • Auch in Apples Release Notes wurde der Status dieses Problems von „Resolved Issue“ auf „Known Issue“ geändert
    • Das heißt, die Problemlösung wurde zurückgezogen und der Fehler bleibt weiterhin als bekannter Bug bestehen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-13
Hacker-News-Kommentare

  • Seit ich zum ersten Mal einen Window Manager (WM) unter Linux kennengelernt habe, bin ich überzeugt, dass zum Verschieben und Größenändern von Fenstern jeweils die Kombination super+LMB/RMB am effizientesten ist
    Das Beste daran ist, dass man Header oder Ecken nicht mehr pixelgenau treffen muss
    Eine entsprechende Diskussion gibt es auch in diesem Reddit-Thread

    • Früher habe ich den Sawfish-Window-Manager genutzt, und er war wirklich großartig, bis die Wartung eingestellt wurde
      Am meisten vermisse ich daran, dass man jedes Fenster frei in der Größe ändern konnte
      Wenn man einen hochkantigen Monitor nutzt, ist es besonders ärgerlich, dass Fenster mit fester Modalgröße unnötige Scrollbalken haben
    • Unter Linux kann man, wenn man auch noch die Shortcuts für Schließen/Minimieren/Maximieren lernt, sogar Fensterrahmen und Titelleiste entfernen
      So bekommt man den Bildschirmplatz vollständig zurück
    • Unter macOS kann man mit der Kombination Control+Command das Ziehen von Fenstern aktivieren
      Das lässt sich mit dem Befehl defaults write -g NSWindowShouldDragOnGesture -bool true einstellen, und zusammen mit Drei-Finger-Ziehen gibt es dann fast keine Probleme mehr mit dem Resize am Rand
    • Seit ich diese Funktion zum ersten Mal unter Linux gesehen habe, frage ich mich, warum andere Betriebssysteme das nicht einfach kopiert haben
    • Ich habe kürzlich beruflich einen neuen Mac bekommen, und nach dem Wechsel von Hyprland fällt die Umstellung nicht leicht
      Mit Aerospace und Karabiner-Elements konnte ich den Großteil meines Workflows nachbauen, aber ich vermisse immer noch Resize per super+Rechtsklick
      Trotzdem ist ctrl+cmd+Linksklick zum Verschieben von Fenstern ziemlich brauchbar

  • Die Bildschirme werden immer größer, aber die UI-Elemente wirken eher kleiner und schwerer anklickbar
    Zu Zeiten des Macintosh 640x480 waren Fenstersteuerungen klar und leicht zu treffen
    Einen passenden Rückblick gibt es auch in diesem Blogpost

    • Schon seit den Tagen von EGA 620x200 scheint sich die Pixelgröße der Fenster-Bedienbereiche kaum verändert zu haben
      Heute gibt es viele Displays mit über 200 ppi, und trotzdem bleibt alles bei denselben Pixelmaßen, was ineffizient ist
      Vielleicht ist es besser, gleich zu einem Tiling Window Manager zurückzukehren und Größenänderungen per Tastendruck ganz abzuschaffen
    • Ich nutze Macs seit System 7 im Jahr 1994, und für mich war Snow Leopard (10.6) sowohl bei Stabilität als auch bei Geschwindigkeit der Höhepunkt
      Besonders die Touchpads und Tastaturen aus der BlackBook-Ära waren hervorragend, und auch die Multimonitor-Unterstützung war großartig
      Ich frage mich, was herauskäme, wenn die Designphilosophie des alten MacOS mit moderner Hardware kombiniert würde
    • Wenn sogar UX-Designer mit 4K-Monitoren tatsächlich auf 2K-Auflösung heruntergehen, ist das Problem „großer Bildschirm, aber alles wirkt klein“ eindeutig real

  • Wenn die Pixelstärke von 7 auf 6 sinkt, entspricht das zwar einer Verringerung um 14 %, aber die tatsächliche Wahrscheinlichkeit eines Fehlklicks steigt deshalb nicht automatisch genau um 14 %
    Denn Klicks von Nutzern sind nicht gleichverteilt, sondern eher zur Mitte hin konzentriert

    • Wenn man die Verteilung aber nicht kennt, könnte die Fehlerrate ebenso gut noch stärker steigen
    • Umgekehrt könnte die Wahrscheinlichkeit steigen, dass das Klick-Event nicht vom Window Manager abgefangen wird und stattdessen bei der Anwendung ankommt
    • Ich hatte denselben Gedanken, habe ihn aber nicht ausgesprochen, weil ich nicht zu pedantisch wirken wollte

  • In letzter Zeit habe ich das Gefühl, dass Apples Updates in macOS, iOS und iPadOS eher mehr Bugs einführen
    Es wirkt, als gäbe es intern eine Gruppe, die Organisationslogik über den Nutzen für Anwender stellt

    1. Beim Anschließen eines externen Monitors muss die Anzeige jedes Mal neu angeordnet werden
    2. AirDrop hört grundlos auf zu funktionieren
    3. Copy-and-paste zwischen Geräten ist unzuverlässig
    4. Beim Scrollen in PDFs stürzt die Preview-App ab
      Wenn solche Probleme neu auftreten, ist Apples interne Qualitätssicherung offenbar ernsthaft ins Wanken geraten
    • Wenn ein Ethernet-Kabel eingesteckt ist und man Wi-Fi aktiviert, stürzt macOS vollständig ab und startet neu
      Ohne Warnmeldung, einfach sofort
    • Ich frage mich, ob Apple intern wie Microsoft ebenfalls den Einsatz von KI erzwingt

  • Diese Änderung wurde in der RC-Version behoben und dann in der finalen Veröffentlichung wieder zurückgenommen
    Es muss irgendeine Regression oder Nebenwirkung gegeben haben, aber ich frage mich, was genau das Problem war

    • Es gab Berichte, dass einige NSWindow-Stile kaputtgingen (Apple Developer Forum)
    • Es könnte technische Gründe gehabt haben
      Wenn sich zum Beispiel die Ecken zweier Fenster überlappen, musste man vielleicht statt einer einfachen bounding box mit echten grafischen Masken rechnen
      Oder es war einfach nur ein Bug oder Absturz
    • Vielleicht wurde es auch zurückgenommen, weil Apple plant, das Design mit den abgerundeten Ecken abzuschaffen
    • Wahrscheinlich wurde es wegen schlechter Reaktionen im öffentlichen Test zurückgestellt
    • Dass selbst so eine einfache Korrektur intern bei Apple schwer auszurollen ist, zeigt, wie komplex die Organisationsstruktur sein muss
      Fast noch interessanter ist, warum dieser Bug überhaupt so schnell bearbeitet wurde

  • Hit Testing in UIs ist seit Jahrzehnten ein gelöstes Problem, deshalb überrascht es mich, dass darüber immer noch diskutiert wird
    Selbst abgerundete Ecken sind technisch nicht schwierig, also vermute ich eher einen Konflikt zwischen Designern und Entwicklern intern

    • Das Touch-Hit-Testing in Mobile Safari ist besonders schrecklich
      Wenn man in der Nähe eines Controls tippt, reagiert oft ein ganz anderes Element
      Es wäre gut, wenn man in CSS die Tap-Zone steuern könnte, aber derzeit muss man zusätzliche HTML-Elemente einfügen oder onclick-Handler hineinzwängen
      In Safari auf iOS 26 gibt es außerdem ein neues Problem, bei dem Tab-Events abgefangen werden

  • Ich hatte monatelang einen Bug, bei dem sich Fenster grundlos nicht in der Größe ändern ließen, und die Ursache war ein Fenster über zwei Monitore hinweg
    Sobald ein Fenster auch nur ein paar Pixel auf dem zweiten Bildschirm lag, war Resize nicht mehr möglich

    • Die Verwaltung externer Monitore unter macOS ist wirklich chaotisch
      Fenster behalten manchmal ihre Position, wandern auf den falschen Bildschirm oder erscheinen sogar in einem unsichtbaren Bereich
      Ich verstehe langsam, warum Apple Nutzer dazu bringen will, Fenster nur gekachelt oder im Vollbild zu verwenden
      Es ist sogar instabiler als unter Windows oder Linux
    • Irgendwo in den Einstellungen kann man diese Funktion deaktivieren, und nachdem ich das getan hatte, stellte sich heraus, dass dieser Zustand sogar angenehmer war
    • Mit einem Shortcut wie super+Pfeil, der Fenster exakt an Monitorgrenzen ausrichtet, kann man solche Probleme vermeiden
      Inzwischen muss ich Fenster fast nie mehr per Maus verschieben

  • Nicht perfekt, aber mit BetterTouchTool kann man per Drei-Finger-Doppeltipp einen Resize-Modus umschalten
    Mit Yabai muss man SIP nicht vollständig deaktivieren, und mit der HYPER-Taste geht auch Fenster verschieben
    Man passt das Fenster über die Cursorbewegung an, und sobald man die Taste loslässt, stoppt es sofort

  • Ich habe auf dem Mac mehrere Apps zum Größenändern von Fenstern ausprobiert, aber nichts war so gut wie FancyZones aus Windows PowerToys
    Ich will keine komplizierten Shortcuts oder Hot Corners
    Ich will genau zwei Dinge

    1. Vordefinierte Bereiche
    2. Resize über die gemeinsame Grenze zweier Fenster
      Es wäre schön, wenn es eine App ohne Abo gäbe, die das bietet
    • Rectangle Pro ist zwar kostenpflichtig, kommt dem aber am nächsten
      Ich habe stattdessen selbst Hammerspoon installiert und Lua-Skripte geschrieben
      Da meine Konfiguration auf zwei 1440p-Monitore zugeschnitten ist, ist der Code simpel und leicht anzupassen
      Siehe offizielle Hammerspoon-Website und mein Skriptbeispiel
    • Swish kann mehrere Fenster gleichzeitig in der Größe ändern, BentoBox ist von FancyZones inspiriert
      Lasso bietet rasterbasierte Layouts, und MacsyZones liefert als Open-Source-Projekt ähnliche Funktionen
      Swish, BentoBox, Lasso, MacsyZones
    • PowerToys ist gut, aber 1.17 GB Speicherbedarf ist einfach zu viel

  • Wenn selbst das Standard-Gnome besser wirkt, ist die Lage ernst

    • Ich bin kürzlich zu KDE Plasma gewechselt und freue mich, wieder eckige Fensterecken zu haben
    • Mir gefällt Fedoras Gnome-Umsetzung
      Wenn ich zu einem Mac zurückkehre, verstehe ich nicht, warum Spotlight und Mission Control getrennt existieren
    • Mir fehlt das Fenster-Snapping von Windows oder Gnome
      Mit der Win-Taste alle Apps anzeigen, Fenster halbseitig anordnen oder maximieren, ohne in den Vollbildmodus zu gehen, ist viel intuitiver als unter macOS