Martin Stransky, mainteneur des paquets Firefox pour Fedora et RHEL, travaillant sur le portage de Firefox pour Wayland, a publi\u00e9 un rapport sur les derni\u00e8res avanc\u00e9es concernant le fonctionnement de Firefox dans des environnements bas\u00e9s sur le protocole Wayland. <\/p>\n
Les prochaines versions de Firefox devraient r\u00e9soudre les probl\u00e8mes d'\u00e9change de donn\u00e9es et de gestion des fen\u00eatres pop-up dans les versions pour Wayland. Ces fonctionnalit\u00e9s n'ont pas pu \u00eatre mises en \u0153uvre imm\u00e9diatement en raison des diff\u00e9rences dans leur r\u00e9alisation entre X11 et Wayland. Dans le premier cas, les difficult\u00e9s sont survenues en raison du fonctionnement asynchrone du presse-papiers de Wayland, ce qui a n\u00e9cessit\u00e9 la cr\u00e9ation d'une couche interm\u00e9diaire pour abstraire l'acc\u00e8s au presse-papiers de Wayland. Cette couche sera int\u00e9gr\u00e9e dans Firefox 93 et activ\u00e9e par d\u00e9faut dans Firefox 94. <\/p>\n
Concernant les fen\u00eatres dialoguelles, la principale difficult\u00e9 r\u00e9sidait dans le fait que Wayland exige le respect d'une hi\u00e9rarchie stricte des fen\u00eatres pop-up, c'est-\u00e0-dire qu'une fen\u00eatre parent peut cr\u00e9er une fen\u00eatre enfant avec un pop-up, mais le pop-up suivant initi\u00e9 \u00e0 partir de cette fen\u00eatre doit \u00eatre attach\u00e9 \u00e0 la fen\u00eatre enfant d'origine, formant ainsi une cha\u00eene. Dans Firefox, chaque fen\u00eatre pouvait g\u00e9n\u00e9rer plusieurs pop-ups sans \u00e9tablir de hi\u00e9rarchie. Le probl\u00e8me \u00e9tait que, lorsque Wayland \u00e9tait utilis\u00e9, la fermeture de l'un des pop-ups n\u00e9cessitait de reconstruire toute la cha\u00eene de fen\u00eatres avec d'autres pop-ups, \u00e9tant donn\u00e9 que la pr\u00e9sence de plusieurs pop-ups ouverts n'est pas rare, car des menus, des infobulles, des dialogues d'extensions, des demandes d'autorisation, etc., sont r\u00e9alis\u00e9s sous forme de pop-ups. La situation \u00e9tait \u00e9galement compliqu\u00e9e par des lacunes dans Wayland et GTK, qui faisaient que de petites modifications pouvaient conduire \u00e0 diverses r\u00e9gressions. N\u00e9anmoins, le code de gestion des fen\u00eatres pop-up pour Wayland a \u00e9t\u00e9 affin\u00e9 et il est pr\u00e9vu de l'int\u00e9grer dans Firefox 94. <\/p>\n
Parmi les autres am\u00e9liorations li\u00e9es \u00e0 Wayland, il convient de mentionner l'ajout dans Firefox 93 de modifications concernant le redimensionnement sur des \u00e9crans avec des DPI diff\u00e9rents, qui ont permis d'\u00e9liminer le scintillement lors du d\u00e9placement de la fen\u00eatre vers le bord de l'\u00e9cran dans des configurations multi-\u00e9crans. Dans Firefox 95, il est pr\u00e9vu de s'attaquer aux probl\u00e8mes rencontr\u00e9s lors de l'utilisation de l'interface de glisser-d\u00e9poser, par exemple, lors de la copie de fichiers depuis des sources externes vers des syst\u00e8mes de fichiers locaux et lors du d\u00e9placement des onglets. <\/p>\n
Dans la version Firefox 96, l'objectif est d'atteindre un parit\u00e9 fonctionnelle entre la version de Firefox pour Wayland et celle pour X11, au moins dans l'environnement GNOME de Fedora. Apr\u00e8s cela, l'attention des d\u00e9veloppeurs sera tourn\u00e9e vers l'optimisation du fonctionnement du processus GPU sous Wayland, qui contient le code pour interagir avec les cartes graphiques et qui prot\u00e8ge le processus principal du navigateur des plantages en cas de d\u00e9faillance des pilotes. Le processus GPU est \u00e9galement pr\u00e9vu pour inclure le code de d\u00e9codage vid\u00e9o via VAAPI, qui est actuellement ex\u00e9cut\u00e9 dans les processus de traitement de contenu. <\/p>\n
On peut \u00e9galement noter l'inclusion pour un petit pourcentage d'utilisateurs des branches stables de Firefox du mode de stricte isolation des sites, d\u00e9velopp\u00e9 dans le cadre du projet Fission. Contrairement \u00e0 la distribution al\u00e9atoire utilis\u00e9e jusqu'\u00e0 pr\u00e9sent pour le traitement des onglets dans le pool de processus disponible (par d\u00e9faut 8), le mode d'isolation attribue le traitement de chaque site \u00e0 son propre processus, en s\u00e9parant non pas par onglets, mais par domaines (Public Suffix), ce qui permet d'isoler davantage le contenu des scripts externes et des blocs iframe. Le contr\u00f4le de l'activation du mode Fission se fait via la variable \u00ab fission.autostart=true \u00bb dans about:config ou sur la page about:preferences#experimental. <\/p>\n
Le mode de stricte isolation permet de se prot\u00e9ger contre les attaques par canaux lat\u00e9raux, par exemple ceux li\u00e9s aux vuln\u00e9rabilit\u00e9s de type Spectre, et r\u00e9duit la fragmentation de la m\u00e9moire, renvoyant plus efficacement la m\u00e9moire au syst\u00e8me d'exploitation, minimisant l'impact de la collecte des d\u00e9chets et des calculs intensifs sur les pages des autres processus, augmentant l'efficacit\u00e9 de la r\u00e9partition de la charge sur diff\u00e9rents c\u0153urs de CPU et am\u00e9liorant la stabilit\u00e9 (le plantage du processus traitant un iframe ne mettra pas \u00e0 mal le site principal et les autres onglets). <\/p>\n
Parmi les probl\u00e8mes connus lors de l'utilisation du mode de stricte isolation, une augmentation notable de la consommation de m\u00e9moire et de descripteurs de fichiers est mentionn\u00e9e lors de l'ouverture d'un grand nombre d'onglets, ainsi que des dysfonctionnements de certaines extensions, la disparition du contenu des iframes lors de l'impression et de l'appel de la fonction de capture d'\u00e9cran, une diminution de l'efficacit\u00e9 du mise en cache des documents avec iframes, ainsi que la perte du contenu des formulaires remplis mais non soumis lors du r\u00e9tablissement de la session apr\u00e8s un plantage. <\/p>\n