Firefox 3.6.4 intègre Electrolysis

Posté par . Modéré par Florent Zara.
Tags :
26
24
juin
2010
Mozilla
La nouvelle version 3.6.4 du navigateur Firefox vient d'être publiée. Bien que cela soit une version mineure, elle incorpore la fonctionnalité très attendue des utilisateurs : la séparation en processus des greffons.

Firefox 3.6.4 fournit ainsi une navigation sans interruption pour les utilisateurs Windows et Linux après un plantage des greffons Adobe Flash, Apple Quicktime ou Microsoft Silverlight. Si un greffon cesse brutalement de fonctionner, cela n'affectera pas les autres onglets et fenêtres de Firefox. Vous aurez alors la possibilité d'actualiser la page pour redémarrer le greffon et ré-essayer (crash protection). Rappelons que Chrome, le navigateur de Google, utilise déjà ce système.

La séparation en différents processus de l'interface utilisateur du navigateur, l'affichage du contenu web et l'exécution des greffons repose sur la plate-forme Electrolysis, un sous-projet de la fondation Mozilla. Electrolysis devrait profiter également à Thunderbird, le client de messagerie électronique de Mozilla.

En outre cette version corrige de nombreuses anomalies ou problèmes de stabilité et quelques problèmes de sécurité.

Cette mouture du logiciel symbolise aussi la nouvelle politique de développement de la fondation Mozilla dévoilée en début d'année et qui consiste à intégrer de nouvelles fonctions à des mises à jour dites « mineures ».

NdM : la dépêche a été modifiée. Elle indiquait que chaque onglet utilisait un processus séparé, ce qui n'est pas encore le cas. Pour le moment, seuls les greffons tournent dans un processus séparé. Il faudra attendre la prochaine version de Firefox pour la mise en application complète d'Electrolysis.
  • # Lorentz <> Electrolysis

    Posté par (page perso) . Évalué à 10.

    J'ai lu que ce qui était inclus dans cette 3.6.4 était une branche "Lorentz" qui était le début d'Electrolysis mais que cela n'intégrait pas tout.

    Notemment, Lorentz supporte la séparation en process des plugins, mais pas des différents onglets qui restent communs (finalement, c'est le principal, c'est surtout le plugin flash qui crashe).

    (Ils en parlent aussi sur le lien du wiki, donc je pense que c'est effectivement ça)
    • [^] # Re: Lorentz <> Electrolysis

      Posté par . Évalué à 6.

      Normal, cela fait un moment que c'est décrit comme la première étape de la migration vers ce que tu indique!

      1ère étape : Séparation des greffons en processus à part
      2ème étape : Séparation des onglets en processus à part
    • [^] # Re: Lorentz <> Electrolysis

      Posté par (page perso) . Évalué à 10.

      finalement, c'est le principal, c'est surtout le plugin flash qui crashe

      Oauis enfin si Firefox arrêtait de geler l'affichage dès qu'un onglet a un peu de mal à charger une page, je ne m'en plaindrais pas, tu sais...
    • [^] # Re: Lorentz <> Electrolysis

      Posté par . Évalué à 5.

      Effectivement,

      J'ai testé, l'ouverture d'onglets n'ouvre pas de nouveaux processus.
      Je pense que la News devrait être corrigée en conséquence...
    • [^] # Re: Lorentz <> Electrolysis

      Posté par . Évalué à 4.

      C'est bien dommage. Je vais essayer mais pour mon utilisation la gestion de processus, léger ou pas, est très importante. En effet j'utilise vimperator : avec cette extension l'ensemble des interactions Homme/Machine sont dans le même processus que le reste du javascript du coup on se mange des méchant gèle d'interface.

      Chromium avec l'extension vimium n'a pas se problème. Cependant je ne sais pas comme doit se faire le découper les processus pour que ça reste propre.

      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

      • [^] # Re: Lorentz <> Electrolysis

        Posté par (page perso) . Évalué à 3.

        euh, ouai enfin là, c'est peut être aussi l'extension qui est à revoir. Les threads ça existe depuis la nuit des temps dans Firefox, si le gars ne sait pas faire ses traitements dans des threads, c'est pas de la faute à Firefox. Et c'est pas le fait de faire tourner chaque onglet dans un processus qui va changer les choses.
        • [^] # Re: Lorentz <> Electrolysis

          Posté par . Évalué à 4.

          Si une extension peut figer l'application principale, je considère que c'est l'application principale qui fournit un mauvais mécanisme d'extension.
          • [^] # Re: Lorentz <> Electrolysis

            Posté par . Évalué à 2.

            N’importe quoi. Ce que tu appelles « un pas mauvais mécanisme d’extension », c’est implémenter un mini-OS (scheduler + MMU) dans ton application. Merci, mais non merci.
            • [^] # Re: Lorentz <> Electrolysis

              Posté par . Évalué à 2.

              Implementer dans l'application?
              Non, utiliser celui fourner par l'OS..
              Tu crois qu'ils ont fait comment Chrome et Firefox 3.6.4?
              • [^] # Re: Lorentz <> Electrolysis

                Posté par . Évalué à 3.

                Il y a une différence entre une extension, genre adblock, et un plugin, genre flash.
                Le second utilise une interface figée pour communiquer avec le navigateur (NSAPI, si mes souvenirs sont bons). La particularité du premier, c’est que personne ne sait comment le mécanisme sera utilisé, et se limiter à une interface figée n’est tout simplement pas une option.
                Plus prosaïquement, avec ma dizaine d’extensions et ma vingtaines d’onglets, ça me ferait 200 processus. Pas que je n’aime pas les processus, mais…
                • [^] # Re: Lorentz <> Electrolysis

                  Posté par . Évalué à 2.

                  Pas grand chose a ajouter, je suis d'accord.

                  Après le probleme est que rien n'empecherait Adobe (par exemple) d'utiliser le mécanisme d'extension plutot que de plugin..

                  Pour ce qui est du probleme des processus sur les machines a faible mémoire, on peut multiplexer des threads dans un processus, Chrome possède d'ailleurs une option pour ça:
                  http://css.dzone.com/news/make-google-chrome-take-less-m

            • [^] # Re: Lorentz <> Electrolysis

              Posté par . Évalué à 2.

              Personnellement je parlais juste d'avoir un thread pour le javascript de l'extension différents de celui de la page. C'est pas pour gérer un éventuel plantage de l'extension mais pour qu'elle puisse offrir une interaction propre et donc faire comme toutes les interfaces graphiques avoir un thread qui gère l'affichage différent de celui qui gère le reste de l'appli'.

              Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

  • # Test concluant

    Posté par Anonyme . Évalué à 10.

    1/ Lancement d'une vidéo en flash dans firefox

    2/ On récupère le pid du processus lié à libflashplayer

    $ ps aux | grep flash-player | grep -v grep
    olivier 8841 3.0 5.3 164628 39896 ? Sl 08:38 0:16 /usr/lib/xulrunner-1.9.2/plugin-container /usr/lib/adobe-flashplugin/libflashplayer.so 8591 plugin


    3/ On lui envoie le signal SIGSEGV
    $ kill -s 11 8841

    4/ Retour dans firefox. On a le message : "The Adobe Flash plugin has crashed"
    • [^] # Re: Test concluant

      Posté par Anonyme . Évalué à 3.

      coquille :

      ps ux | grep flashplayer | grep -v grep
    • [^] # Re: Test concluant

      Posté par . Évalué à 4.

      Pour information, sous Windows, le processus ce nomme : « plugin-container.exe ». On peut cliquer sur : « Terminer le processus », et on a le même message.
  • # Hexa-coeurs

    Posté par (page perso) . Évalué à 3.

    Rah, enfin le navigateur va utiliser plusieurs processeurs pour rendre flash fluide ;-) à moins que ce ne soit le contraire!

    Bref, la consommation de votre machine va fortement augmenter quand vous visiterez des sites en avec plus d'une applet flash.

    ⚓ À g'Auch TOUTE! http://agauch.online.fr

    • [^] # Re: Hexa-coeurs

      Posté par . Évalué à 4.

      Non: je ne sais pas si c'est de la faute des développeurs de Flash ou si c'est la conception du mécanisme de plugin qui est pourri++, mais j'ai lu qu'un seul processus Flash gère toute les applet Flash.

      D'un point de vue sécurité, isolation de faute, c'est pas terrible (comme d'habitude)..
      • [^] # Re: Hexa-coeurs

        Posté par . Évalué à 2.

        justement c'est ce que je me disais en lisant la news, dans chromium quand flash plante sur un onglet il s'arrete dans tous les onglets

        du coup je comprend bien l'intérêt de faire que tout le navigateur plante pas, et il était temps de changer ça dans firefox, mais tant que flash est aussi moisi la meilleure manière de pas avoir de problèmes c'est de pas l'utiliser, ou s'arrager pour que les player flash soient lances dans des processus differents a chaque fois,
        mais vu la qualité de flash, même les pc haut de gamme actuels seraient a genoux

        le souci c'est que quand c'est flash qui plante l'utilisateur de base le voit pas et voit juste que firefox a planté...
      • [^] # Re: Hexa-coeurs

        Posté par (page perso) . Évalué à 4.

        Les processus alourdissent l'ensemble, donc vu la quantité de pubs de m*rde en flash, je préfère encore qu'il n'y ait pas 50 000 processus supplémentaire. C'est pas comme si Flash était pas déjà assez lourd...
        • [^] # Re: Hexa-coeurs

          Posté par . Évalué à 2.

          >Les processus alourdissent l'ensemble

          Ca dépend..
          1) Une bonne implémentation des processus fait du COW, donc toute page non-modifiée dans une processus fils, n'utilise pas plus de mémoire physique.

          Je crois que Windows ne fait pas de COW(*).

          2) Pour les pages modifiée commune, il y a la mémoire partagée.

          3) Gilad Ben-Yossef a montré un benchmarks à l'ELCE 2009 (** ) comparant les deux et dans ce comparatif il n'y a pas de vainqueur net..


          *: ok on est sur *linux*fr, mais comme j'ai l'impression que les dev de FF optimisent d'abord pour Windows, donc je me dis que c'est peut-être pour ça qu'ils ont choisi une architecture toute pourrie a base de thread..

          **: http://free-electrons.com/blog/elce-2009-videos/
          • [^] # Re: Hexa-coeurs

            Posté par . Évalué à 3.

            Windows ne fait pas de Copy on Write sur les processus parce qu'il n'y à pas de fork sous Windows. Il y a des spawn de process ! Du coup, c'est d'emblé de jeu optimisé pour un processus neuf.
            Le COW du fork est surtout la pour éviter de copier le processus père, car on sais que dans 99% des cas un fork est suivi par exec() !
            • [^] # Re: Hexa-coeurs

              Posté par . Évalué à 2.

              > Le COW du fork est surtout la pour éviter de copier le processus père, car on sais que dans 99% des cas un fork est suivi par exec() !

              Ça sert surtout à faire tourner 300 processus d'un serveur quelconque sans consommer 300 fois la taille d'un processus. Si on prend l'exemple d'un serveur web avec quelques modules, le code et les données jamais réécrites peuvent facilement atteindre plusieurs Mo; c'est autant de mémoire économisée pour chaque processus.

              Avec ces navigateurs au code assez conséquent et qui utilisent un processus par onglet et par plugin, ça peut avoir un bénéfice énorme aussi.

              Si je comprend bien, pour isoler les onglets entre eux chrome spawn un processus tout neuf pour chaque onglet ? Et tout le code du navigateur est chargé en double dans chaque onglet ? Ça consomme pas trop de mémoire ? Le "spawn" prend pas trop de temps ?
              • [^] # Re: Hexa-coeurs

                Posté par (page perso) . Évalué à 2.

                Chromium me semble manger pas mal de ram. Là où un Firefox me prend 110mo, Chromium en prend le triple.

                Cela la bête est véloce, alors...
                • [^] # Re: Hexa-coeurs

                  Posté par . Évalué à 3.

                  J'avais cru comprendre que windows reporte mal la RAM utilisée: il dit que chaque processus prend, disons 100Mo, mais ce qu'il ne dit pas c'est que peut être 50-60Mo seraient partages entre plusieurs processus. Je sais plus ou j'ai lu ca.

                  Pur linux, je n'en sais rien.
          • [^] # Re: Hexa-coeurs

            Posté par . Évalué à 10.

            *: ok on est sur *linux*fr, mais comme j'ai l'impression que les dev de FF optimisent d'abord pour Windows, donc je me dis que c'est peut-être pour ça qu'ils ont choisi une architecture toute pourrie a base de thread.

            Ca commence a bien faire cette histoire de critiquer gratuitement Firefox des que l'on en a l'occasion. Quand Firefox a commencé, sorti de IE et Mozilla, il n'y avait pas vraiment d'autres navigateurs qui faisait jeu égal avec ceux-la (je ne parle pas de lynx ou de w3m - Est ce que Konqueror existait déjà dans un état utilisable?). Et a l'époque, l'architecture par thread était la plus adaptée, sinon ils ne l'auraient tout simplement pas fait comme ca.

            Maintenant que Google est arrivé avec son Chrome en présentant ca comme une super feature que les autres n'ont pas, on voit beaucoup de gens critiquer l'architecture de Firefox. Pourtant personne ne trouvait rien a redire dessus avant et personne ne s'est proposé pour implémenter une architecture par processus.

            Bien sur critiquer après coup c'est facile surtout quand on n'a rien fait pour aider. [/rant]

            Maintenant, ils sont quand même pas cons chez Mozilla, si ca marche mieux avec des processus et qu'on concurrent leur botte le cul gentiment grâce a ca, et bien ils vont pas rester les bras croisés. Ça arrive avec Firefox 3.6.4 et ca continuera avec la prochaine version.

            Sans Firefox, les concurrents n'auraient peut être même pas eu le loisir de faire mieux parce que le web tel que nous le connaissons n'existerait peut être plus et ne serait plus qu'une foire pas possible avec des ActiveX partout comme en Corée du Sud.

            Alors merci Mozilla, et continuez votre super boulot! J'ai toute confiance en vous.
            • [^] # Re: Hexa-coeurs

              Posté par . Évalué à 3.

              >> Pourtant personne ne trouvait rien a redire dessus avant et personne ne s'est proposé pour implémenter une architecture par processus. <<

              Ah? Pourtant je t'assure que je n'ai pas attendu Chrome pour penser que l'archi de FF est toute pourri:
              - une tab figée? toute la fenetre est figée.
              Vive XUL!(*)
              - mettre des plugins contenant du code non maitrisé par défaut dans le même processus que le navigateur?
              Bravo!

              Qu'est-ce que j'étais content quand j'ai lu les documents expliquant l'architecture de Chrome, enfin une conception saine!(**)

              >> Bien sur critiquer après coup c'est facile surtout quand on n'a rien fait pour aider. [/rant] <<

              Ca c'est vrai..

              *: j'attends toujours les merveilleuses applications qui devaient être basé sur XUL et qui expliquaient ses choix de conceptions..

              **: Je ne prétends pas que Chrome soit parfait: son "bloquage" du Flash et des pub est *très* perfectible, mais cela m'étonnerait que Google fasse le nécéssaire dans ce cas là..
              • [^] # Re: Hexa-coeurs

                Posté par (page perso) . Évalué à 8.

                Ce que je constate pour ma part, c'est que la conception de XUL permet un VRAI Adblock, un VRAI flashblock, des trucs qui modifient vraiment la page visitée pour virer les trucs dont on ne veut pas.

                Les adblocks et flashblock de Chrome ne font que cacher ces choses...

                Bref, XUL est infiniment plus puissant que le modèle d'extension de Chrome.

                La conception actuelle de Firefox permet d'envisager, par-dessus XUL, la création d'un système d'extension semblable à celui de Chrome : Jetpack.

                je ne suis pas certains que Google puisse à l'avenir proposer quelque chose d'aussi puissant que XUL dans Chrome à moins de récrire tout le cœur du navigateur...

                Bref, il y a de très bonne idées dans Chrome qui donnent un coup de vieux à Firefox. Mais Firefox est techniquement bien plus flexible et mieux pensé que Chrome.

                Je ne me soucie pas de l'avenir de Firefox. Il ne sera peut-être pas tout le temps moteur d'innovations, mais il sera pour longtemps au moins capable de les intégrer.

                En son état actuel, Chrome est bien plus limité sur le long terme.

                Bref, c'est un peu comme Emacs et Textmate : Textmate a apporté des trucs fun, hype et bien pensés qui ont fait paraître Emacs pour un vieux truc croulant. Mais au final, Emacs est capable non seulement de faire tout ce que fait Textmate, mais il fait aussi bien plus, et a infiniment plus de potentiel sur le court et sur le long terme.

                Parce qu'il est tout simplement mieux conçu.
                • [^] # Re: Hexa-coeurs

                  Posté par (page perso) . Évalué à 2.

                  Depuis quelques jours (ou semaines), on a un vrai adblock sur Chromium. Les pubs ne sont pas chargées, au lieu d'être masquées comme avant.

                  Ça va encore plus vite :-)

                  Envoyé depuis mon lapin.

              • [^] # Re: Hexa-coeurs

                Posté par . Évalué à 4.

                Comme dit ci-dessus, Gecko reste encore au-dessus de Safari et Chrome pour les extensions:
                http://hackademix.net/2009/12/10/why-chrome-has-no-noscript/

                Pourquoi est ce que tu dis que XUL est la raison pour laquelle toute la fenêtre est figée? Je ne vois pas ce qui empêche d'avoir a la fois XUL et des fenêtres non figées? D'ailleurs, si je ne me trompe pas, Mozilla travaille a avoir un processus par tab, et ce sans devoir supprimer XUL.

                - mettre des plugins contenant du code non maitrisé par défaut dans le même processus que le navigateur?
                Jusqu'à preuve du contraire il est infiniment plus facile de faire ca au début, que de faire un sandboxing de tout ce que l'on veut des le début. Jusqu'a preuve du contraire, Google Chrome ne s'es pas fait en un jour et Google Chrome ne devait pas maintenir son logiciel pour des millions d'utilisateurs jusqu'à récemment. Tout de suite ca offre pas mal de libertés que Mozilla n'avait pas.

                Je ne défend pas l'architecture choisie a l'époque, évidemment qu'aujourd'hui on peut faire mieux. Je dis juste que pour un projet avec des millions d'utilisateurs, avec un but défini comme "préserver et favoriser l'innovation sur internet", on ne peut pas tout faire a la fois, et il faut faire des choix, même si l'on voudrait pouvoir tout faire.
            • [^] # Re: Hexa-coeurs

              Posté par . Évalué à 2.

              Personnellement c'est quand j'ai essayé l'extension vimperator que j'ai vu de petits problèmes.

              Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

  • # Quant

    Posté par . Évalué à 4.

    C'est marrant que tout les navigateurs se mettent à implémenter ce type de fonction pil au moment où silverlight commence à être un peu utilisé.

    quoi ? comment ça de mauvaise foi ?
  • # question

    Posté par . Évalué à 3.

    comment font il pour que chaque processus s'execute indépendament dans la meme interface (en gros on une seule fenetre)? Plusieurs thread, je comprend bien, mais avec plusieurs process? Il y a une shared memory avec la page completement rendue ? comment font-il pour que ce soit fluide ?
    • [^] # Re: question

      Posté par . Évalué à 2.

      Je suppose que les plugins en temps normal font leur rendu dans un petit bout de mémoire mis à disposition par le navigateur. Là il suffit de faire en sorte que ce bout de mémoire soit partagé entre le processus du navigateur et le processus séparé. Ça doit être un peu plus compliqué que ça, mais je pense que ça résume à peu près la chose. La mémoire partagée est exactement la même chose que la mémoire "normale", je pense pas qu'une mémoire partagée soit moins performante qu'une mémoire non partagée.
      • [^] # Re: question

        Posté par . Évalué à 2.

        Non mais tu dois avoir des mécanismes d'indirection plus complexes et plus lent (appel système, commutation de contexte,...). Après est ce négligeable ? Je ne sais pas.

        Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

    • [^] # Re: question

      Posté par . Évalué à 4.

      Note que Chrome utilise encore plus de processus que Firefox (environ un par onglet) et qu'il est même plus fluide que Firefox..

    • [^] # Re: question

      Posté par . Évalué à 2.

      en:XEmbed, je pense
  • # Pas de processus séparés

    Posté par (page perso) . Évalué à 6.

    Correction : Firefox 3.6.4 n'utilise pas de processus séparé pour chaque onglet. Ça se vérifie très facilement en ouvrant plusieurs onglets et en faisant un ps.

    Et enfin, contrairement à ce qui ce dit, ce système de séparation des processus par onglet n'est pas du tout nécessaire pour avoir des interactions fluides alors qu'une page se charge dans un onglet donné : ça peut aussi bien se faire avec des sous-processus légers (threads).

    En revanche, séparer les processus pour les plugins, ça c'est important. Le navigateur n'a pas à souffrir à cause d'un plugin.
    • [^] # Re: Pas de processus séparés

      Posté par . Évalué à 3.

      Si tu fais référence à mon message plus haut je dis bien que je parle de processus ou processus léger, autrement dit thread. Il vaut d'ailleurs mieux je pense que ce soit des processus léger afin que les communication soient rapide.

      Mais là c'est la gestion du javascript qui est en cause.

      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

  • # 3.6.6

    Posté par . Évalué à 2.

    Mozilla à le don de gonfler les numéro de version de Firefox. La version 3.6.6 [http://www.mozilla-europe.org/fr/firefox/3.6.6/releasenotes/] est sortie le samedi 26 et quels sont les nouveautés ? On passe de 10 à 45 secondes avant de déclarer qu'un plugin s'est planté [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%20s(...)]...

    Pour une si petite modification (1 ligne [https://bug574905.bugzilla.mozilla.org/attachment.cgi?id=454(...)]), pourquoi ne pas numéroter cette version 3.6.4.1 ? Surtout que sans mettre à jour mon Firefox, je peux facilement corriger le bug ! :p

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.