Version bêta de Chrome 143

Rachel Andrew

Publié le 29 octobre 2025

Sauf indication contraire, ces modifications s'appliquent à la version bêta de Chrome 143 pour Android, ChromeOS, Linux, macOS et Windows. Pour en savoir plus sur ces fonctionnalités, consultez les liens fournis ou ChromeStatus.com. Téléchargez la version bêta de Chrome 143 sur Google.com pour ordinateur ou sur le Google Play Store pour Android.

CSS et UI

Requêtes de conteneur de secours ancrées CSS

Cette fonctionnalité introduit @container anchored(fallback) pour styliser les descendants des éléments positionnés par ancrage en fonction de la valeur position-try-fallbacks appliquée.

Par exemple, vous pouvez utiliser ces requêtes pour styliser l'attache ou les animations d'un élément ancré en fonction de la position de l'ancre et de l'élément ancré les uns par rapport aux autres.

Exemple :

#anchored {
 position-try-options: flip-block;
 container-type: anchored;
}

@container anchored(fallback: flip-block) {
  #anchored > .arrow {
    --arrow-rotation: 180deg;
   }
}

Pour en savoir plus, consultez Détecter les positions de secours avec les requêtes de conteneur ancrées à partir de Chrome 143.

EditContext : TextFormat underlineStyle et underlineThickness

Chromium a déployé l'API EditContext avec un bug qui fait que l'objet TextFormat, fourni par EditContext/textformatupdate_event, fournit des valeurs incorrectes pour les propriétés underlineStyle et underlineThickness. Dans Chromium, les valeurs possibles sont None, Solid, Dotted, Dashed, Squiggle et None, Thin, Thick. Toutefois, selon les spécifications EditContext, elles doivent être none, solid, dotted, dashed, wavy et none, thin, thick.

API Web

Autoriser plus de caractères dans les API DOM JavaScript

L'analyseur HTML a toujours (ou depuis longtemps) autorisé les éléments et les attributs à avoir une grande variété de caractères et de noms valides, mais les API DOM JavaScript pour créer les mêmes éléments et attributs sont plus strictes et ne correspondent pas à l'analyseur.

Cette modification assouplit la validation des API DOM JavaScript pour qu'elle corresponde à l'analyseur HTML.

Pour en savoir plus, consultez github.com/whatwg/dom/issues/849.

Cette modification ne devrait pas entraîner de problèmes de compatibilité, car tous les noms d'éléments et d'attributs précédemment autorisés restent valides avec le nouveau comportement.

Règles de spéculation : amélioration de l'eagerness "eager" sur mobile

Sur mobile, les règles de préchargement et de prérendu spéculatives pour l'eagerness "eager" se déclenchent désormais lorsque les éléments d'ancrage HTML se trouvent dans la fenêtre d'affichage pendant une courte période.

Auparavant, la prélecture et le prérendu commençaient dès que possible, ce qui équivalait à un niveau d'empressement "immédiat". Ce comportement mis à jour est plus utile, car il reflète mieux l'intention de l'auteur d'être plus impatient que "modéré" et moins impatient qu'"immédiat".

Implémenter la propriété CSS font-language-override

Cette fonctionnalité permet de prendre en charge la propriété CSS font-language-override dans Chromium. Cette propriété permet aux développeurs de remplacer la langue du système utilisée pour la substitution de glyphes OpenType en spécifiant un tag de langue de quatre caractères directement dans le CSS.

Cela permet un contrôle typographique précis, ce qui est utile pour les contenus multilingues ou les polices avec des variantes de glyphes spécifiques à une langue.

WebGPU : permutation des composants de texture

Le swizzle des composants de texture permet à GPUTextureViews de réorganiser ou de remplacer les composants de couleur des canaux rouge, vert, bleu ou alpha d'une texture lorsqu'un nuanceur y accède.

ICU 77 (compatible avec Unicode 16)

La bibliothèque ICU (International Components for Unicode) de compatibilité Unicode passe de la version 74.2 à la version 77.1, ce qui ajoute la compatibilité avec Unicode 16 et met à jour les données de paramètres régionaux. Deux modifications peuvent présenter un risque pour les applications Web qui supposent un format spécifique des API JavaScript Intl :

• Le format de nombre italien par défaut omet désormais le séparateur de milliers pour les nombres à quatre chiffres. Par exemple, new Intl.NumberFormat("it").format(1234) renvoie "1234" au lieu de "1.234". Vous pouvez obtenir l'ancien comportement avec le paramètre useGrouping pour le constructeur Intl.NumberFormat.
• Dans certaines langues anglaises (par exemple, en-AU, en-GB et en-IN), une virgule a été ajoutée après les jours de la semaine écrits en toutes lettres, ce qui a transformé "Saturday 30 April 2011" en "Saturday, 30 April 2011". Les applications Web doivent éviter de s'appuyer sur la mise en forme précise des dates.
• Intl et RegExp (V8) : de nombreuses petites modifications. La modification du format des nombres italiens présente le risque le plus élevé et dispose d'un indicateur dédié.
• IDNA : cette mise à niveau permet généralement d'effectuer plus d'actions et améliore les résultats globaux des tests dans WPT.
• Segmentation du texte : le changement le plus notable est l'amélioration du retour à la ligne en japonais lors de l'utilisation de word-break: auto-phrase. Cela concerne https://chromestatus.com/feature/5133892532568064.

Propriété DataTransfer pour les événements d'entrée insertFromPaste, insertFromDrop et insertReplacementText

Cette fonctionnalité remplit la propriété dataTransfer des événements d'entrée avec inputType de insertFromPaste, insertFromDrop et insertReplacementText. Cela permet d'accéder aux données du presse-papiers et du glisser-déposer lors des opérations de modification dans les éléments contenteditable.

L'objet dataTransfer contient les mêmes données que celles disponibles lors de l'événement beforeinput.

Cette fonctionnalité ne s'applique qu'aux éléments contenteditable. Pour les contrôles de formulaire (textarea, input), le comportement reste inchangé : la propriété data contient le texte inséré et dataTransfer reste nul. Safari et Firefox sont déjà compatibles avec cette fonctionnalité. L'adoption de cette fonctionnalité par Chrome améliore l'interopérabilité entre les navigateurs, offrant une expérience plus cohérente aux auteurs Web.

FedCM : prise en charge des réponses JSON structurées des IdP

Cette fonctionnalité permet aux fournisseurs d'identité (IdP) de renvoyer des objets JSON structurés au lieu de chaînes brutes aux parties de confiance (RP) via id_assertion_endpoint.

Cette modification simplifie l'intégration pour les développeurs en éliminant la nécessité de sérialiser et d'analyser manuellement les chaînes JSON. Il fournit des flux d'authentification plus dynamiques et flexibles, permettant aux RP d'interpréter directement les réponses complexes et de prendre en charge divers protocoles tels qu'OAuth2, OIDC ou IndieAuth sans accords hors bande.

Négociation du protocole d'application WebTransport

La négociation du protocole d'application WebTransport vous permet de négocier le protocole utilisé par l'application Web lors du handshake WebTransport.

Une application Web peut spécifier une liste de protocoles d'application lors de la construction d'un objet WebTransport. Ces protocoles sont ensuite transmis au serveur via des en-têtes HTTP. Si le serveur choisit l'un de ces protocoles, il peut l'indiquer dans les en-têtes de réponse. Cette réponse est disponible dans l'objet WebTransport.

API Web Smart Card pour les applications Web isolées

Disponible uniquement dans les applications Web isolées (AWI). Cette fonctionnalité permet aux applications de carte à puce (PC/SC) de passer à la plate-forme Web. Il leur donne accès à l'implémentation PC/SC (et aux pilotes de lecteur de carte) disponibles dans le système d'exploitation hôte.

Les administrateurs peuvent contrôler la disponibilité de cette API de deux manières :

• Au niveau mondial, à l'aide de la règle DefaultSmartCardConnectSetting
• Par application : à l'aide des règles SmartCardConnectAllowedForUrls et SmartCardConnectBlockedForUrls

Fichier manifeste d'application Web : spécifiez l'éligibilité aux mises à jour, les URL d'icône sont Cache-Control: immutable

La spécification du fichier manifeste inclut désormais un algorithme d'éligibilité aux mises à jour. Cela rend le processus de mise à jour plus déterministe et prévisible, ce qui permet aux développeurs de mieux contrôler le moment où les mises à jour s'appliquent aux installations existantes. Les utilisateurs ont également plus de choix quant à la manière de gérer une mise à jour (par exemple, ils peuvent l'ignorer s'ils le souhaitent). Il permet également de supprimer la "limitation de la vérification des mises à jour" que les agents utilisateur implémentent pour éviter de gaspiller les ressources réseau.

Intervention sur les annonces lourdes : rapports envoyés au frame d'intégration

Les rapports sur les interventions publicitaires sont désormais envoyés au frame d'intégration de l'annonce, en plus du frame de l'annonce lui-même. Le rapport envoyé au frame d'intégration contiendra l'ID de l'iframe de l'annonce et l'URL de pré-redirection du frame qui a été déchargé dans le champ de message du corps du rapport. Ce changement permet au contexte d'intégration d'identifier les fournisseurs d'annonces problématiques et de traiter les annonces intrusives afin d'améliorer l'expérience utilisateur.

Phases d'évaluation en cours

Dans Chrome 143, vous pouvez activer les nouvelles versions d'essai d'origine suivantes.

API Digital Credentials (prise en charge de l'émission)

Cette fonctionnalité permet aux sites Web émetteurs (par exemple, une université, un organisme gouvernemental ou une banque) d'initier le processus de provisionnement (émission) des identifiants numériques de manière sécurisée directement dans l'application de portefeuille mobile d'un utilisateur. Sur Android, cette fonctionnalité utilise le système Android IdentityCredential CredMan (Gestionnaire d'identifiants). Sur ordinateur, il utilise des approches multi-appareils avec le protocole CTAP, semblables au flux multi-appareils de présentation des identifiants numériques.

Randomisation de la limite du pool de sockets TCP

En exploitant les limites de la taille du pool de connexions sur Chrome, vous pouvez obtenir des informations sur l'état multisite qui seraient autrement inaccessibles. Plus précisément, vous pouvez (avec une certaine certitude statistique) évaluer l'état de connexion, l'historique des visites ou même quelque chose de plus spécifique, comme le fait de savoir si Gmail a des messages en attente dans la boîte de réception.

Pour atténuer ce problème, une randomisation est ajoutée à la façon dont les pools de sockets TCP sont limités, de sorte qu'un site d'observation ne puisse pas déduire ces informations avec une grande certitude.

Arrêts et suppressions

Cette version de Chrome introduit les abandons et les suppressions décrits dans les sections suivantes. Consultez ChromeStatus.com pour obtenir la liste des fonctionnalités dont l'arrêt est prévu, de celles qui sont actuellement arrêtées et de celles qui ont été supprimées.

Cette version de Chrome abandonne deux fonctionnalités.

Abandon des getters dans Intl Locale Info

L'API Intl Locale Info est une proposition ECMAScript TC39 de phase 3 visant à améliorer l'objet Intl.Locale en exposant des informations sur les paramètres régionaux, telles que les données relatives aux semaines (premier jour de la semaine, jour de début du week-end, jour de fin du week-end, valeur minimale du jour de la première semaine), l'orientation du texte et le cycle horaire utilisé dans les paramètres régionaux.

L'implémentation a été déployée dans Chrome 99. Cependant, la proposition a été modifiée par la suite dans la phase 3 et plusieurs getters ont été déplacés dans des fonctions. Les getters obsolètes doivent être supprimés et les fonctions renommées relancées.

Abandonner XSLT

XSLT v1.0, auquel tous les navigateurs adhèrent, a été normalisé en 1999. Entre-temps, XSLT a évolué vers les versions 2.0 et 3.0, ajoutant des fonctionnalités et s'éloignant de la version implémentée dans les navigateurs. Ce manque de progrès, associé à l'essor des bibliothèques et frameworks JavaScript qui offrent une manipulation flexible et puissante du DOM, a entraîné une baisse significative de l'utilisation de XSLT côté client. Les technologies basées sur JavaScript, telles que JSON et React, ont largement remplacé son rôle dans le navigateur Web.

Chromium utilise la bibliothèque libxslt pour traiter ces transformations, mais libxslt n'a pas été maintenue pendant environ six mois en 2025. Libxslt est une base de code C complexe et ancienne, sujette à des failles de sécurité au niveau de la mémoire, comme les dépassements de mémoire tampon, qui peuvent entraîner l'exécution de code arbitraire. Étant donné que la transformation XSLT côté client est désormais une fonctionnalité de niche rarement utilisée, ces bibliothèques font l'objet d'une maintenance et d'un examen de sécurité moins poussés que les moteurs JavaScript principaux. Toutefois, ils représentent une surface d'attaque directe pour le traitement de contenu Web non approuvé. En effet, XSLT est à l'origine de plusieurs failles de sécurité très médiatisées qui continuent de mettre en danger les utilisateurs de navigateurs.

Pour ces raisons, Chromium prévoit d'abandonner et de supprimer XSLT de la plate-forme Web. Le WHATWG a décidé de poursuivre l'abandon de XSLT.

Pour en savoir plus sur l'abandon et sur ce que vous devez faire si vous utilisez XSLT, consultez Suppression de XSLT pour un navigateur plus sécurisé.