Safari 27 ist jetzt auf den Handys Ihrer Nutzer. Was sich für gemeldete Bugs geändert hat

Safari 27 erschien am 14. September 2026, zusammen mit iOS 27, iPadOS 27 und macOS 27. In Apples Release Notes steckt ein Satz, der mehr Gewicht hat, als er zunächst vermuten lässt: Dasselbe Safari kommt auch auf macOS 26 und macOS Sequoia. Es bleibt also nicht auf Nutzer beschränkt, die das neue Betriebssystem installiert haben. Es erreicht jeden, der auf einem zwei Jahre alten Mac ein Safari-Update annimmt, und jedes iPhone, das sich über Nacht selbst aktualisiert, also die meisten.

Bis zum Ende der Woche wird ein großer Teil der Besucher, die Ihre Seite vom iPhone aus nutzen, in einem anderen Browser unterwegs sein als noch am Freitag, und fast keiner von ihnen wird es merken. Genau das macht ein Browser-Release zu einem Ereignis für Bug-Reports. Die Seite hat sich nicht verändert. Die Reports darüber schon.

Die Beta-Ankündigung zur WWDC bezifferte den Umfang des Releases auf 58 neue Funktionen, 525 Fehlerbehebungen und 4 entfernte Funktionen. Die meisten davon bleiben unsichtbar, wenn man kein CSS schreibt. Eine Handvoll verändert jedoch, was eine Seite tut, und zwar so, dass Nutzer es bemerken, und genau die landen als Tickets bei Ihnen. Hier sind sie, mit jeweils dem, was zu tun ist.

Scroll Anchoring ist aktiv und verschiebt einen Bug, statt ihn zu beseitigen

Jahrelang war Safari der Browser, bei dem die Seite sprang. Ein Bild oberhalb des Absatzes, den man gerade las, war fertig geladen, oder ein Banner schob sich oben ins Bild, und alles rutschte unter dem Daumen nach unten weg. Chrome und Firefox gleichen das schon seit Jahren aus, jetzt tut Safari es auch. Wird Inhalt oberhalb des sichtbaren Bereichs eingefügt oder entfernt, passt der Browser die Scroll-Position so an, dass der gelesene Text an seiner Stelle bleibt.

Damit verschwindet eine ganze Kategorie von Meldungen der Art „die Seite springt, während ich lese“, allerdings nur für Nutzer von Safari 27. Wer noch auf Safari 26 unterwegs ist, wird diese Meldungen weiterhin schreiben, und das ist schon der erste Grund, warum die Version im Ticket wichtig ist.

Der zweite Grund ist die Falle. Viele Seiten haben das Springen selbst bekämpft: die Höhe von dem messen, was gleich nachgeladen wird, und die Scroll-Position beim Eintreffen um genau diesen Betrag verschieben. Dieser Code war am Freitag noch korrekt. Heute, unter Safari 27, nimmt der Browser dieselbe Korrektur zuerst vor, und die Korrektur der Seite kommt obendrauf. Die Seite springt nun in die andere Richtung, um genau den Betrag, den die Seite bisher ausgeglichen hat. Eine Meldung wie „die Seite springt beim Laden von Bildern nach oben, das war früher nie so“ ist genau dieser Bug, und die ehrliche Antwort lautet, dass der eigene Fix jetzt die Ursache ist.

Der übliche Ausweg ist in jedem Browser derselbe: overflow-anchor: none auf dem Container schaltet das Anchoring des Browsers für diesen Bereich ab, sodass nur noch die eigene Kompensation der Seite läuft. Oder, besser noch: die eigene Kompensation entfernen und die Sache allen drei Engines überlassen.

Im selben Abschnitt der Release Notes wird auch etwas Kleineres behoben, das auf iOS sehr verwirrende Meldungen erzeugt hat: Ein Aufruf von scrollTo während eines Momentum-Scrolls stoppte den Scrollvorgang bislang abrupt. Eine Seite, die den Nutzer irgendwohin scrollte und sich danach anfühlte, als hätte sie den Bildschirm festgehalten, war oft genau das. Behoben in 27, vorhanden in 26.

Acht Fixes an der Content Security Policy, zwei davon erzeugen Reports

Der Abschnitt Security der Release Notes listet acht Korrekturen an der Content Security Policy auf. Sechs davon machen Safari strenger oder korrekter, und zwar auf eine Weise, die vor allem Seiten betrifft, die ohnehin schon leicht fehlerhaft waren. Zwei davon tauchen in einem Report-Endpunkt auf, ohne dass sich bei Ihnen irgendetwas geändert hätte.

Verstöße gegen frame-ancestors in einer Report-only-Policy wurden bisher verworfen statt gemeldet. Jetzt werden sie gesendet. Eine Seite, die Content-Security-Policy-Report-Only mit frame-ancestors einsetzt, und genau so finden die meisten Teams heraus, wer sie einbettet, bevor sie etwas erzwingen, war gegenüber Safari blind, solange es diese Policy gibt. Ab dieser Woche treffen die Reports ein. Die Menge kann wie ein Angriff aussehen. Es ist ein Rückstau.

JSON-Modul-Importe (import data from "./x.json" with { type: "json" }) wurden bisher gegen script-src geprüft. Die Spezifikation verlangt connect-src, und Safari 27 hält sich nun daran. Eine Policy, die den Ursprung des JSON unter script-src erlaubte, aber nicht unter connect-src, blockiert diese Importe nun, und eine Policy mit der umgekehrten Regelung lässt sie neu zu. So oder so ändert sich das Verhalten der Seite auf einer Browserversion und nicht auf der vorherigen.

Schwach

Unser CSP-Report-Endpunkt ist über Nacht vollgelaufen. Irgendetwas bettet uns überall ein.

Besser

Verstöße gegen frame-ancestors im Report-only-Modus treffen seit dem 15. September von Safari 27.0 ein. Safari 26 hat sie verworfen, es handelt sich also um bestehende Einbettungen, die wir bisher nicht sehen konnten, nicht um neue.

Zwei weitere aus derselben Liste sind einen Satz wert, weil sie aus einer kaputten Seite eine funktionierende machen, und auch das ist eine Änderung, die jemandem auffällt. <object>-Elemente, die Bilder laden, wurden bisher von img-src blockiert, jetzt nicht mehr. Und 'self' traf bei Skriptquellen in Dokumenten mit einem opaken Ursprung, etwa einem sandboxed iframe, nicht zu, sodass manche Skripte, die eigentlich laufen sollten, es nicht taten. Beides ist behoben. Wenn eine Seite diese Woche auf irgendjemandes Handy plötzlich zu funktionieren begann, war das vielleicht nicht Ihr Deploy.

Gestylte Selects, die vorher schlicht waren

appearance: base-select hält mit Safari 27 Einzug, zusammen mit dem Element <selectedcontent>. Jede Seite, die bereits ein angepasstes <select> für Chrome ausgeliefert hat, abgesichert durch Feature-Detection, bekommt die angepasste Version jetzt auch unter Safari. Das ist das beabsichtigte Ergebnis und meist ein gutes. Es ist außerdem das erste Mal, dass dieses CSS auf Safari überhaupt läuft, und das erste Mal, dass es jemand auf einem iPhone bei der echten Breite, mit der echten Tastatur, im echten Dark Mode sieht. Rechnen Sie mit der einen oder anderen Meldung, und behandeln Sie „das Dropdown sieht seit gestern auf meinem Handy anders aus“ als zutreffend statt als Verwirrung.

Secure-Cookies auf localhost

Versteckt im Abschnitt Networking: Safari respektiert jetzt Secure-Cookies auf Loopback-Hosts. Jede andere Engine macht das schon seit Jahren, und genau deshalb konnte ein Login-Flow in Chrome auf localhost funktionieren, nur in Safari fehlschlagen und jemanden eine Stunde lang Zertifikate prüfen lassen. Diese eine Stunde entfällt jetzt. Was localhost eigentlich ist erklärt den Rest davon, warum „es funktioniert auf localhost“ weniger beweist, als es klingt.

Was das alles für den Report bedeutet

Jeder Punkt oben hat dieselbe Form: dieselbe Seite, die sich unter Safari 26.6 anders verhält als unter Safari 27.0, am selben Tag, bei zwei Menschen, die nebeneinandersitzen. Diese Form lässt sich nur diagnostizieren, wenn der Report verrät, von welcher der beiden er stammt.

Die meisten Reports tun das nicht. „Safari auf meinem iPhone“ ist, was Leute schreiben, und das ist nicht ihre Schuld: Auf einem iPhone ist die Safari-Version die iOS-Version, sie steckt in den Einstellungen unter Allgemein und Info, und das Update passierte, während sie schliefen. Die erste Rückfrage muss also die Version betreffen, noch vor den Reproduktionsschritten, und der günstigste Weg, sie zu bekommen, ist eine Seite, die sie ausliest. Unsere liegt unter /tools/user-agent: Sie zeigt Browser und Version, das Betriebssystem, die Bildschirmgröße und das Farbschema, und wer den Report schreibt, kann das Ganze einfach einfügen. Das funktioniert in jedem Browser, weil es muss.

Eine ehrliche Grenze auf unserer Seite: Session Replay ist eine Chrome-Erweiterung. Sie kann keinen Report aus Safari erfassen, und ein Bug, der nur in Safari 27 auftritt, zeigt sich nicht auf einer in Chrome geöffneten Seite. Was sie aber leistet, ist die andere Hälfte der Frage schnell zu klären: dieselbe Seite in Chrome öffnen, erfassen, und innerhalb einer Minute wissen Sie, ob der Fehler in der Seite oder in der Engine steckt. Genau das ist Cross-Browser-Testing in der Praxis: drei Engines, und wissen, welche man gerade vor sich hat.

Für die Safari-Hälfte gilt: Wenn Sie einen Mac haben, ist Web Inspector über ein Kabel immer noch der Weg, und so geht Inspect Element auf einem iPhone führt Schritt für Schritt durch. Der Web Inspector von Safari 27 zeigt jede Anfrage in einer Redirect-Kette jetzt einzeln an, eine kleine Erleichterung, wenn der Bug eine Login-Schleife ist.

Der Rest des Releases, kurz zusammengefasst

Noch ein paar Dinge aus den Release Notes, von denen Entwickler wissen sollten.

Streams lassen sich jetzt leichter konsumieren. for await...of über einen ReadableStream, ReadableStream.from(), um einen aus einem beliebigen Iterable zu bauen, und Streams lassen sich per postMessage() übertragen. Code, der für Chrome geschrieben wurde und sich auf eines davon verlassen hat, läuft jetzt auch in Safari, ohne Polyfill.

Fehler in Web-Extensions werden gemeldet. Nicht abgefangene Exceptions und unbehandelte Promise-Rejections in den Skripten einer Safari-Web-Extension werden jetzt sichtbar, wo sie vorher spurlos verschwanden. Wer einen Safari-Port einer Chrome-Erweiterung pflegt, sollte damit rechnen, von Fehlern zu erfahren, die es schon länger gibt.

Die Static-Routing-API für Service Worker ist da: Ein Service Worker kann jetzt im Voraus festlegen, welche Requests an ihm vorbeigehen, sodass der Netzwerkpfad für ein statisches Asset nicht mehr auf den Start eines Workers warten muss.

Vier entfernte SVG-Funktionen. SVGLocatable, SVGTransformable, nearestViewportElement, farthestViewportElement und viewTarget sind verschwunden, zusammen mit glyph-orientation-horizontal. Altes SVG-Tooling, das eines davon angefasst hat, wirft unter Safari 27 einen Fehler und unter 26 nicht, noch ein Report, den man an der Version erkennt.

Was Sie daraus mitnehmen sollten

Ein Browser-Update ist eine Änderung an der Produktion, die niemand im Team deployt, reviewt oder zurückrollen kann, und sie erreicht eine Woche lang jeden Tag einen anderen Anteil der Nutzer. Der einzige Schutz besteht darin, zu wissen, aus welcher Version jeder Report stammt, damit sich „es fing gestern an“ mit „Safari 27 ist gestern erschienen“ verknüpfen lässt statt mit dem letzten eigenen Deploy.

Apples eigene Release Notes sind die Referenz, und sie sind lang: Safari 27 Release Notes.