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.
Aller plus loin
- Notes de cette version (2 clics)
- Electrolysis (8 clics)
- Page de téléchargement (11 clics)
# Lorentz <> Electrolysis
Posté par Damien Thébault . Évalué à 10.
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 VINDICATORs . Évalué à 6.
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 liberforce (site web personnel) . Évalué à 10.
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 ecyrbe . Évalué à 5.
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 barmic . Évalué à 4.
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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Lorentz <> Electrolysis
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: Lorentz <> Electrolysis
Posté par reno . Évalué à 4.
[^] # Re: Lorentz <> Electrolysis
Posté par Moonz . Évalué à 2.
[^] # Re: Lorentz <> Electrolysis
Posté par reno . Évalué à 2.
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 Moonz . Évalué à 3.
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 reno . Évalué à 2.
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 barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Test concluant
Posté par Anonyme . Évalué à 10.
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.
ps ux | grep flashplayer | grep -v grep
[^] # Re: Test concluant
Posté par Spack . Évalué à 4.
# Hexa-coeurs
Posté par ʭ ☯ . Évalué à 3.
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://afdgauch.online.fr
[^] # Re: Hexa-coeurs
Posté par reno . Évalué à 4.
D'un point de vue sécurité, isolation de faute, c'est pas terrible (comme d'habitude)..
[^] # Re: Hexa-coeurs
Posté par Lodran . Évalué à 2.
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 liberforce (site web personnel) . Évalué à 4.
[^] # Re: Hexa-coeurs
Posté par reno . Évalué à 2.
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 ecyrbe . Évalué à 3.
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 __o . Évalué à 2.
Ç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 jbbourgoin (site web personnel) . Évalué à 2.
Cela la bête est véloce, alors...
[^] # Re: Hexa-coeurs
Posté par djano . Évalué à 3.
Pur linux, je n'en sais rien.
[^] # Re: Hexa-coeurs
Posté par jbbourgoin (site web personnel) . Évalué à 2.
J'aime beaucoup Chromium cela dit.
[^] # Re: Hexa-coeurs
Posté par djano . Évalué à 10.
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 reno . Évalué à 3.
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 jbbourgoin (site web personnel) . Évalué à 8.
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 yellowiscool . Évalué à 2.
Ça va encore plus vite :-)
Envoyé depuis mon lapin.
[^] # Re: Hexa-coeurs
Posté par djano . Évalué à 4.
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 barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Quant
Posté par bubar🦥 (Mastodon) . Évalué à 4.
quoi ? comment ça de mauvaise foi ?
# question
Posté par Stibb . Évalué à 3.
[^] # Re: question
Posté par __o . Évalué à 2.
[^] # Re: question
Posté par barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: question
Posté par reno . Évalué à 4.
[^] # Re: question
Posté par Moonz . Évalué à 2.
# Pas de processus séparés
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
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 barmic . Évalué à 3.
Mais là c'est la gestion du javascript qui est en cause.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# 3.6.6
Posté par Spack . Évalué à 2.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.