Version bêta de Chrome 139

Publié le 25 juin 2025

Sauf indication contraire, les modifications suivantes s'appliquent à la dernière version bêta de Chrome pour Android, ChromeOS, Linux, macOS et Windows. Pour en savoir plus sur les fonctionnalités listées ici, cliquez sur les liens fournis ou consultez la liste sur ChromeStatus.com. Chrome 139 est en version bêta depuis le 25 juin 2025. Vous pouvez télécharger la dernière version sur Google.com pour ordinateur ou sur le Google Play Store sur Android.

CSS

Cette version ajoute six nouvelles fonctionnalités CSS et d'interface utilisateur.

Court-circuit var() et attr()

Lorsque le remplacement n'est pas effectué, les fonctions var() et attr() s'évaluent sans rechercher de cycles dans ce remplacement. Le code CSS suivant fonctionne, car --green et --blue existent.

--green: green;
--blue: blue;
--a: var(--green, var(--b));
--b: var(--blue, var(--a));

Propriété CSS caret-animation

Chrome était déjà compatible avec l'animation de la propriété caret-color, mais lorsque l'animation était activée, le comportement de clignotement par défaut du curseur interférait avec l'animation. La propriété CSS caret-animation comporte deux valeurs possibles : auto et manual. auto correspond à la valeur par défaut du navigateur (clignotement), tandis que manual signifie que le développeur Web contrôle l'animation du curseur. La propriété permet également aux utilisateurs de désactiver le clignotement à l'aide d'une feuille de style utilisateur.

Mise en forme des angles

Activez la mise en forme des angles, en plus de la propriété border-radius existante, en spécifiant la forme ou la courbure de l'angle. Vous pouvez ainsi créer des formes telles que des "squircles", des encoches et des creux, et les animer. Pour en savoir plus, consultez cet article d'Amit Sheen.

Poursuivre l'exécution des transitions lors du passage à la valeur de transition initiale

Lorsque les propriétés associées à la transition changent, elles ne sont censées affecter que les transitions qui viennent de démarrer. Cela signifie que si vous modifiez les propriétés de transition, à moins de modifier également les propriétés qui comportent des animations de transition actives, ces animations de transition continueront avec la durée, le lissage de vitesse, etc. spécifiés précédemment. Blink a annulé de manière incorrecte les transitions lorsque la propriété de transition était définie sur "none", même si elle ne les annule pas si vous ne modifiez que la durée de la transition. Grâce à cette fonctionnalité, Blink sera cohérent avec WebKit et Gecko, ce qui permettra aux transitions actives de continuer à s'exécuter, sauf si la valeur de leur propriété change et déclenche une nouvelle mise à jour de la transition.

Fonctions CSS personnalisées

Les fonctions personnalisées sont semblables aux propriétés personnalisées, mais au lieu de renvoyer une seule valeur fixe, elles renvoient des valeurs basées sur d'autres propriétés personnalisées, paramètres et conditions.

@function --negate(--value) {
result: calc(var(--value) * -1);
}

div {
--gap: 1em;
margin-top: --negate(var(--gap));
}

Compatibilité avec width et height en tant qu'attributs de présentation sur les éléments <svg> imbriqués

Permet d'appliquer width et height en tant qu'attributs de présentation sur les éléments imbriqués <svg> via le balisage SVG et le CSS. Cette double approche offre une flexibilité encore plus grande, ce qui vous permet de gérer et de mettre en forme plus efficacement les éléments SVG dans des conceptions complexes.

API Web

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

Spécifiez un algorithme d'éligibilité aux mises à jour dans la spécification du fichier manifeste. Cela rend le processus de mise à jour plus déterministe et prévisible, ce qui permet aux développeurs de mieux contrôler si (et quand) les mises à jour doivent s'appliquer aux installations existantes, et de supprimer le "throttle de vérification des mises à jour" que les agents utilisateur doivent actuellement implémenter pour éviter de gaspiller des ressources réseau.

Améliorations des performances de la détection de profondeur WebXR

Expose plusieurs nouveaux mécanismes permettant de personnaliser le comportement de la fonctionnalité de détection de profondeur dans une session WebXR, dans le but d'améliorer les performances de la génération ou de la consommation du tampon de profondeur. Les principaux mécanismes exposés sont les suivants : la possibilité de demander le tampon de profondeur brut ou lissé, la possibilité de demander que l'environnement d'exécution arrête ou reprenne la fourniture du tampon de profondeur, et la possibilité d'exposer un tampon de profondeur qui ne correspond pas exactement à la vue de l'utilisateur, de sorte que l'agent utilisateur n'ait pas à effectuer de reprojections inutiles à chaque frame.

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 à comporter une grande variété de caractères et de noms valides, mais les API DOM JavaScript qui créent 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.

Commande d'appel request-close

Les éléments de boîte de dialogue peuvent être fermés par différents mécanismes. Parfois, les développeurs souhaitent pouvoir empêcher la fermeture. Pour ce faire, les boîtes de dialogue déclenchent un événement d'annulation. À l'origine, cet événement n'était déclenché que par une requête de fermeture (par exemple, en appuyant sur la touche Esc). Récemment, une fonction JS requestClose() a été ajoutée, qui déclenche également l'événement d'annulation. La commande request-close apporte cette nouvelle fonctionnalité à l'API de commandes d'appel déclaratives.

WebGPU : compatibilité avec les textures 3D pour les formats compressés BC et ASTC

Les fonctionnalités WebGPU texture-compression-bc-sliced-3d et texture-compression-astc-sliced-3d ajoutent respectivement la compatibilité avec les textures 3D pour les formats compressés BC et ASTC.

Confirmation de paiement sécurisé : clés liées au navigateur

Ajoute une signature cryptographique supplémentaire aux assertions de confirmation de paiement sécurisé et à la création d'identifiants. La clé privée correspondante n'est pas synchronisée sur tous les appareils. Cela permet aux développeurs Web de répondre aux exigences de liaison des appareils pour les transactions de paiement.

Confirmation de paiement sécurisé : actualisation de l'expérience utilisateur

Met à jour les éléments d'expérience utilisateur de la boîte de dialogue SPC sur Android Chrome. Outre la présentation de l'expérience utilisateur, les éléments suivants sont ajoutés :

  • Permet aux marchands de fournir une liste facultative de logos d'entités de paiement associés au paiement qui seront affichés.
  • Renvoie différents états de sortie au marchand selon que l'utilisateur souhaite poursuivre la transaction sans SPC ou l'annuler.
  • Ajoute un nouveau champ de libellé de détails de paiement au mode de paiement afin que le texte soit présenté sur deux lignes.

WebGPU core-features-and-limits

La fonctionnalité core-features-and-limits indique qu'un adaptateur et un appareil WebGPU sont compatibles avec les fonctionnalités et les limites de base de la spécification.

Correction du candidat prioritaire d'ancrage de défilement

Actuellement, l'algorithme d'ancrage de défilement sélectionne les candidats prioritaires lorsqu'ils sont disponibles en tant que cibles d'ancrage. Les candidats prioritaires sont actuellement un élément modifiable sélectionné et des surlignages de recherche sur la page. Cela peut entraîner une expérience utilisateur sous-optimale s'il existe un grand élément contenteditable sélectionné dont le contenu a été modifié hors écran (le curseur finit par être décalé). Cette correction modifie l'algorithme : au lieu de sélectionner le candidat prioritaire comme ancre, utilisez le candidat comme champ d'application ou racine de l'algorithme de sélection d'ancres standard qui sélectionne l'élément à l'écran le plus profond comme ancre.

Compatibilité avec l'attribut async pour les éléments <script> SVG

L'interface SVGScriptElement dans SVG 2.0 introduit l'attribut async, semblable à HTMLScriptElement. Cet attribut permet d'exécuter des scripts de manière asynchrone, ce qui améliore les performances et la réactivité des applications Web qui utilisent SVG.

API Web Speech sur l'appareil

Cette fonctionnalité ajoute la compatibilité avec la reconnaissance vocale sur l'appareil à l'API Web Speech, ce qui permet aux sites Web de s'assurer qu'aucun contenu audio ni aucune transcription vocale ne sont envoyés à un service tiers pour traitement. Les sites Web peuvent interroger la disponibilité de la reconnaissance vocale sur l'appareil pour des langues spécifiques, inviter les utilisateurs à installer les ressources nécessaires pour la reconnaissance vocale sur l'appareil et choisir entre la reconnaissance vocale sur l'appareil ou dans le cloud, selon les besoins.

Supprimer window.name pour les navigations intersites qui changent de groupe de contexte de navigation

La valeur de la propriété window.name est actuellement conservée tout au long de la durée de vie d'un onglet, même en cas de navigation qui change de groupe de contexte de navigation, ce qui peut entraîner une fuite d'informations et être potentiellement utilisé comme vecteur de suivi. La suppression de la propriété window.name résout ce problème. Il s'agit d'une modification à faible risque, car la recherche d'un contexte de navigation par nom ne fonctionne déjà pas s'il se trouve dans un autre groupe de contexte de navigation. Le nom n'est donc pas réellement utile.

Règle d'entreprise : ClearWindowNameCrossSiteBrowsing (ne fonctionnera plus dans Chrome 142).

Extensions de champ d'application des applications Web

Ajoute un champ de fichier manifeste d'application Web "scope_extensions" qui permet aux applications Web d'étendre leur champ d'application à d'autres origines.

Cela permet aux sites qui contrôlent plusieurs sous-domaines et domaines de premier niveau d'être présentés comme une seule application Web. Les origines listées doivent confirmer leur association à l'application Web à l'aide d'un fichier de configuration .well-known/web-app-origin-association.

Détection du type MIME JSON conforme aux spécifications

Chromium reconnaît désormais tous les types MIME JSON valides, tels que définis par la spécification WHATWG mimesniff. Cela inclut tous les types MIME dont le sous-type se termine par +json, en plus des types traditionnels application/json et text/json. Cette modification garantit que les API Web et les fonctionnalités qui s'appuient sur la détection JSON se comportent de manière cohérente avec la norme de la plate-forme Web et d'autres navigateurs. L'une des principales motivations de cette modification est de corriger le comportement d'importation des modules JSON, où les types MIME JSON précédemment valides tels que text/html+json et image/svg+json ne pouvaient pas être chargés en tant que modules.

API Private Aggregation : création de rapports d'erreur agrégés

L'utilisation de l'API Private Aggregation peut entraîner diverses conditions d'erreur. Par exemple, le budget de confidentialité peut être épuisé, ce qui empêche toute contribution supplémentaire à l'histogramme. Cette fonctionnalité permet aux développeurs d'enregistrer des contributions à l'histogramme qui ne doivent être envoyées que si un type d'erreur particulier se produit. Cette fonctionnalité permet de mesurer la fréquence des conditions d'erreur et de diviser ces mesures en fonction des dimensions spécifiées par le développeur (par exemple, la version du code déployé). Comme les erreurs elles-mêmes peuvent être des informations intersites, nous ne pouvons pas simplement les exposer à la page pour les utilisateurs sans cookies tiers. Au lieu de cela, cette fonctionnalité réutilise les pipelines de création de rapports agrégés existants via le service d'agrégation.

API Crash Reporting : spécifiez la création de rapports d'erreur pour ne recevoir que des rapports d'erreur

Cette fonctionnalité permet aux développeurs de ne recevoir que des rapports d'erreur en spécifiant le point de terminaison nommé crash-reporting. Par défaut, les rapports d'erreur sont envoyés au point de terminaison default, qui reçoit de nombreux autres types de rapports en plus des rapports d'erreur. Les développeurs peuvent fournir une URL distincte au point de terminaison connu nommé crash-reporting pour y diriger les rapports d'erreur au lieu du point de terminaison default.

Réduire l'empreinte numérique dans les informations d'en-tête Accept-Language

Réduit la quantité d'informations que la chaîne de valeur d'en-tête Accept-Language expose dans les requêtes HTTP et dans navigator.languages. Au lieu d'envoyer une liste complète des langues préférées de l'utilisateur dans chaque requête HTTP avec l'en-tête Accept-Language. Nous envoyons désormais la langue préférée de l'utilisateur dans l'en-tête Accept-Language. Pour minimiser les risques de compatibilité, le lancement initial réduit les informations dans l'en-tête HTTP. Nous réduirons les getters JavaScript navigator.languages associés à l'avenir.

Générer un événement d'erreur au lieu de générer pour un worker bloqué par CSP

Lorsqu'il est bloqué par la Content Security Policy (CSP), Chrome génère actuellement une exception SecurityError à partir du constructeur de Worker et de SharedWorker. La spécification exige que la CSP soit vérifiée lors de la récupération et déclenche des événements d'erreur de manière asynchrone au lieu de générer une exception lorsqu'un script exécute new Worker(url) ou new SharedWorker(url). Cette modification rend Chrome conforme aux spécifications : elle ne génère pas d'exception lors du constructeur et déclenche des événements d'erreur de manière asynchrone.

Niveau audio pour les frames encodés RTC

Expose au Web le niveau audio d'un frame encodé transmis avec RTCPeerConnection et exposé à l'aide de WebRTC Encoded Transform.

Nouvelles phases d'évaluation

Dans Chrome 139, vous pouvez activer les nouvelles phases d'évaluation origin trials suivantes.

API Prompt

L'API Prompt est conçue pour interagir avec un modèle de langage d'IA à l'aide d'entrées textuelles, d'images et audio. Elle prend en charge différents cas d'utilisation, comme la génération de légendes d'images et l'exécution de recherches visuelles, la transcription de contenus audio, la classification d'événements sonores, la génération de texte en suivant des instructions spécifiques et l'extraction d'informations ou d'insights à partir de texte. Elle est compatible avec les sorties structurées, qui garantissent que les réponses respectent un format prédéfini, généralement exprimé sous forme de schéma JSON. Cela permet d'améliorer la conformité des réponses et de faciliter l'intégration parfaite aux applications en aval qui nécessitent des formats de sortie standardisés. Cette API est également exposée dans les extensions Chrome. Cette phase d'évaluation est destinée à l'exposition sur le Web.

Attribut de blocage du rendu à fréquence d'images complète

Nous proposons d'ajouter un nouveau jeton de blocage du rendu à fréquence d'images complète aux attributs de blocage. Lorsque le moteur de rendu est bloqué avec le jeton à fréquence d'images complète, il fonctionne à une fréquence d'images inférieure afin de réserver davantage de ressources pour le chargement.

Mode de compatibilité WebGPU

Ajoute un sous-ensemble facultatif et légèrement restreint de l'API WebGPU capable d'exécuter des API graphiques plus anciennes telles qu'OpenGL et Direct3D11. En activant ce mode et en respectant ses contraintes, les développeurs peuvent étendre la portée de leurs applications WebGPU à de nombreux appareils plus anciens qui ne disposent pas des API graphiques modernes et explicites requises par WebGPU. Pour les applications simples, la seule modification requise consiste à spécifier le niveau de fonctionnalité "compatibility" lors de l’appel requestAdapter. Pour les applications plus avancées, certaines modifications peuvent être nécessaires pour tenir compte des restrictions du mode. Étant donné que le mode de compatibilité est un sous-ensemble, les applications résultantes sont également des applications WebGPU Core valides et s'exécuteront même sur les agents utilisateur qui ne sont pas compatibles avec le mode de compatibilité.

Obsolescence et suppression

Cette version de Chrome introduit les obsolescences et les suppressions listées ci-dessous. Consultez ChromeStatus.com pour obtenir la liste des obsolescences prévues, des obsolescences actuelles et des suppressions précédentes.

Cette version de Chrome supprime deux fonctionnalités.

Supprimer la compatibilité avec macOS 11

Chrome 138 est la dernière version compatible avec macOS 11. À partir de Chrome 139, macOS 11 n'est plus compatible, car il n'est plus pris en charge par Apple. Exécuter un système d'exploitation compatible est essentiel pour assurer la sécurité. Sur les Mac exécutant macOS 11, Chrome continuera de fonctionner et affichera une barre d'informations avec un avertissement, mais ne sera plus mis à jour. Si un utilisateur souhaite mettre à jour Chrome, il doit installer une version compatible de macOS sur son ordinateur. Pour les nouvelles installations de Chrome 139 ou version ultérieure, vous devrez disposer de macOS 12 ou d'une version ultérieure.

Supprimer la détection automatique du jeu de caractères ISO-2022-JP en HTML

Des problèmes de sécurité connus sont liés à la détection automatique du jeu de caractères pour ISO-2022-JP. Étant donné que l'utilisation est très faible et que Safari n'est pas compatible avec la détection automatique d'ISO-2022-JP, Chrome supprime sa compatibilité pour éliminer les problèmes de sécurité.