Safari 27 est sur le téléphone de vos utilisateurs. Ce qui a changé pour les bugs qu'ils signalent

Safari 27 est sorti le 14 septembre 2026, avec iOS 27, iPadOS 27 et macOS 27. Les notes de version d’Apple ajoutent une ligne plus importante qu’il n’y paraît : ce même Safari arrive aussi sur macOS 26 et macOS Sequoia. Il ne se limite donc pas aux personnes qui sont passées au nouveau système d’exploitation. Il touche quiconque accepte une mise à jour de Safari sur un Mac vieux de deux ans, et tous les iPhone qui se mettent à jour tout seuls pendant la nuit, c’est-à-dire la plupart d’entre eux.

D’ici la fin de la semaine, une grande partie des personnes qui utilisent votre site depuis un iPhone se trouveront sur un navigateur différent de celui qu’elles utilisaient le vendredi, et presque aucune ne le saura. C’est ce qui fait d’une sortie de navigateur un événement générateur de rapports de bugs. La page n’a pas changé. Les rapports à son sujet, eux, vont changer.

L’annonce de la bêta à la WWDC chiffrait cette version à 58 nouvelles fonctionnalités, 525 corrections et 4 dépréciations. La plupart sont invisibles pour quiconque n’écrit pas de CSS. Une poignée change le comportement d’une page d’une manière que l’utilisateur peut voir, et ce sont celles-là qui se retrouvent en ticket. Les voici, avec la conduite à tenir pour chacune.

L’ancrage du défilement est activé, et il déplace un bug plutôt qu’il ne le supprime

Pendant des années, Safari a été le navigateur où la page sautait. Une image finissait de charger au-dessus du paragraphe que vous lisiez, ou une bannière s’insérait en haut de l’écran, et tout se décalait vers le bas sous votre pouce. Chrome et Firefox compensent cela depuis des années ; Safari le fait désormais aussi. Quand du contenu est inséré ou retiré au-dessus de la zone visible, le navigateur ajuste la position de défilement pour que ce que vous lisiez reste à sa place.

Cela ferme toute une famille de rapports du type « la page saute pendant que je la lis », mais uniquement pour les utilisateurs de Safari 27. Ceux qui sont encore sur Safari 26 continueront d’en signaler, ce qui est la première raison pour laquelle la version compte dans le ticket.

La deuxième raison est le piège. Beaucoup de sites combattaient déjà ce saut par leurs propres moyens : mesurer la hauteur de ce qui va se charger, puis décaler la position de défilement d’autant à son arrivée. Ce code était correct le vendredi. Aujourd’hui, sur Safari 27, le navigateur applique d’abord la même correction, et celle du site vient s’ajouter par-dessus. La page saute désormais dans l’autre sens, exactement de la quantité que le site corrigeait. Un rapport qui dit « la page saute vers le haut quand les images chargent, elle ne faisait pas ça avant » décrit ce bug précis, et la réponse honnête est que le correctif du site en est désormais la cause.

La solution standard est la même dans tous les navigateurs : overflow-anchor: none sur le conteneur désactive l’ancrage du navigateur pour cette zone, si bien que seule la compensation du site s’applique. Ou, mieux encore, supprimez cette compensation et laissez les trois moteurs s’en charger.

La même section des notes corrige un point plus précis, à l’origine d’un rapport très déroutant sur iOS : appeler scrollTo pendant un défilement avec inertie interrompait net le défilement. Une page qui faisait défiler l’utilisateur quelque part et donnait ensuite l’impression d’avoir figé l’écran, c’était souvent cela. Corrigé dans la 27, encore présent dans la 26.

Huit correctifs de Content Security Policy, et deux d’entre eux génèrent des rapports

La section Sécurité des notes de version liste huit corrections de Content Security Policy. Six d’entre elles rendent Safari plus strict ou plus correct, ce qui touche surtout des pages qui étaient déjà légèrement fautives. Deux autres vont apparaître dans un point de collecte de rapports sans que vous n’ayez rien changé de votre côté.

Les violations de frame-ancestors dans une politique en mode rapport seul étaient abandonnées au lieu d’être signalées. Elles sont désormais envoyées. Un site qui exécute Content-Security-Policy-Report-Only avec frame-ancestors, ce qui est la façon dont la plupart des équipes découvrent qui les intègre avant d’imposer quoi que ce soit, était aveugle à Safari depuis que cette politique existe. Depuis cette semaine, les rapports arrivent. Le volume peut ressembler à une attaque. Il s’agit d’un arriéré.

Les imports de modules JSON (import data from "./x.json" with { type: "json" }) étaient vérifiés selon script-src. La spécification indique connect-src, et Safari 27 s’y conforme désormais. Une politique qui autorisait l’origine du JSON sous script-src mais pas sous connect-src se met à bloquer ces imports, et une politique qui faisait l’inverse se met à les autoriser. Dans les deux cas, le comportement de la page change sur une version du navigateur et pas sur la précédente.

Faible

Notre point de collecte des rapports CSP s'est rempli pendant la nuit. Quelque chose nous intègre partout.

Mieux

Les violations frame-ancestors en mode rapport seul de Safari 27.0 ont commencé à arriver le 15 septembre. Safari 26 les abandonnait, donc il s'agit d'intégrations déjà existantes que nous ne pouvions pas voir, pas de nouvelles intégrations.

Deux autres corrections de la même liste méritent une phrase, car elles transforment une page cassée en page fonctionnelle, et c’est aussi un changement que quelqu’un remarquera. Les éléments <object> qui chargent des images étaient bloqués par img-src, ce n’est plus le cas. Et 'self' ne correspondait pas aux sources de scripts dans les documents à origine opaque, comme une iframe en bac à sable, si bien que certains scripts qui auraient dû s’exécuter ne le faisaient pas. Les deux sont corrigés. Si une page s’est mise à fonctionner mystérieusement sur le téléphone de quelqu’un cette semaine, ce n’est peut-être pas grâce à votre déploiement.

Des listes déroulantes personnalisées, là où elles étaient basiques

appearance: base-select arrive dans Safari 27, avec l’élément <selectedcontent>. Tout site qui a déjà déployé un <select> personnalisé pour Chrome, protégé par une détection de fonctionnalité, obtient désormais aussi la version personnalisée sur Safari. C’est le résultat voulu, et généralement un bon résultat. C’est aussi la toute première fois que ce CSS s’exécute sur Safari, et la première fois que quelqu’un le voit sur un iPhone à la largeur réelle, avec le vrai clavier, dans le vrai mode sombre. Attendez-vous à quelques rapports isolés, et considérez que « la liste déroulante a l’air différente sur mon téléphone depuis hier » est exact plutôt que confus.

Les cookies Secure sur localhost

Enfoui dans la section Réseau : Safari respecte désormais les cookies Secure sur les hôtes de bouclage. Tous les autres moteurs le font depuis des années, ce qui explique qu’un flux de connexion pouvait fonctionner dans Chrome sur localhost, échouer uniquement dans Safari, et envoyer quelqu’un passer une heure à vérifier des certificats. Cette heure-là appartient désormais au passé. Ce qu’est vraiment localhost explique le reste de pourquoi « ça marche en local » prouve moins que ce qu’on croit.

Ce que tout cela signifie pour le rapport

Chaque point ci-dessus a la même forme : la même page, se comportant d’une façon sur Safari 26.6 et d’une autre sur Safari 27.0, le même jour, pour deux personnes assises l’une à côté de l’autre. Cette forme n’est diagnosticable que si le rapport indique de laquelle des deux il provient.

La plupart des rapports ne le font pas. Les gens écrivent « Safari sur mon iPhone », et ce n’est pas leur faute : sur un iPhone, la version de Safari est celle d’iOS, elle se trouve dans Réglages sous Général puis Informations, et la mise à jour a eu lieu pendant leur sommeil. La première question à poser en retour doit donc être la version, avant les étapes de reproduction, et le moyen le moins coûteux de l’obtenir est une page qui l’affiche toute seule. La nôtre se trouve sur /tools/user-agent : elle affiche le navigateur et sa version, le système d’exploitation, la taille de l’écran et le thème clair ou sombre, et la personne qui signale le bug peut tout coller d’un coup. Elle fonctionne dans n’importe quel navigateur, car c’est indispensable.

Une limite honnête de notre côté. Session Replay est une extension Chrome. Elle ne peut pas

capturer un rapport depuis Safari, et un bug qui ne se produit que sur Safari 27 n’apparaîtra pas

sur une page ouverte dans Chrome. Ce qu’elle fait en revanche, c’est régler rapidement l’autre

moitié de la question : ouvrez la même page dans Chrome, capturez-la, et vous saurez en une minute

si le problème vient de la page ou du moteur. C’est là tout le

test cross-browser en pratique

trois moteurs, et savoir lequel vous avez sous les yeux.

Pour la moitié Safari, si vous avez un Mac, Web Inspector par câble reste la méthode, et comment inspecter un élément sur iPhone détaille la marche à suivre. Le Web Inspector de Safari 27 affiche désormais chaque requête d’une chaîne de redirections individuellement, ce qui est un petit soulagement quand le bug est une boucle de connexion.

Le reste de la version, en bref

Quelques autres points des notes de version qu’un développeur voudra connaître.

Les flux sont devenus plus simples à consommer. for await...of sur un ReadableStream, ReadableStream.from() pour en construire un à partir de n’importe quel itérable, et les flux peuvent désormais être transférés via postMessage(). Le code écrit pour Chrome qui s’appuyait sur l’un de ces points s’exécute maintenant dans Safari sans polyfill.

Les erreurs des extensions web sont désormais signalées. Les exceptions non interceptées et les rejets de promesses non gérés dans les scripts d’une extension web Safari remontent désormais, alors qu’ils disparaissaient auparavant. Si vous maintenez un portage Safari d’une extension Chrome, attendez-vous à découvrir des erreurs qu’elle traîne peut-être depuis un moment.

L’API de routage statique des service workers fait son entrée : elle permet à un service worker de déclarer à l’avance quelles requêtes le contournent, si bien que le chemin réseau d’une ressource statique n’attend plus le démarrage d’un worker.

Quatre suppressions côté SVG. SVGLocatable, SVGTransformable, nearestViewportElement, farthestViewportElement et viewTarget ont disparu, tout comme glyph-orientation-horizontal. Les anciens outils SVG qui touchaient à l’un d’eux lèveront une erreur sur Safari 27 et pas sur la 26, ce qui est un rapport de plus, propre à une version, qu’il faut savoir reconnaître.

Ce qu’il faut en retenir

Une mise à jour de navigateur est un changement en production que personne dans l’équipe n’a déployé, relu ou ne peut annuler, et il touche une fraction différente des utilisateurs chaque jour pendant une semaine. La seule parade consiste à savoir de quelle version provient chaque rapport, pour pouvoir relier « ça a commencé hier » à « Safari 27 est sorti hier » plutôt qu’au dernier déploiement.

Les notes officielles d’Apple font référence, et elles sont longues : Safari 27 Release Notes.