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

101PARTAGES

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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.

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