Firefox 9 est sorti

38
21
déc.
2011
Mozilla

La nouvelle version du navigateur de la fondation Mozilla est sortie le 20 décembre. À part les corrections de bugs et l'amélioration de la prise en charge des standards HTML5, MathML et CSS, la principale nouveauté est l'inférence de type en JavaScript, qui permet une amélioration des performances.

Firefox

Merci à antistress, Nÿco, Barret Michel, Internaciulo, Enjolras, gregR ☯, Hell Pé, o-mann et Florent Zara pour leur aide lors de la rédaction de la dépêche. Merci à ikux pour avoir proposé une dépêche similaire.

Mise à jour :
Sortie de Mozilla Firefox 9.0.1 ce 21 décembre. Évidemment cette sous-version est sortie pour corriger un grand nombre de bugs. On notera toutefois l'ajout de l'inférence de type devant améliorer la rapidité de javascript ainsi qu'une amélioration du support des standards CSS, HTML5 et MathML et de l'intégration du thème de Mac OSx Lion.

Sommaire

Optimisation du moteur JavaScript

Compilation à la volée (JIT)

Pour exécuter du code JavaScript, le moteur SpiderMonkey de Firefox compile le code en bytecode, puis l'interprète. Cette méthode peut s'avérer particulièrement lente, notamment si le code est exécuté de multiples fois, comme dans le cas de boucles. C'est pourquoi des compilateurs à la volée ont été introduits.

La compilation à la volée consiste à compiler directement certaines parties du code en code natif plus efficace, et ce durant l'exécution.

Le moteur JavaScript de Firefox a intégré successivement deux compilateurs à la volée : TraceMonkey (depuis la version 3.5 de Firefox) et JägerMonkey (depuis la version 4). Ces deux compilateurs sont conçus pour agir alternativement :

  • TraceMonkey va repérer les calculs complexes et répétés et enregistrer le résultat pour réutilisation ultérieure, d'où un gain de temps maximum dans les cas où il peut être utilisé.
  • Dans les autres cas, c'est JägerMonkey, un compilateur à la volée basique et efficace, qui sera utilisé. L'inférence de types est une optimisation importante de JägerMonkey.

Inférence de types

JavaScript est un langage typé dynamiquement, c'est-à-dire qu'un type n'est pas associé à chaque identificateur. Lors de la compilation, le compilateur ne connait pas le type des variables ou des expressions. La contrepartie de la grande flexibilité offerte au programmeur se traduit souvent par une perte de performance. En effet, l'information de type doit être stockée en mémoire avec l'objet lui-même, et diverses opérations doivent être déportées de la compilation à l'exécution.

Prenons un exemple concret :

foo = foo + bar;

L'opérateur + est polymorphe, et cette expression peut traduire une concaténation de chaines ou une addition d'entiers. Sans information de type, un compilateur doit envisager tous les cas. Il faut donc conserver une information de type pour les deux variables dans le code produit, et compiler un jeu d'instructions, qui, suivant les types dynamiques, choisira lors de l'exécution quelle opération effectuer.

Imaginons que dans notre cas, ce code est et sera uniquement une addition d'entiers : on a introduit une complexité inutile et à la compilation, et à l'exécution.
L'idée de l'inférence de types et de déduire le type possible des différentes valeurs et variables en analysant le programme, et en appliquant des règles d'inférence. On garde un environnement de typage dans le contexte courant. La règle d'inférence qui s'applique dans notre exemple se traduit par :
foo a le type t dans le contexte courant si foo et bar ont le type t dans ce contexte.

Si on a plus haut:

foo = 1;

On peut en déduire que foo a le type int dans le contexte courant et compiler le code efficacement.

Bien sûr, cet exemple est relativement simpliste, et la souplesse du JavaScript ainsi que sont paradigme objet basé sur les prototypes rendent le problème bien plus complexe. Pour des informations détaillées sur les choix techniques, se reporter à l'article des développeurs.

L'introduction de l'inférence de types améliore significativement les performances. Des gains de 30% ont été constatés sur divers tests. Cela devrait améliorer la réactivité de Firefox sur les sites utilisant beaucoup de code JavaScript.

Sur ma machine, j'obtiens :

Navigateur Kraken V8 Benchmark Suite
Firefox 8 4244.6ms +/- 1.5% 4806
Firefox 9b4 3371.5ms +/- 4.1% 5002
Chromium 15 3010.7ms +/- 6.7% 8911

Évolutions futures

L'introduction de l'inférence de types rend JägerMonkey plus efficace que la combinaison des deux méthodes, c'est pourquoi le code de TraceMonkey sera supprimé dans une version ultérieure (probablement la version 11).

La prochaine étape sera l’intégration d'un troisième compilateur à la volée, IonMonkey, qui pourrait être le dernier : ce compilateur devrait contribuer à stabiliser l'infrastructure de SpiderMonkey de par sa conception suffisamment propre et flexible pour permettre de nombreuses optimisations et expérimentations futures.

MemShrink

MemShrink est un projet visant à réduire la consommation mémoire de Firefox, et de corriger les fuites de mémoires qui se présentent. Il a été lancé durant le cycle de développement de Firefox 7.

Au total, c'est près de 90 bugs qui ont été corrigés dans cette version de Firefox. Parmi les changements notables, on trouve :

  • Decode-on-draw : les images ne sont plus décodées à l'ouverture d'une page mais à l'affichage de l'onglet, ce qui fait économiser mémoire et temps processeur.
  • Lazy regexp : la compilation JIT des expressions régulières est rendue « paresseuse », ce qui permet dans certains cas d'éviter leur compilation.
  • Une multitude d’optimisations d'alignement et d'allocation mémoire pour JavaScript.
  • Les compteurs de mémoire, qui permettent d'afficher les informations dans about:memory ont été grandement améliorés pour fournir des informations plus détaillées, permettant de nouvelles améliorations dans le futur.

Pour plus d'informations sur MemShrink, voir le blog de Nicholas Nethercote.

Vie privée

Cette nouvelle version améliore l'utilisation de la fonction en:Do_not_track (« ne pas me pister », à activer dans les options du logiciel, onglet « Vie privée »). En effet il est dorénavant possible de vérifier en JavaScript si l'utilisateur accepte ou non d'être suivi.

Rappelons que Do Not Track est une initiative de Mozilla qui vise à permettre à l'utilisateur d'indiquer explicitement qu'il ne souhaite pas être suivi. Celle-ci est actuellement en voie de discussion au W3C pour tenter de créer un standard. Google est évidemment farouchement opposé à ce mécanisme et préfère proposer Keep My Opt-Outs qui consiste à s'inscrire chez des regroupements de publicitaires pour demander de ne plus être fiché.

Il faut noter que Commission Fédérale du Commerce américaine recommande Do Not Track.

Electrolysis

Le travail sur Electrolysis, le projet pour séparer le processus d'affichage du processus gérant le contenu afin d'améliorer la réactivité, a été stoppé. Les développeurs se sont rendu compte que le travail était trop important (la première partie du projet, la séparation du processus des plug-ins, date de la version 3.6.4 et les développeurs ne peuvent toujours pas donner une date de fin) et mobilisait trop de monde qui pourrait être utile ailleurs. Ils ont donc jugé plus efficace de réaffecter ces personnes sur des projets moins imposants et qui avaient une date de fin prévisible beaucoup plus courte.

Un des successeurs d'Electrolysis est le projet Snappy. Il vise :

  • une réactivité de 50ms lors de la frappe dans une zone de texte ;
  • rester à 60 images par seconde dans les opérations sur l’interface ;
  • vérifier les performances via la télémétrie ;
  • avoir un temps de démarrage comparable à celui de Chrome ou Internet Explorer ;
  • des fonctionnalités Précédent et Suivant aussi rapides que sous Opera.
  • # Optimisations JavaScript

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

    Tests sur un Core 2 Duo cadencé à 2,26 GHz.
    Benchmark Kraken => http://krakenbenchmark.mozilla.org/

    Firefox 8 : 7 105 ms
    Firefox 9 : 4 915 ms

    Impressionnant !

    • [^] # Re: Optimisations JavaScript

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

      Sur ce sujet, un article de blog (en Anglais) par Wingo (développeur pour Guile) explique une partie du fonctionement de V8, la machine Javascript de Chrome. Je trouve vraiment impressionnant ce qu'ils arrivent à faire avec un langage qui est à la base pas franchement conçu pour les performances. J'espère qu'un jour ce niveau d'optimisation sera atteint avec des langages dynamiques plus « classiques », comme Python ou Ruby.

      • [^] # Re: Optimisations JavaScript

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

        Pour python, PyPy avance à pas de géant, et commence à être utilisé en prod ici et là.

        • [^] # Re: Optimisations JavaScript

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

          Il faut dire aussi que je ne pense pas que les autres langages de script bénéficient d'autant de ressource humaine que javascript de ce coté là...

          Cela serait amusant d'avoir une comparaison ?

          • [^] # Re: Optimisations JavaScript

            Posté par . Évalué à 3.

            Difficile de savoir quelles ressources sont allouées. Mais il reste fort à parier que JavaScript est le langage où il y a actuellement le plus de travail.

            Pourtant, j'ai toujours été impressionné par LuaJIT, la réalisation de Mike Pall (c'est libre et il n'est sans doute pas le seul contributeur mais il reste ultra majoritaire sur les commits). Depuis la rénovation du shootout, LuaJIT n'est plus mais les bêtas de la version 2 montraient, sur ce type de tests qui ne sont certes que des micro-tests sans valeur biblique, que cette implémentation de Lua était capable de taquiner Java en performances brutes, pour une consommation mémoire bien plus faible (et équivalente à l'implémentation officielle de Lua). Il reste sur le site officiel un comparatif entre Lua et LuaJIT.

            Assez impressionnant pour un langage compilé à la volée. Une telle prouesse a sans doute été rendue possible par la petitesse de la librairie standard Lua et la qualité de de conception originale du langage. Et pourtant, Lua n'est pas exempt de fonctionnalités intéressantes à mon avis : closures, first-class functions, tables faisant office à la fois de conteneur de données et permettant un développement objet à prototype, concurrence par le biais des coroutines...

          • [^] # Re: Optimisations JavaScript

            Posté par . Évalué à 2.

            Pour Python, c'est simple, à peu près personne n'est payé pour bosser dessus.
            (on peut considérer que certains développeurs de PyPy, qui sont universitaires, bossent dessus dans le cadre de leur boulot ; faudrait leur demander pour avoir plus de précisions)

            • [^] # Re: Optimisations JavaScript

              Posté par . Évalué à 2.

              Pour Pypy, il y a eu visiblement différents soutiens, notamment européens, depuis quelques années. Plusieurs millions d'euros auraient été investis, entre 2004 et 2007, depuis 2009 également. Google et la Python Software Foundation auraient aussi mis quelques billes.
              A côté de cela, il y a plusieurs appels à dons en ce moment : 105 000 $ pour le support de Python3 et 60 000 $ pour Numpy.

              Du côté de LuaJIT, plusieurs sponsors ont aidé au développement de fonctionnalités, notamment des ports vers de nouvelles architectures (par exemple 20 000 $, dont 8 000 de Google, pour le port vers x64 - pas de chiffres pour les autres). Il y a aussi un chiffrage de dons récurrents : 15 000 $ annuels par iNTERFACEWARE.

      • [^] # Re: Optimisations JavaScript

        Posté par . Évalué à 2.

        Pour FF, note que la description de JägerMonkey (l'optimisation du code par inférence de type) ressemble furieusement à ce qui était fait sur Self, par contre la mémoïzation automatique de TraceMonkey la description me parait à peine croyable..

        Bon même si l'optimisation du code par inférence de type est une technique connue, l'implémenter et vérifier que ça fonctionne bien représente un énorme travail effectivement.

    • [^] # Re: Optimisations JavaScript

      Posté par . Évalué à -6.

      Sur mon AMD Athlon(tm) II X2 215 Processor (2800 Mhz en vitesse de pointe) :

      Firefox 12.0a1 : 5560.4ms sur Kraken ; 271.2ms sur Sunspider ; 4756 points sur le benchmark v8.

      • [^] # Re: Optimisations JavaScript

        Posté par . Évalué à 7.

        Sans point de comparaison avec un autre navigateur (Chrome ou Firefox 8 ou 9), il est impossible de savoir si ces chiffres sont impressionnants ou mauvais.

    • [^] # Re: Optimisations JavaScript

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

      Je n'ai pas un résultat aussi impressionnant :

      1.33x as fast 7656.7ms +/- 0.6% 5759.6ms +/- 0.5% significant

      Par contre, j'ai une régression pour

      crypto-pbkdf2: *1.61x as slow* 326.1ms +/- 1.1% 526.5ms +/- 1.3% significant

      Je me demande pourquoi et ce que ça implique.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Interface

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

    En ce moment j'ai de temps en temps des petits soucis de chargements sur Chromium 17 (images avec le symbole d'erreur de chargement qui fonctionne si je recharge la page, page qui reste blanche, ...).
    Et puis la consommation mémoire est juste affolante.

    Du coup j'ai installé Firefox 9 pour voir si le problème venait du browser ou de ma connection, mais vu que c'est quand même un bug assez rare, il va falloir que je l'utilise une ou deux semaines pour voir si je le reproduit ou pas. Et pour la mémoire Firefox 9 pourrait être plus efficace également.

    Du coup je me retrouve confronté à des différences au niveau de l'interface.

    • Le truc principal c'est le changement d'onglets par défilement de la molette de la souris.
    • Il y a aussi la page de nouvel onglet qui est finalement bien pratique.
    • Et aussi la recherche web dans la barre d'adresse, que j'utilisais déjà à l'époque de Mozilla Suite, puis Seamonkey, qui n'est pas présent dans Firefox (il faut utiliser la lettre "g", tu parles d'une "awesome bar"), qui fonctionne de manière très pratique sur Chromium (avec suggestion des résultats).
    • Les onglets qui défilent à partir d'un certain nombre, au lieu de diminuer encore.

    Mais il y a un contournement: en rajoutant des extensions (sauf pour le scroll des onglets, il faut aller modifier le style css de firefox à la main à priori, j'ai laissé tomber...).

    J'avoue que je suis assez déçu de l'orientation de Firefox en ce qui concerne l'UI, quand on arrive de Chromium avec une interface épurée et pratique ça fait bizarre on se croirait presque revenir dans les années 90.
    (Pour la RAM la solution ça serait peut-être de me commander 4Go et puis ça sera réglé)

    • [^] # Re: Interface

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

      En ce moment j'ai de temps en temps des petits soucis de chargements sur Chromium 17 (images avec le symbole d'erreur de chargement qui fonctionne si je recharge la page, page qui reste blanche, ...).

      C'est pas la 16.0.912.63 la version stable de Chromium ? À priori là tu es sur une version alpha (enfin, « dev » dans la terminologie du projet).

    • [^] # Re: Interface

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

      J'avoue que je suis assez déçu de l'orientation de Firefox en ce qui concerne l'UI, quand on arrive de Chromium avec une interface épurée et pratique

      C'est surtout une question de goûts, personnellement je préfère l'interface de Firefox, et je trouve d'ailleurs qu'elle s'est énormément améliorée avec les dernières versions.

    • [^] # Re: Interface

      Posté par . Évalué à 2. Dernière modification le 21/12/11 à 12:52.

      Et aussi la recherche web dans la barre d'adresse, que j'utilisais déjà à l'époque de Mozilla Suite, puis Seamonkey, qui n'est pas présent dans Firefox (il faut utiliser la lettre "g", tu parles d'une "awesome bar"), qui fonctionne de manière très pratique sur Chromium (avec suggestion des résultats).

      Je sais pas si il n'y a pas un problème de configuration chez toi, mais chez moi il me suffit de taper un mot, puis enter, il cherche quelque instant à charger une page et si rien n'est trouvé, il fait une recherche Google.
      Par contre effectivement pas de suggestion de résultat hors historique et bookmarks

      La page nouvel onglet est prévue pour la version 12 (https://wiki.mozilla.org/Features/Release_Tracking)

    • [^] # Re: Interface

      Posté par . Évalué à 2.

      Mais il y a un contournement: en rajoutant des extensions (sauf pour le scroll des onglets, il faut aller modifier le style css de firefox à la main à priori, j'ai laissé tomber...).

      Tab Mix Plus le fait (et pleins d'autres choses).

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

      • [^] # Re: Interface

        Posté par . Évalué à 0.

        je suis en 18 et j'ai pas réinstallé depuis un moment...met à jour...

  • # adieu tracemonkey

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

    c'est pourquoi le code de TraceMonkey sera supprimé dans une version ultérieure

    Il est en fait déjà supprimé du trunk depuis un bon mois. La prochaine version qui en profitera c'est bien Firefox 11. Mais à priori, la fonctionnalité avait été déjà désactivée, donc pour l'utilisateur, il n'y aura pas de changement, si ce n'est un binaire un peu moins gros (67 000 lignes de code en moins)

  • # Je n'utilise plus Firefox

    Posté par . Évalué à -5.

    Je suis en Debian testing, et les mises à jours d'Iceweasel mettent la pagaille (pour ceux qui ne connaisse pas, iceweasel, c'est FF sauce Debian). Par exemple, ma "developer toolbar" n'était plus compatible. Une tentative de réinstallation a planté et conduit à la suppression de cette extension. Or FF sans ses extensions n'a pas de grands atouts face à ses concurrents. Mais le pire est qu'à chaque démarrage il y a un risque de perturbation de l'interface (par exemple, plus de "mouse gestures" auquel je suis très attaché).
    J'ai envisagé de revenir à la version stable de FF, mais dans Debian, c'est une 3.5, donc c'est inutilisable en pratique (vous avez dit CSS3 ? ecmascript ?).

    Je me suis finalement décidé à arrêter d'utiliser FF en attendant qu'il se stabilise. Je ne testerai pas cette version 9.

    • [^] # Re: Je n'utilise plus Firefox

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

      Par exemple, ma "developer toolbar" n'était plus compatible.

      je ne sais pas si c'est de celle-là dont tu parles https://addons.mozilla.org/en-US/firefox/addon/web-developer/ (qui est compatible ff9) . Mais tu sais que tu en a plein d'autres des extensions pour developpeurs...

      Je me suis finalement décidé à arrêter d'utiliser FF en attendant qu'il se stabilise.

      Comment ça qu'il se stabilise ? Toutes les nouvelles versions sont stables... Et dorénavant il y en a toutes les 6 semaines.

      Et puis tu sais que Debian ne t'oblige pas à utiliser leur paquet. Tu peux très bien aller sur le site de mozilla pour récupérer un beau binaire Firefox 9.0. http://getfirefox.com . J'ai toujours fait ça et ça fonctionne très bien.

      • [^] # Re: Je n'utilise plus Firefox

        Posté par . Évalué à 3.

        Mais tu sais que tu en a plein d'autres des extensions pour developpeurs...

        Sauf que les plus connues sont présentes dans les dépôts Debian, et c'est bien pratique de les installer en même temps que Firefox pour tous les utilisateurs du système. Et c'est pratique aussi de gérer les mises à jour par le même outil que le reste du système.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Je n'utilise plus Firefox

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

          Alors, il faut rester cohérent. C'est normal que ça pète si tu installe les extensions du dépôt principal tout en installant le firefox du dépôt mozilla.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Je n'utilise plus Firefox

          Posté par . Évalué à 2.

          Les extensions sont quand même dans le profil quand tu fait ça ?

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

          • [^] # Re: Je n'utilise plus Firefox

            Posté par . Évalué à 2.

            Oui, tu peux les désactiver et même les mettre à jour manuellement (mais ça désynchronise avec le système). Elles sont juste d'emblée présentes dans un nouveau profil.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Je n'utilise plus Firefox

      Posté par . Évalué à 6.

      Bizarre... je suis en Debian stable et les mises à jour de Iceweasel (en utilisant les backports mozilla.debian.net) ne m'ont jamais posé de problème.
      As-tu pensé à supprimer les paquets obsolètes inférieurs à la v9 de "libmozjs" et "xulrunner" ?

    • [^] # Re: Je n'utilise plus Firefox

      Posté par . Évalué à 6.

      J'aime bien le "en attendant qu'il se stabilise" =)
      Debian Unstable avec Iceweasel Experimental: no problème à signaler. Le soucis des extensions tend réellement à s'améliorer depuis 2-3 versions. Je n'utilise pas mouse gesture, mais "Add-on compatibility reporter" me permet de faire fonctionner toutes mes extensions.
      L'inconvénient de Debian est effectivement que les versions dites stables de logiciel sont un peu obsolètes, mais l'avantage, c'est que tu peux tester (avec les dépôts officiels) jusqu'à 3 versions différentes.

      Or FF sans ses extensions n'a pas de grands atouts face à ses concurrents.

      Nan, il consomme juste 3 fois moins de mémoire que Chromium/Chrome ... mais c'est vrai qu'avec la démocratisation des 4Gb de ram minimum un peu partout (ouai on va vers les 8 now^^), c'est pu un avantage (chez moi Iceweasel consomme 3 fois moins de ram avec 20 extensions que Chromium sans extensions).

      Sinon, je crois que j'avais eu quelques soucis d'install sur la version 8, mais du coup je suis passé directement de la 7 à la 9.

      J'ai toujours pensé que firefox valait la peine d'être suivi et vu le développement actuel, j'y crois encore plus =)

    • [^] # Re: Je n'utilise plus Firefox

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

      Je suis sous Debian et j'utilise Firefox (pas Iceweasel) ... ça me coûte une p'tite install manuelle. Mais bon, une fois de temps en temps ;-)

      • [^] # Re: Je n'utilise plus Firefox

        Posté par . Évalué à 4.

        Avec le dépôt mozilla.debian.net ça n'a plus d'utilité. J'ai eu la mise à jour vers la version 9 (sur Debian Stable) hier matin.

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

        • [^] # Re: Je n'utilise plus Firefox

          Posté par (page perso) . Évalué à 2. Dernière modification le 22/12/11 à 20:02.

          Es tu sûr que c'est en stable ?

           % apt-cache policy iceweasel
          iceweasel:
            Installé : 8.0-3~bpo60+1
            Candidat : 8.0-3~bpo60+1
           Table de version :
               10.0~a2+20111216042030-1 0
                    9 http://mozilla.debian.net/ experimental/iceweasel-aurora amd64 Packages
               10.0~a2+20111216042030-1~bpo60+1 0
                   50 http://mozilla.debian.net/ squeeze-backports/iceweasel-aurora amd64 Packages
               9.0-1 0
                   50 http://ftp.fr.debian.org/debian/ sid/main amd64 Packages
               9.0-1~bpo60+1 0
                   91 http://mozilla.debian.net/ squeeze-backports/iceweasel-release amd64 Packages
               9.0~b6-1~bpo60+1 0
                   90 http://mozilla.debian.net/ squeeze-backports/iceweasel-beta amd64 Packages
               8.0-3+b1 0
                   90 http://ftp.fr.debian.org/debian/ wheezy/main amd64 Packages
           *** 8.0-3~bpo60+1 0
                  100 /var/lib/dpkg/status
               3.6.24-1 0
                  500 http://mozilla.debian.net/ wheezy/iceweasel-3.6 amd64 Packages
               3.6.24-1~bpo60+1 0
                  500 http://mozilla.debian.net/ squeeze-backports/iceweasel-3.6 amd64 Packages
               3.6.24-1~bpo50+1 0
                  500 http://mozilla.debian.net/ lenny-backports/iceweasel-3.6 amd64 Packages
               3.5.16-11 0
                  990 http://security.debian.org/ squeeze/updates/main amd64 Packages
               3.5.16-11~bpo50+1 0
                    1 http://backports.debian.org/debian-backports/ lenny-backports/main amd64 Packages
               3.5.16-10 0
                  990 http://ftp.fr.debian.org/debian/ squeeze/main amd64 Packages
               3.0.6-3 0
                  500 http://ftp.fr.debian.org/debian/ lenny/main amd64 Packages
                  500 http://security.debian.org/ lenny/updates/main amd64 Packages
          
          

          Edit : Je ne sais pas lire.

        • [^] # Re: Je n'utilise plus Firefox

          Posté par . Évalué à 1.

          Oui, il faudra juste penser, si on veut Firefox en français, à récupérer le fameux fr.xpi dans releases.mozilla.org/pub/mozilla.org/firefox/releases/ à chaque maj... (> /$version/$architecture/xpi/fr.xpi)

  • # Support long durée ?

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

    Des news sur le support de cette version ?

    En septembre, il a été annoncé que cette version serait peut être la première à bénéficier d'un support longue durée ... sauf que je ne vois aucune annonce la dessus ?

    ( ... parce que ce n'est pas pour une remettre une couche ... mais changer de version tous les 3 mois c'est plus que problématique ... )

    • [^] # Re: Support long durée ?

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

      Non, c'est Firefox 10 qui sera, à priori, la première version qui bénéficiera d'un support "longue durée" (1 an). Mais pour le moment, rien n'est confirmé officiellement.

  • # Onglets en vertical

    Posté par . Évalué à 10. Dernière modification le 21/12/11 à 18:43.

    À quand une option permettant de disposer les onglets verticalement ?

    Ça fait des années qu’Opera le fait et ce serait encore plus approprié maintenant que la mode est aux écrans larges.

    Il y a bien de très sympathiques extensions pour le faire (Tree Style Tab, Vertical Tabs...), mais elles ne cohabitent pas toujours bien avec d’autres extensions sympathiques, donc si ça pouvait un jour être en natif...

    Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

  • # Bha ils lui ont collé des stéroïdes au rongeur ... ?

    Posté par (page perso) . Évalué à 6. Dernière modification le 22/12/11 à 03:41.

    Ca y est je viens à nouveau de redevenir pro-machinrouge ... voyant cette news je ne peux m'empêcher de réagir -et de m'inscrire pour le coup-

    Bloqué sur une version 3.6 et utilisant principalement le concurrent d'en face depuis pas mal de temps, je me suis laissé aller à l'installer manuellement... je ne sais pas si c'est l'effet placébo nouveauté -probablement que si- ,mais le chargement de l'appli et l'affichage sur linux-fr par exemple est quasi-instantanée (cache vide) mais avec profil du 3.6 >> with modules, même le chargement de sites bien lourds (type actu) est du genre ultra-véloce, enfin tel fut mon ressenti lors du premier lancement. ça fait plaisir de retrouver ce sentiment de vitesse, qui je trouve s'effritait dans la maison Mozilla avec le temps et les versions (depuis les 1.x)

    C'est bien, la concurrence active ça a vraiment du bon :)

Suivre le flux des commentaires

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