Si vous avez la chance d’être parmi les utilisateurs qui peuvent essayer Firefox multi-processus avant les autres, donnez-nous votre avis. Le coup de boost est-il sensible ? Et si oui, est-ce que cela vous semble être une raison valable de faire revenir les utilisateurs qui sont passés à Chrome ?
Les développeurs de Mozilla en sont apparemment persuadés puisqu’ils déclarent qu’il s’agit de « la nouveauté la plus significative de notre histoire », rien que ça !
Rappelons que le passage de Firefox à une architecture multi-processus est un énorme chantier, commencé en 2009 (!) sous le nom de code Electrolysis (abrégé en e10s) en référence au procédé de séparation d’éléments chimiques.
E10s sera-t-il dans Firefox 42 ? Notre graphique du nombre de bogues résolus montre que oui. (illustration ci-contre)
Pour rappel, le projet Electrolysis vise à paralléliser le rendu de l’interface et du contenu afin de rendre l’une et l’autre plus fluides. Cette méthode, déjà utilisée par Chrome et IE, profite de la généralisation des processeurs multi-cœurs. Cependant, Mozilla n’entend pas aller jusqu’à créer un processus par onglet comme Chrome, afin de limiter la consommation de mémoire.
Dans un tweet, Chris Peterson appelle les volontaires courageux à tester le multi-processus dans la version de développement de Firefox (« nightly »). Nous vous avions parlé de ce projet dénommé Electrolysis (« e10s ») qui consiste à rendre Firefox multi-processus au même titre que Chrome et Internet Explorer, dans le but d’avoir une plus grande réactivité de l’interface utilisateur. D’après les commentaires de notre dernier article en date, il semblerait que le manque (relatif) de réactivité de l’interface utilisateur de Firefox soit une des raisons pour lesquelles il perd des parts de marché au profit de Chrome. Ce projet e10s pourrait donc être une nécessité absolue pour Firefox.
Afin d’illustrer l’avantage du multi-processus, Popescu Sorin a publié une vidéo qui montre comment l’interface utilitsateur de Firefox bloque lorsqu’un script JavaScript fait des calculs intenses, alors qu’elle répond encore parfaitement lorsque ces calculs sont lancés dans un onglet avec un processus dédié.
Sachez toutefois qu’il s’agit encore d’un projet expérimental réservé, comme le souligne Chris Peterson, aux « âmes braves ». Il faut en effet activer browser.tabs.remote.autostart dans la configuration (about:config) et être disposé à rapporter les bugs rencontrés, en particulier avec les extensions.
Le blog de Firefox Nightly publie les articles de Mike Conley intitulés « These Weeks in Firefox ». Sa 14ᵉ édition rapporte des nouvelles du développement de Firefox. Nous en avons sélectionnées quelques-unes :
Onglets
Le bénévole Kevin Jones a fait un boulot impressionnant sur le projet lazytabs (bogue vieux de 4 ans) qui crée des listes d’onglets ouverts pour les gros consommateurs. Les mesures initiales montrent le potentiel en gains de temps pour les restaurations épiques de sessions :
Le blog de Firefox Nightly publie les articles de Mike Conley intitulés « These Weeks in Firefox ». Sa 13ᵉ édition rapporte des nouvelles du développement de Firefox. Nous en avons sélectionné quelques-unes :
Firefox Nightly a désormais 4 processus par défaut pour le contenu.
Les onglets en arrière-plan sont restaurés dans le processus de contenu par défaut, améliorant les performances de la restauration de session perçues, particulièrement pour les utilisateurs avec de nombreux onglets.
Le blog de Firefox Nightly, lancé par Pascal Chevrel l’été dernier dans le cadre de son projet « Reboot Nightly », continue d’offrir une foule de petites informations intéressantes sur les évolutions qui arriveront prochainement dans Firefox. Nous en traduisons quelques-unes ci-dessous :
Le travail a commencé sur le compositeur du projet Quantum, dont nous parlions dans notre article précédent. Il s’agit d’utiliser un processus dédié au rendu du contenu via le processeur graphique afin d’obtenir les meilleures performances possibles avec le matériel informatique actuel. Nom de code : e10s-gpu !
Le mode responsive design (RDM, activable par Maj-Ctrl-M) offrira la possibilité de simuler une connexion lente du type GPRS, 2G, ou 3G.
Le panneau des permissions telles que « partager sa position » va bientôt être plus clair : moins de risque de se tromper d’action, la possibilité de refuser sera plus accessible.
Firefox va bientôt avertir quand on tente de se connecter sur un site non-sécurisé par HTTPS. La fonction est activable par les réglages security.insecure_field_warning.contextual.enabled à true et signon.autofillForms.http à false (dans about:config)
La réflexion a repris sur la possibilité d’appliquer un style aux cases à cocher et boutons radios plus facilement, comme sur Webkit/Blink (à gauche sur l’image, au milieu un patch proposé sur Firefox et à droite Firefox en l’état). Cette vidéo montre le but visé. C’est une demande qui remonte à 2008 !
Le panneau des téléchargements va subir un petit lifting.
Le sélecteur de dates <input type=”time”> a été intégré mais il est encore caché derrière le réglage dom.forms.datetime (dans about:config)
Dans un article paru aujourd’hui sur le blog des extensions de Mozilla, Kev Needham écrit ceci :
Comme nous l’avions annoncé, Mozilla va proposer un Firefox multi-processus (projet e10s) à quelques utilisateurs à partir de la version 48. Les Firefox installés sans extension ni fonctions d’accessibilité auront le multi-processus activé par défaut pendant six semaines. Nous testerons Firefox multi-processus avec des extensions dans le canal public à partir de la version 49, dans le but de généraliser à tout le monde début 2017.
Un certain nombre d’extensions existantes fonctionnent avec Firefox multi-processus, mais certaines ne fonctionnent pas, ou pas bien. Nous aimerions que les extensions marchent tout simplement, pour que les utilisateurs puissent utiliser leurs extensions préférées et en même temps bénéficier des avantages d’e10s. Nous lançons donc un appel urgent à tous les développeurs d’extensions qui n’ont pas encore testé les leurs avec e10s ou qui sont déjà passé au format WebExtensions :
Si votre extension ne fonctionne pas comme prévu avec e10s, adaptez-la, puis marquez-la comme compatible et envoyez la nouvelle version sur AMO et/ou sur votre URL de mise à jour
Les informations supplémentaires sur e10s, les extensions et les WebExtensions sont disponibles sur le Wiki de Mozilla et sur MDN, et nous sommes aussi là pour vous aider à faire la transition. Cela semble encore loin, mais 2017 c’est juste dans quelques mois, et nous aimerions que vous testiez (et fassiez les modifs si nécessaires) le plus rapidement possible.
Note : à l’exception du lien sur l’acronyme « e10s », nous avons laissé les liens vers les articles originaux, en anglais.
L’annonce de la diffusion prochaine de la technologie Electrolysis (e10s) dans Firefox 48 a rencontré un certain succès. Nous ne reviendrons pas sur la teneur de cette technologie, qui est bien présentée par l’article de NextInpact « Multiprocessus : Firefox 48 marquera enfin le premier pas vers Electrolysis ». Cependant, Asa Dotzler, qui est cité dans cet article, a publié cette mise à jour que nous traduisons ici :
Il y a une certaine confusion sur ce qui est nouveau. Je voudrais faire une mise au point. E10s est en bêta depuis un certain temps. Ce n’est pas nouveau. Il était là pour la moitié de nos utilisateurs bêta pendant l’ensemble du cycle précédent de 6 semaines. Ce qui est nouveau ici est que nous avons récemment rempli tous nos critères de mise en production, et nous pensons que nous pouvons passer cette fonction en production pendant les 6 prochaines semaines. Maintenant, nous sommes dans un cycle de finalisation – en supposant que nous ne rencontrons pas de surprises. C’est là que vous, les utilisateurs, entrez en scène. S’il vous plaît, aidez-nous à tester cette prochaine Firefox 48 bêta, de manière à nous assurer que e10s fonctionne bien pour tout le monde. Merci.
Dans un article paru sur le blog Mozilla Hacks le 28 octobre, Jan Honza Odvarko fait le point sur le rapprochement en cours entre Firebug et les outils pour développeurs de Firefox (DevTools) :
Nous avons travaillé dur pour reproduire les fonctions les plus appréciées de Firebug dans les outils intégrés à Firefox, les rendre compatibles avec le multi-processus (e10s) et permettre le débogage à distance. Nous avons aussi travaillé à rendre la transition de Firebug aux DevTools la plus simple et la plus douce possible. Comme nous l’avons déjà dit par le passé, nous faisons tout notre possible pour développer un super outil pour les développeurs !
Alors voyons à quoi cela ressemble, maintenant.
Le but principal de la nouvelle génération de Firebug est que les utilisateurs se sentent chez eux quand ils travaillent avec les DevTools natifs. C’est là qu’intervient Firebug 3 (nom de code Firebug.next). Firebug 3 n’est pas un nouveau logiciel, c’est plutôt une surcouche fine au dessus des DevTools, autrement dit un thème qui fait ressembler les DevTools à Firebug. Il y a aussi quelques fonctionnalités en plus, que nous allons migrer dans les DevTools petit à petit.
Et comme un croquis vaut mieux qu’un long discours, nous vous invitons à lire la suite de l’article pour voir les copies d’écrans qui intéresseront au plus haut point les développeurs web.
Commentaires fermés sur Firebug et les DevTools de Firefox vont s’unir
Dans un article qui vient de paraitre sur le blog Mozilla Hacks, Blake Winton vous propose d’écrire des extensions pour la nouvelle API de Firefox qui permet d’être compatible avec le multi-processus. C’est aussi une API qui permet d’écrire du code compatible avec Chrome, et inversement, qui permet de récupérer les extensions de Chrome et de les faire tourner sur Firefox au prix de modifications mineures. C’est dans l’esprit de l’interopérabilité qui fait tourner le Web depuis le début, mais on se doute bien que cela fera grincer des dents ceux qui y verront une manière de rapprocher Firefox du diable (Google Chrome) 😉 En tout cas, cela annonce aussi l’arrivée prochaine de Firefox multi-processus, avec la promesse de faire disparaitre une fois pour toutes les petits blocages de l’interface que pouvaient provoquer les scripts dans des pages web lourdes.
L’été dernier, nous avons relayé 
Le 
L’annonce de la diffusion prochaine de la technologie 
Dans un article paru 
Dans 
