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, cliquez sur les liens fournis ou consultez 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 en CSS

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

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

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 publié l'API EditContext avec un bug : 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, conformément à la spécification EditContext, elles doivent être none, solid, dotted, dashed, wavy et none, thin, thick.

API Web

Autoriser davantage 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 permettant de 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'elles correspondent à 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éliorations de l'empressement "eager" sur mobile

Sur mobile, les règles de spéculation de préchargement et de prérendu pour l'empressement "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, le préchargement et le prérendu démarraient dès que possible, ce qui équivalait à un empressement "immediate". Ce comportement mis à jour est plus utile, car il reflète mieux l'intention de l'auteur d'être plus empressé que "moderate" et moins empressé que "immediate".

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

Cette fonctionnalité introduit la prise en charge de 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 une balise de langue à 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 à la langue.

WebGPU : permutation des composants de texture

La permutation des composants de texture permet aux GPUTextureViews de réorganiser ou de remplacer les composants de couleur des canaux rouge, vert, bleu ou alpha d'une texture lorsqu'un shader y accède.

ICU 77 (compatible avec Unicode 16)

La bibliothèque de support Unicode ICU (International Components for Unicode) a été mise à niveau de la version 74.2 à la version 77.1. Elle inclut désormais la prise en charge d'Unicode 16 et la mise à jour des données relatives aux paramètres régionaux. Deux modifications peuvent poser problème pour les applications Web qui reposent sur un format spécifique des API Intl JavaScript :

• La mise en forme par défaut des nombres en italien ne comporte plus de 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 certains paramètres régionaux anglais (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. Par exemple, "Saturday 30 April 2011" devient "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) : nombreuses petites modifications. La modification de la mise en forme des nombres en italien présente le risque le plus élevé et dispose d'un indicateur dédié.
• IDNA : cette mise à niveau permet généralement plus de choses et améliore les résultats globaux des tests dans WPT.
• Segmentation du texte : la modification la plus notable est l'amélioration du saut de ligne en japonais lors de l'utilisation de word-break: auto-phrase. Cela est lié à 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 commandes de formulaire (textarea, input), le comportement reste inchangé : la propriété data contient le texte inséré et dataTransfer reste nulle. 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 ainsi 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 simples aux parties utilisatrices (RP) via le 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. Elle offre des flux d'authentification plus dynamiques et flexibles, permettant aux RP d'interpréter directement les réponses complexes et de prendre en charge différents protocoles tels qu'OAuth2, OIDC ou IndieAuth sans accord hors bande.

Négociation du protocole d'application WebTransport

La négociation du protocole d'application WebTransport vous permet de négocier le protocole fusionné par l'application Web dans le 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 en choisit un, il peut l'indiquer dans les en-têtes de réponse, et cette réponse est disponible dans l'objet WebTransport.

API Web Smart Card pour les applications Web isolées

Disponible uniquement sur les applications Web isolées (IWA). Cette fonctionnalité permet aux applications de carte à puce (PC/SC) de passer à la plate-forme Web. Elle 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 :

• Globalement : à 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 à ce qu'ils peuvent faire avec une mise à jour, par exemple l'ignorer s'ils le souhaitent. Cela permet également de supprimer le "throttle de vérification des mises à jour" que les agents utilisateur implémentent pour éviter de gaspiller des ressources réseau.

Intervention sur les annonces gourmandes en ressources : rapports envoyés au frame d'intégration

Les rapports d'intervention sur les annonces 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 contient 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. Cette modification 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.

Essais d'origine en cours

Dans Chrome 143, vous pouvez activer les nouveaux essais d'origine suivants.

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) de lancer de manière sécurisée le processus de provisionnement (émission) d'identifiants numériques directement dans l'application de portefeuille mobile d'un utilisateur. Sur Android, cette fonctionnalité utilise le système Android IdentityCredential CredMan (Credential Manager). Sur ordinateur, elle utilise des approches inter-appareils avec le protocole CTAP, semblables au flux inter-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 intersites 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, par exemple 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.

Abandons et suppressions

Cette version de Chrome introduit les abandons et les suppressions dans les sections suivantes. Consultez ChromeStatus.com pour obtenir la liste des abandons prévus, des abandons actuels et des suppressions précédentes.

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é publiée dans Chrome 99. Toutefois, la proposition a ensuite été modifiée en phase 3 et plusieurs getters ont été déplacés vers des fonctions. Les getters obsolètes doivent être supprimés et les fonctions renommées relancées.

Abandon de XSLT

Le langage XSLT v1.0, auquel tous les navigateurs se conforment, a été normalisé en 1999. Entre-temps, XSLT a évolué vers les versions 2.0 et 3.0 qui intègrent de nouvelles fonctionnalités, s'éloignant ainsi de la version implémentée dans les navigateurs. Ce manque d'évolution, associé à l'essor des bibliothèques et frameworks JavaScript qui offrent une manipulation du DOM flexible et puissante, a entraîné une baisse significative de l'utilisation de XSLT côté client. Son rôle dans le navigateur Web a été largement supplanté par des technologies basées sur JavaScript, telles que JSON et React.

Chromium utilise la bibliothèque libxslt pour gérer ces transformations, or sa maintenance n'est plus assurée depuis environ six mois en 2025. Libxslt est un codebase C complexe et vieillissant, susceptible d'être exposé à des failles de sécurité liées à la mémoire telles que les dépassements de tampon, qui peuvent entraîner l'exécution de code arbitraire. Étant donné que XSLT côté client est désormais une fonctionnalité de niche rarement utilisée, ces bibliothèques font l'objet de moins de maintenance et d'examens de sécurité que les moteurs JavaScript principaux. Pourtant, elles représentent une surface d'attaque directe pour le traitement de contenus Web non fiables. En effet, XSLT est à l'origine de plusieurs failles de sécurité récentes 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. WHATWG a décidé d'avancer l'abandon de XSLT.

Pour en savoir plus sur l'abandon et sur ce qu'il faut faire si vous utilisez XSLT, consultez Supprimer XSLT pour un navigateur plus sécurisé.