IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Chrome 89 bêta : Google poursuit ses efforts en matière « d'interactions matérielles avancées »
Que Mozilla et Apple considèrent comme nuisibles

Le , par Bill Fassinou

96PARTAGES

2  0 
À la suite de la sortie de Chrome 88, Google a publié la version bêta de Chrome 89 pour permettre aux développeurs de faire des tests. La version bêta de Chrome 89 comporte de nombreux ajouts, en particulier de nouvelles API Web et d'autres nouveautés notables que les développeurs Web peuvent commencer à utiliser. Les nouvelles fonctionnalités comprennent plusieurs API d'interaction avec le matériel, par exemple, Chrome 89 bêta embarque une API de partage de bureau pour Windows et Chrome OS, mais Mozilla et Apple considèrent que nombre de ces fonctionnalités sont nuisibles.

Chrome 89 est entré en version bêta le 28 janvier dernier et Google l'a publié aussitôt. Si Google respecte son calendrier, Chrome 89 devrait être stable dans environ un mois, début mars. En attendant, voici un aperçu détaillé des fonctionnalités de la nouvelle version bêta.

Ajout de l'API WebHID permettant d'accéder aux dispositifs HID

Selon l'équipe de Google Chromium, il existe une longue liste de périphériques d'interface humaine (HID - Human interface devices) qui sont trop récents, trop anciens ou trop peu courants pour être accessibles par les pilotes des systèmes. L'API WebHID résout ce problème en fournissant un moyen d'implémenter une logique spécifique à l'appareil en JavaScript. Un dispositif d'interface humaine est un dispositif qui prend des données d'entrée ou fournit des données de sortie aux humains. Les claviers, les dispositifs de pointage (souris, écrans tactiles, etc.) et les manettes de jeu sont des exemples de périphériques.



L'impossibilité d'accéder à des dispositifs HID peu communs ou inhabituels est particulièrement pénible, par exemple, en ce qui concerne la prise en charge des manettes de jeu. Les entrées et sorties des gamepads ne sont pas bien normalisées et les navigateurs Web exigent souvent une logique personnalisée pour des dispositifs spécifiques. Cette situation n'est pas viable et se traduit par une mauvaise prise en charge de la longue queue des appareils anciens et peu courants. WebHID était auparavant disponible dans Chrome en tant qu'essai d'origine, mais est maintenant activé par défaut sur le bureau.

En gros, la principale motivation de WebHID a été de mieux supporter les gamepads dans les navigateurs. Il permet aux développeurs d'écrire du JavaScript pour communiquer avec des appareils tels que des contrôleurs de jeu ou des claviers en utilisant une logique spécifique à l'appareil, plutôt que de s'appuyer sur les appareils pour mettre en œuvre des API standard comme l'API Gamepad.

Web NFC pour la transmission de données sur une courte portée

NFC (Near Field Communications) est une technologie sans fil à courte portée pour la transmission de petites quantités de données, généralement entre un appareil NFC spécialisé et un lecteur. Si vous avez scanné un badge pour entrer dans un bâtiment, vous avez peut-être déjà utilisé la technologie NFC. Web NFC permet à une application Web de lire et d'écrire sur des badges NFC lorsqu'ils sont rapprochés de l'appareil de l'utilisateur (généralement de 5 à 10 cm, 2 à 4 pouces). La portée actuelle est limitée à NDEF, un format de message binaire léger.

Les opérations d'E/S de bas niveau (par exemple : ISO-DEP, NFC-A/B, NFC-F) et l'émulation de carte basée sur l'hôte (HCE) ne sont pas prises en charge dans le cadre actuel. Selon la firme de Mountain View, Web NFC ouvre de nouvelles possibilités d'utilisation du Web, notamment la fourniture d'informations sur les expositions des musées, la gestion des stocks, la fourniture d'informations dans un badge de conférence, et bien d'autres encore. Google a annoncé que dans Chrome 89 sur Android, le Web NFC est activé par défaut.

L'API Web Serial : une interface de communication bidirectionnelle

Une autre nouveauté est l'API Web Serial. Il s'agit d'un port série, c'est-à-dire une interface de communication bidirectionnelle qui permet d'envoyer et de recevoir des données octet par octet. L'API Web Serial apporte cette capacité aux sites Web, en leur permettant de contrôler des appareils dotés de ports série, notamment des microcontrôleurs et des imprimantes 3D. En effet, l'équipe Chromium estime que dans les milieux éducatifs, les loisirs et l'industrie, les périphériques sont déjà contrôlés par des pages Web. Dans tous ces cas, le contrôle des périphériques nécessite l'installation d'adaptateurs et de pilotes.

L'API Web Serial améliore l'expérience de l'utilisateur en permettant une communication directe entre un site Web et un périphérique. Elle vient ainsi s'ajouter à l'API WebUSB, qui est prise en charge depuis Chrome 61, mais qui n'est pas supportée dans Firefox ou Safari pour des raisons de sécurité et de confidentialité. Son essai d'origine est terminé et l'API Web Serial est maintenant activée sur le bureau. Une démo est disponible sur GitHub.

Ajout de l'API de partage de sites Web sur le bureau

Pourquoi cet ajout ? L'équipe a expliqué que, afin de permettre aux utilisateurs de partager facilement du contenu sur les réseaux sociaux, les développeurs ont intégré manuellement des boutons de partage dans leur site pour chaque service social. Cela conduit souvent à ce que les utilisateurs ne puissent pas partager avec les services qu'ils utilisent réellement, en plus des tailles de page gonflées et des risques de sécurité liés au code tiers. En ce qui concerne la réception, seules les applications de la plateforme pouvaient s'inscrire pour être des cibles de partage et recevoir des parts d'autres applications.

Ainsi, les API de partage Web déjà intégrées à Chrome sur Android (entre Chrome 61 et 75) ont été ajoutées sur Windows et Chrome OS. L'idée est de remplacer les petits boutons que les sites Web optimistes affichent pour le partage de contenu sur Twitter, Facebook et autres, par un seul bouton de partage qui appelle la fonction de partage du système d'exploitation. Dans Chrome 89, le partage Web est disponible sur Windows et ChromeOS, tandis que l'enregistrement en tant que cible de partage est pris en charge sur ChromeOS.

Sur ces plateformes, les sites peuvent désormais utiliser navigator.share() sur le bureau pour déclencher une boîte de dialogue de partage. Et une entrée dans le manifeste de l'application Web permet à un PWA d'agir en tant que cible de partage. Cette fonction permet également de partager des fichiers tels que des images ou des documents en texte brut (la gamme des extensions de fichiers prises en charge est limitée). Firefox ne prend pas en charge le partage Web, mais il est disponible dans Microsoft Edge (81 et plus) et Safari (12.1 et plus sur macOS, 12.2 sur iOS).

Des API utiles, mais qui ajoutent de nouveaux vecteurs d'attaque

Selon les critiques, la prise en charge améliorée des appareils dans Chrome comble le fossé entre les applications Web et natives, mais augmente également la surface d'attaque potentielle. La position actuelle des normes de Mozilla sur l'API WebUSB, par exemple, est qu'elle est nuisible. « De nombreux dispositifs USB ne sont pas conçus pour gérer des interactions potentiellement malveillantes sur les protocoles USB et ces dispositifs peuvent avoir des effets importants sur l'ordinateur auquel ils sont connectés », a déclaré Mozilla par rapport à l'API WebUSB.

« Nous pensons que les risques de sécurité liés à l'exposition des dispositifs USB au Web sont trop vastes pour risquer d'y exposer les utilisateurs ou pour expliquer correctement aux utilisateurs finaux comment obtenir un consentement éclairé valable », a-t-il ajouté. Parmi les autres API considérées comme nuisibles par Mozilla figurent l'API Web Serial et l'API Web NFC. La difficulté est que lorsque les utilisateurs trouvent des fonctionnalités prises en charge par Chrome qui ne fonctionnent pas dans Mozilla Firefox, ils peuvent simplement considérer Firefox comme cassé et cela devient un autre facteur de la domination de Chrome.

À titre d'exemple, concernant WebADB, une application qui permet d'accéder à l'API de débogage Android à partir d'un navigateur, Mozilla juge qu'il est difficile d'expliquer aux utilisateurs qu'une fonctionnalité peut manquer pour leur protection. L'équipe WebKit d'Apple est également opposée à bon nombre de ces API, notamment Web NFC, WebHID, Web Serial et WebUSB, en raison de problèmes d'empreintes digitales, de sécurité et autres.

Autres fonctionnalités de cette version introduites dans Chrome 89

Décodage d'images AVIF

Chrome prend désormais en charge le décodage du contenu AVIF en utilisant nativement les décodeurs AV1 existants sur Android et WebView. (La prise en charge du bureau a été ajoutée dans Chrome 85.) L'AVIF est un format d'image de nouvelle génération normalisé par l'Alliance for Open Media. Selon l'équipe Chromium, il y a trois motivations principales ayant conduit au support natif de l'AVIF :

  • réduire la consommation de bande passante pour charger les pages plus rapidement et réduire la consommation globale de données. L'AVIF offrirait une réduction significative de la taille des fichiers d'images par rapport aux formats JPEG ou WebP ;
  • l'ajout de la prise en charge des couleurs HDR. L'AVIF est une voie vers la prise en charge des images HDR pour le Web. En pratique, le JPEG est limité à une profondeur de couleur de 8 bits. Les écrans étant de plus en plus capables d'une luminosité, d'une profondeur de couleur et d'une gamme de couleurs plus élevées, les acteurs du Web sont de plus en plus intéressés par la préservation des données d'image perdues avec le JPEG ;
  • soutenir l'intérêt des écosystèmes. Les entreprises fortement présentes sur le Web ont exprimé leur intérêt pour l'envoi d'images AVIF sur le Web.


API de déclaration des politiques d'ouverture croisées

Une nouvelle API de reporting aide les développeurs à déployer une politique d'ouverture interorigine. En plus de signaler les casses lorsque le COOP (Cross-origin opener policy) est appliqué, l'API fournit un mode de rapport uniquement pour le COOP. Ce mode ne permet pas d'appliquer le COOP, mais il permet de signaler les casses potentielles qui se seraient produites si nous avions appliqué le COOP. Les développeurs peuvent inspecter l'API de signalement avec Chrome DevTools.

Annulation de l'affichage dans les manifestes des applications Web

Le nouveau champ display_override du manifeste d'une application Web permet aux développeurs de spécifier une chaîne de repli explicite pour le champ display. Selon l'équipe, Cette API est destinée aux cas d'utilisation et aux modes d'affichage avancés, et ses capacités sont limitées.

Exposer l'interface ReadableStreamDefaultController

Chrome expose maintenant l'interface ReadableStreamDefaultController sur l'objet global, comme pour les autres classes liées à ReadableStream. Cela élimine une limitation précédente où les instances devaient être créées à l'intérieur des constructeurs de flux.

performance.measureUserAgentSpecificMemory()

Cette fonctionnalité ajoute une fonction performance.measureUserAgentSpecificMemory() qui estime l'utilisation de la mémoire de la page Web. La méthode est intégrée derrière COOP/COEP, ce qui signifie que le site Web doit être isolé pour pouvoir l'utiliser.

API des flux (Streams API) : Flux d'octets

Les API de flux fournissent des primitives omniprésentes et interopérables pour la création, la composition et la consommation de flux de données. Pour les flux représentant des octets, Chrome prend désormais en charge une version étendue du flux lisible afin de gérer efficacement les octets, notamment en minimisant les copies. Les flux représentant des octets permettent d'acquérir des lecteurs BYOB (Bring Your Own Buffer). L'implémentation par défaut peut donner une gamme de sorties différentes telles que des chaînes de caractères ou des tampons de tableau dans le cas des sockets Web, alors que les flux d'octets garantissent une sortie d'octets.

En outre, l'équipe estime que le fait de pouvoir disposer de lecteurs BYOB présente des avantages en matière de stabilité. En effet, si un tampon se détache, il est désormais garanti que le même tampon ne sera pas écrit deux fois, ce qui permet d'éviter les conditions de course. Les lecteurs BYOB n'ont pas non plus besoin d'un ramassage des déchets pour chaque lecture, car les tampons sont réutilisés.

Support de la syntaxe complète des propriétés de "filtrage" sur les éléments SVG

Chrome permet maintenant d'utiliser la syntaxe complète de la propriété "filter" sur des éléments SVG qui ne supportaient auparavant que les références url() uniques. Cela permet aux fonctions de filtrage telles que blur(), sepia() et grayscale() de s'appliquer à la fois aux éléments SVG et aux éléments non SVG. Cela rend la prise en charge du "filtrage" par la plateforme plus uniforme et permet d'appliquer plus facilement certains effets "en conserve". Sans cette fonctionnalité, les développeurs doivent utiliser une définition complète des éléments SVG <filtre>, même pour les filtres de base tels que grayscale() ou blur().

API d'authentification Web : ResidentKeyRequirement et extension credProps

Chrome prend désormais en charge deux nouvelles fonctionnalités liées à l'API d'authentification Web. La propriété AuthenticatorSelectionCriteria.residentKey spécifie, pour l'enregistrement des justificatifs d'authentification Web, si un justificatif découvrable côté client doit être créé. L'extension Web Authentication credProps indique à la partie qui se fie à l'authentification si un justificatif créé est découvrable côté client. Les "références découvrables côté client" sont un type de références WebAuthn qui peuvent être contestées par une partie qui s'y fie sans avoir à fournir l'identifiant de la référence dans la demande d'API WebAuthn.

Les navigateurs affichent une liste de toutes les références découvertes d'un authentificateur donné (clé de sécurité externe ou intégrée) et permettent à l'utilisateur de choisir celle avec laquelle il souhaite s'identifier.

Nouvelles fonctionnalités CSS dans Chrome 89

::target-text pseudo-element

Cette nouvelle propriété ajoute un pseudo élément de mise en évidence pour permettre aux auteurs de styliser les fragments de texte de défilement différemment de la mise en évidence par défaut de l'agent utilisateur.

Propriétés d'arrondi de coin relatives au flux

Les propriétés d'arrondissement des coins par rapport au flux permettent désormais de contrôler les coins à l'aide de cartographies logiques plutôt que de propriétés physiques. De plus, cela permet aux auteurs de définir différents rayons de bordure des coins en fonction de la direction et du mode d'écriture de la page, ce qui met Chrome en conformité avec les spécifications des propriétés et valeurs logiques CSS. Les propriétés logiques suivantes ont été ajoutées :

  • border-start-start-radius ;
  • border-start-end-radius ;
  • border-end-start-radius ;
  • border-end-end-radius.

Propriété des couleurs forcées

La fonction multimédia "forced-colors" détecte si l'agent utilisateur applique une palette de couleurs limitée choisie par l'utilisateur sur la page.

Les couleurs forcées ajustent la propriété

La propriété "forced-color-adjust" permet aux auteurs d'exclure certains éléments du mode de couleurs forcées, ce qui permet de restaurer le contrôle total des couleurs dans le CSS.

Nouvelles fonctionnalités JavaScript dans Chrome 89

Cette version de Chrome intègre la version 8.9 du moteur JavaScript V8. Elle inclut spécifiquement les changements énumérés ci-dessous.

Top-level await

Chrome prend maintenant en charge le mot-clé "await" au niveau supérieur dans les modules JavaScript. Cela permet une intégration plus transparente des appels asynchrones dans le processus de chargement des modules. Aujourd'hui, cela est réalisé en enveloppant les modules dans des fonctions asynchrones, mais cela pousse la complexité dans les modules dépendants et expose les détails de la mise en œuvre.

Dépréciations et suppressions dans Chrome 89

Cette version de Chrome introduit les déprédations et les suppressions énumérées ci-dessous.

Supprimer les événements préfixés pour <link rel=prerender>

Les anciens événements préfixés (webkitprerenderstart, webkitprerenderstop, webkitprerenderload et webkitprerenderdomcontentloaded) envoyés sur <link rel=prerender> sont désormais supprimés de Chrome.

Arrêter la session de clonageStockage des fenêtres ouvertes avec noopener

Lorsqu'une fenêtre est ouverte avec noopener, Chrome ne clone plus le sessionStorage de son ouvreur, mais démarre un espace de nom sessionStorage vide. Cela met Chrome en conformité avec la spécification HTML.

Source : Google Chrome 89 bêta

Et vous ?

Que pensez-vous des nouvelles fonctionnalités introduites par Chromes 89 ?
Que pensez-vous des efforts de Google pour faciliter l'interaction avec le matériel dans Chrome ?

Voir aussi

Google Chrome 88 est disponible avec des demandes d'autorisation moins intrusives et supprime la prise en charge des URL FTP, ainsi que le support de Mac OS X Yosemite 10.10

Après la colère de l'industrie du blocage de pub, Google modifie son API Manifest V3, qui limite le nombre de règles que les extensions peuvent appliquer à une page Web lors de son chargement

Windows 10 : combien utilisent Edge après avoir migré ? 88 % des utilisateurs US ont basculé sur un autre navigateur selon Quantcast

Le problème de compatibilité entre les navigateurs constitue un véritable frein pour les développeurs Web, selon un rapport de Mozilla Developer Network (MDN)

Une erreur dans cette actualité ? Signalez-nous-la !