Journal Des news de Firefox

Posté par (page perso) .
Tags : aucun
36
9
déc.
2009
Parce qu'on parle beaucoup de chrome en ce moment, je me suis dit que ce serait une bonne idée de vous faire une simple liste des trucs sur lesquels on (Mozilla) bosse en ce moment:

* release majeure tous les 6 mois (ce n'est pas évident, mais on va essayer)
* 3.6 qui débarque avec support de la File API, du lourd: http://www.w3.org/TR/FileAPI/ , un tracemonkey plus rapide et des grosses améliorations CSS 3. Niveau UX, Personnas intégré (nouveau gestionnaire de theme)
* 3.7 ensuite très orienté graphisme (SMILE, SVG animations, CSS Transitions, WebGL - mais on en chie sous Linux avec la 3D, ...)
* 4.0 avec une nouvelle UX, truc beaucoup plus clean et moins "à la Netscape 2.0" et plus "à la Chrome simpliste", mais pas trop :)
* MozMessenging: Thunderbird 3 avec un paquet de trucs
* MozMessenging: Raindrop (https://wiki.mozilla.org/Raindrop )
* startup plus rapide (http://autonome.wordpress.com/tag/startup/ )
* jetpack, aka Extensions 2.0 - on va essayer de l'intégrer à Firefox directement
* Electrolysis (multi-process, aujourd'hui ça fonctionne bien pour les plugins. Bientôt, plus de crashs à cause de Flash)
* Parser HTML5
* Fennec (Firefox pour mobiles, on va bientôt releaser pour le n810 et le n900, on bosse aussi sur une version Android)
* Weave, qui va permetre de tout synchroniser (Fennec, Firefox au bureau, Firefox au travail)
* Identité dans le browser (http://blog.mozilla.com/about_mozilla/#identity )
* beaucoup d'énergie dans Firebug
* des trucs spécifiques à Windows (Direct 2D rendering)

... plein d'autres trucs que j'oublie (surtout pour l'UI/UX).

Tous ces projets sont en cours de développement, releasé ou pas, mais très actifs.

À propos de TB3, on est loin de le laisser de côté, mais oui, il y a moins de ressources pour Thunderbird que pour Firefox. Mais on a quand une grosse équipe qui bosse dessus (plus importante et plus structurée qu'à l'époque de TB2).

N'hésitez pas si vous avez des questions, mais évitons les trolls :)
  • # Ca tombe à pic...

    Posté par . Évalué à 6.

    ...aprés le journal sur Google Chrome.

    Et je pense qu'il faudrait le faire savoir "à la google".

    Mais difficile d'être présent sur tous les tableaux. Allez, j' vais aller faire un don ! :D
  • # Coool

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

    Merci pour le travail accompli et encore à accomplir :)
    C'est sûr que la concurrence chère à Mozilla est rude ces derniers temps ... et c'est tant mieux!

    Vivement la mort de ie 6 d'abords et 7-8 ensuite :)

    Un truc qui me manque comme dev web c'est la possibilité de sélectionner plusieurs fichier dans un input file avec multiple (htm5 inside)... j'espère que on verra apparaître cette fonctionnalité dans la 3.6
  • # Une question bête...

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

    J'ai une question assez bête : pourquoi dans Thunderbird la rédaction de mails se fait dans des fenêtres séparées et pas dans des onglets ?

    Sinon, chapeau à l'équipe Mozilla pour tout le travail accompli.
    • [^] # Re: Une question bête...

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

      Oui, c'est lourdingue.

      On y pense très très fort :) ... mais il se trouve que le code pour la rédaction d'un message est particulièrement compliqué (et ça c'est pas normal) et que c'est pas évident à coller dans un onglet, mais on y travaille.
  • # à la bourre

    Posté par . Évalué à 5.

    t'es à la bourre avec ton annonce du futur
    * MozMessenging: Thunderbird 3 avec un paquet de trucs

    il me semble qu'il est sorti hier ;)

    bon sinon, j'adore ce que vous (Mozilla) faites ;)
    • [^] # Re: à la bourre

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

      C'est pour ça que je précise:
      "Tous ces projets sont en cours de développement, releasés ou pas, mais très actifs."

      :)
  • # La troidé sous X.Org

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

    mais on en chie sous Linux avec la 3D

    Faire de la troidé sous {X.Org|MacOS|Windows}, ça ne se résume pas à utiliser l'API OpenGL et puis voilà ?
    • [^] # Re: La troidé sous X.Org

      Posté par . Évalué à 1.

      C'est ça ou bien : DirectX et volià.
    • [^] # Re: La troidé sous X.Org

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

      ça c'est la théorie. En pratique, certaines fonctions sont mal implémentées dans les pilotes réèls, ou non implémentées. Un rendu OpenGL logiciel, c'est très très lent.

      Donc, il faut juste utiliser ce qui marche partout, sous peine de voir tout le monde quitter Firefox parce que ça rame sous Linux avec des pilotes libres....

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

    • [^] # Re: La troidé sous X.Org

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

      Et non :(

      Faire fonctionner WebGL avec une carte ATI ou Intel, c'est la misère.
      Mais on utilise OpenGL, mais avec les différentes versions et les extensions, galères...
      • [^] # Re: La troidé sous X.Org

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

        Et sinon faire simplement du web, mais bien, au lieu de transformer un brouteur en usine à gaz, ça peut être bien non ?

        Je sais c'est pas trop à la mode, y'a pas buzz dedans, ça bouge pas dans tous les sens, donc dans la presse ça le fait moins...

        « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

        • [^] # Re: La troidé sous X.Org

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

          Oui, tu as raison... on va laisser de côté l'implémentation de nouveaux standards et de nouvelles fonctionnalités, bêtes que nous sommes :(
          • [^] # Re: La troidé sous X.Org

            Posté par . Évalué à 2.

            Lorsque les standards sont complètement débiles, ce n'est pas un mal de les laisser de côté.

            « Mediocrity finds safety in standardization. »
            -- Frederick Crane
          • [^] # Re: La troidé sous X.Org

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

            Vous feriez mieux de vous occuper des standards existants déjà. On ne peux toujours pas mettre de SVG en background-image ou dans un dans Firefox... Et oui.

            Pourtant pour "remplacer Flash" comme le dis Laurent, SVG c'est déjà une étape un peu plus utile que la 3D. Je parle même pas de SMIL qui va peut-être bientôt être implémenté dans FF 3.7. Une spéc qui a 8 ans, comme SVG... Et y'a encore beaucoup de boulot pour rattraper le reste du monde : http://www.codedread.com/svg-support.php

            Donc oui pour le moment repousser l'implémentation de nouveaux trucs buzz/hype ça peut être pas mal, pour avoir déjà un support correct des standards existants. Ah c'est sûr ça permet pas de faire des trucs qui clignotent et bougent dans tous les sens (démo à paris web), mais ça, c'est *vraiment* beaucoup "demandé" comme le dis Laurent.

            « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

            • [^] # Re: La troidé sous X.Org

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

              SMIL est déjà en grande partie implémenté dans la version 3.6 qui arrive. C'est juste désactivé par défaut. (about:config chercher smil)

              Et sinon, je ne sais pas si tu te rend compte de certaines choses aussi : compare par exemple la spec de SVG/SMIL, avec la spec openGL. Implémenter SVG, c'est un véritable braquage en terme de ressources humaines, tellement la spec est un pavés de plusieurs centaines de pages. Implémenter la 3D dans canvas ? c'est rien à coté de SVG, vu que des libs qui implémentant openGL existent déjà. Coté intégration donc, y "juste" à faire du mapping js <--> lib openGL, surtout qu'il ne s'agit ici que de dessiner dans une surface limité (canvas), avec aucune interaction avec le reste du document (par ex, pas de reflow sur le rendu HTML quand on dessine dans Canvas, ce qui n'est pas le cas quand il s'agit d'intégrer/modifier des bouts de svg dans le document) .

              Implémenter SVG, ce n'est pas que faire appel à des primitives graphiques 2D, mais il y a aussi à implémenter son DOM, ses propriétés CSS spécifiques, son moteur de rendu, sans compter tout ce qui est timeline/synchronisme pour SMIL, et j'en passe.

              Bref, comparons ce qui est comparable en terme d'implémentation. On n'est pas du tout dans la même échelle.
            • [^] # Re: La troidé sous X.Org

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

              "Vous feriez mieux de vous occuper des standards existants déjà. On ne peux toujours pas mettre de SVG en background-image ou dans un dans Firefox... Et oui."

              Oui, mais ça c'est normal. C'est une question de choix, et pas un problème technique.
              Le truc c'est: "SVG, est-ce un document ou une image?". On est pas encore certain que ce soit une bonne idée de mettre un "document" en background.

              Mais a priori, on va tout de même le permettre (je ne sais pas pour quand).

              Mais bon, tu ne comprends pas qu'on peut avancer en parallèle sur différentes technos.
              On ne peut pas par example mettre l'équipe jetpack ou Fennec sur SVG.

              Et *tes* priorités ne sont peut être pas celles de tout le monde.

              On innove (oui, ça fait du buzz). On avance aussi sur les standards bien établis (on en parle moins probablement).

              Mais bon, on ne peut satisfaire tout le monde.
        • [^] # Re: La troidé sous X.Org

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

          C'est du web. Il faut que le web evolue, parce que les développeurs ont *besoin* de fonctionnalités plus puissantes.

          Peut être que tu ne vois pas l'intérêt de pouvoir utiliser openGL dans une page web, mais beaucoup le demande. Ce n'est pas pour faire du buzz. C'est vraiment pour répondre à un *besoin* : les jeux, les contenus éducatifs (pouvoir par exemple visualiser une molécule sous toute ses coutures), les contenus informatifs. ex: un site immobilier permettant de visiter les futurs appartements en 3D, ou encore la visualisation d'une collision dans un accélérateur de particules, etc.

          Ce n'est pas parce que tu trouves tout ça inutile, que c'est le cas du reste du monde. L'information, ce n'est pas que du plat, du static. c'est aussi de l'interaction.

          Il y a un autre avantage à implémenter des trucs "qui bouge dans tout les sens", c'est que petit à petit, ça nous permet de virer flash et consort. Et ce n'est pas rien.

          Si tu veux utiliser un brouteur qui ne fais afficher que du HTML à papa, installe Mosaic.
          • [^] # Re: La troidé sous X.Org

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

            Mettre tout et n'importe quoi sur le Web, ça ne répond pas à un besoin, non. Ça répond à une volonté, stupide, d'utiliser le Web pour tout, or Internet n'est pas le Web.

            Là, y mettre de la troidé, je trouve que ça a du sens, dans des pages Web. Mais faire des jeux vidéos, non. Faire de la messagerie instantanée, non plus, par exemple.
            • [^] # Re: La troidé sous X.Org

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

              Sérieusement, j'ai l'impression d'entendre un vieux refractaire à l'innovation, ou encore tim berners lee lorsqu'il fut effrayé quand il appris que Mosaic avait implémenté la balise .


              > Ça répond à une volonté, stupide, d'utiliser le Web pour tout, or Internet n'est pas le Web.

              Pour visualiser de la 3D sur internet, il faudrait quoi alors ? un programme à coté ? super pratique pour illustrer un document... web.

              Pour lire une video, il faudrait quoi ? un programme externe ? super pratique là encore pour illustrer un document, et surtout ça donne l'impossibilité à la page web de l'intégrer dans le document, de mixer correctement la vidéo avec le reste du contenu. (ce qu'on peut faire avec la balise video et CSS/JS est tout simplement impossible avec un plugin ou l'utilisation d'un programme externe, cf demos de paul rouget)

              >Mais faire des jeux vidéos, non.

              et pourquoi pas ?

              Très franchement, quels sont les raisons à ne pas vouloir faire en sorte qu'on puisse utiliser une plateforme commune pour jouer, lire, ou faire certaines tâches ?

              Pourquoi avoir inventer javascript alors ? Pourtant il rend bien des services. Comme celui de pouvoir developper des wbemails, que certains cherissent tant et qui se demandent pourquoi les clients lourds mails existent encore.

              C'est bien parce que ça rend service à une partie des utilisateurs. Qu'ils ont *besoin* de ce service.

              Et bien voilà, le web evolue, parce que les besoins evoluent. les utilisations des technos changent. la manière d'utiliser internet change. Il faut donc proposer des outils, des technos, pour que cette utilisation soit plus simple, et surtout qu'il soit plus simple à développer les applications qui sont nécessaires à ces besoins.

              >Faire de la messagerie instantanée, non plus, par exemple.

              qui a parlé de messagerie instantanée ?
              • [^] # Re: La troidé sous X.Org

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

                Pardon, je ne critiquais pas directement le fait d'introduire de la troidé, simplement le fait de mettre tout et n'importe quoi dans le Web. La troidé y a sa place, comme les images, le son et la vidéo.
              • [^] # Re: La troidé sous X.Org

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

                "ou encore tim berners lee lorsqu'il fut effrayé quand il appris que Mosaic avait implémenté la balise ."

                Quelle balise??? (je ne connais pas l'histoire)
              • [^] # Re: La troidé sous X.Org

                Posté par . Évalué à 3.

                En fait je pense que ça surprend du monde de voir un navigateur se transformer en machine virtuelle. Surtout que, sorti de la balise canvas, l'api pour manipuler l'interface (DOM, BOM...) est quand même pas évidente (au début ça va mais on tombe vite sur des cas particulier de rendus, d'events qui trainent partout..)
                En fait, maintenant que java est libre, on pourrait envisager de programmer les contenus 3d de façon à utiliser le java-browser-plugin, et ainsi économiser le temps qu'il faudrait pour développer une api équivalente dans le browser, un interpréteur JS JIT et reporter toutes les contraintes de cross-platform à l'implémentation de la JVM...
                Après ça résout pas le probleme de la communication entre les divers composants: la balise video est facilement manipulable en js, ce qui, je crois, est pas le cas de la balise embed, mais je trouve ça dommage que les plugins soient passés de mode.
          • [^] # Re: La troidé sous X.Org

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

            « Peut être que tu ne vois pas l'intérêt de pouvoir utiliser openGL dans une page web, mais beaucoup le demande. »

            D'oh ! C'est vrai que la 3D sur le web c'est l'avenir, y'a qu'à voir le succès immense de VRML ou SCOL... 15 ans plus tard y'en a sur tous les sites web... Ah tiens non, c'est bizarre.

            « Peut être que tu ne vois pas l'intérêt de pouvoir conduire avec 10g d'alcool dans le sang, mais beaucoup le demandent. »

            « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

            • [^] # Re: La troidé sous X.Org

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

              > y'a qu'à voir le succès immense de VRML ou SCOL

              C'est pas utilisé parce que :

              1) ce n'est pas implémenté par les navigateurs (ils avaient d'autres choses plus "basiques" à implementer)
              2) c'était peut-être des technos à chier, trop compliquées à utiliser, ou encore pas assez riche (c'est une hypothèse, je ne les connais pas), et surtout étrangère à ceux qui font de la 3D.
              3) peut être aussi un problème de puissance des machines. à l'epoque de VRML, la plupart des machines vendues n'avaient pas de carte 3D -> performances inadéquates pour faire de la 3D. alors que maintenant, toutes machines comportent une puce pour faire de la 3D.
              3) il y avait d'autres chats à fouetter, le web dans son ensemble n'était peut être pas assez mature (faut voir le temps que ça a mis pour que les dev utilisent javascript correctement)


              alors que bon, tout bon programmeur 3D connait openGL, ou en tout cas les principes fondamentaux de la 3D sur lesquels reposent openGL. Ils auront alors beaucoup moins de mal à "s'exprimer" sur le web qu'avec des technos underground comme VRML.

              Ce n'est pas parce que un truc n'a pas marché il y a quelques années, que ça ne marchera pas maintenant, avec les évolutions technologiques tant matériels que logiciels qu'il y a eu.
              • [^] # Re: La troidé sous X.Org

                Posté par . Évalué à 2.

                "alors que bon, tout bon programmeur 3D connait openGL"
                OpenGL est très bas niveau. Si l'on doit se contenter d'OpenGL pour faire de la 3D, ça va vite devenir super chiant, et j'ai du mal à imaginer ce que donneraient des libs comme Ogre portés en javascript...
      • [^] # Re: La troidé sous X.Org

        Posté par . Évalué à 2.

        J'ai du mal à comprendre, vous utilisez des fonctions tellement évoluer en openGL que les implémentations incomplètes de ATI et la lenteur des intel posent problèmes ?

        Intel est lent je veux bien le croire mais il me semblait que leur implémentation d'opengl était correct.

        "La première sécurité est la liberté"

        • [^] # Re: La troidé sous X.Org

          Posté par . Évalué à 2.

          Ouais, si on peut faire tourner un cube transparent avec des poissons dedans et des fenêtres en 3D sur lesquelles il neige, on est capable de faire la même chose dans un navigateur, normalement :)

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

  • # Démarrage du navigateur

    Posté par . Évalué à 2.

    C'est le moment d'en profiter pour poser des questions vu que vous êtes à SF en plus (plus proches des devs) :)

    Une question que j'ai vu souvent sur d'autres sites et qui n'est pas si conne : pourquoi une UI différent pour la version 3.7 et 4.0 ? Autant directement faire celle pour la 4.0.

    Une question que je pose pour d'autres car je m'en fou j'ai un Mac :
    Pourquoi les temps de démarrage sous Linux et Windows ont autant de mal à être améliorés ? cf. les derniers chiffres :
    Summary, relative to Firefox 3.5:
    * Warm startup: For Mac, 36% better on 3.6 and 35% better on 3.7. For Windows, 5% and 5%. Flat on Linux.
    * Cold startup: For Mac, 20% better on both 3.6 and 3.7. For Windows, not measuring yet. For Linux, we're seeing a regression of ~9% across branch and trunk in the snapshot but not on the graphs, so we need to figure out where the discrepancy is.
    • [^] # Re: Démarrage du navigateur

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

      Parce que la nouvelle UI de 4.0 est un gros boulversement, on a besoin de temps pour tout mettre en place.

      Pour le startup, je ne sais pas.
      • [^] # Re: Démarrage du navigateur

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

        J'espere juste que cela s'integrera mieux aux desktops KDE & Gnome. :D

        En tout cas, vue la roadmap, bon courage. Vous avez l'air de vous attaquer à tous les défauts de la bête... sympa de voir un projet vivant comme celui ci.
  • # Raindrops

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

    * MozMessenging: Raindrop (https://wiki.mozilla.org/Raindrop )

    Bon. Raindrop, si j'ai bien compris, c'est une collection de parseurs pour afficher directement dans une lettre électronique des contenus tirés de services Web centralisés. Donc, ça va vers le tout Web, une belle connerie à mes yeux, et vers du bon vieux Minitel.

    En attendant, on a aussi le messagerie instantanée, dans le genre truc intéressant qui aurait sa place dans un logiciel de messagerie. Jabber, ça n'intéresse pas Mozilla parce que ce n'est pas Web ?
    • [^] # Re: Raindrops

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

      C'est plus complexe que ça.

      L'idée est d'avoir un moteur de traitement et d'aggrégations de messages qui pourra être requeté à travers une UI XUL (Thunderbird 4) ou via une page web.

      Le moteur pourra se trouver coté web, mais rester aussi sur le desktop.
    • [^] # Re: Raindrops

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

      Raindrop, si j'ai bien compris, c'est une collection de parseurs pour afficher directement dans une lettre électronique des contenus tirés de services Web centralisés.

      Pas vraiment, dans ce sens que c'est surtout un genre de Webmail sous stéroides, qui trie tes messages pour toi (genre les notifications qu'on reçoit par mail, il te les affiche d'une façon différente de messages qui te sont envoyés par ton patron).

      Surtout c'est un framework qui va te permettre de rajouter des modules pour interfacer plusieurs protocoles en plus de ceux du mail.

      Mais c'est bien une application Web, oui.

      Donc, ça va vers le tout Web, une belle connerie à mes yeux, et vers du bon vieux Minitel.

      C'est vrai que le tout-Web peut aller vers le Minitel 2.0, mais ça dépend qui le fait et comment. Si c'est une application Web propriétaire qui tourne uniquement sur des serveurs qui sont tous contrôlés par la même boite, et sans possibilité d'exporter tes données, pas de doute, c'est bien du Minitel 2.0.

      Par contre, si c'est du logiciel Libre que tu peux télécharger, installer sur ton propre serveur voire même ton propre ordi perso, qui est foncièrement extensible, et que tu peux transporter tes données d'une instance à l'autre, alors t'as tous les avantages du Webmail (et bien plus, dont la messagerie instantanée) en plus de la liberté. `

      Si ces conditions sont réunies, alors nous sommes bien loin du Minitel 2.0 !

      En attendant, on a aussi le messagerie instantanée, dans le genre truc intéressant qui aurait sa place dans un logiciel de messagerie. Jabber, ça n'intéresse pas Mozilla parce que ce n'est pas Web ?

      J'espère bien qu'il y aura un module Jabber dans Raindrop. Tu te portes volontaire ? ;-)
      • [^] # Re: Raindrops

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

        Mais c'est bien une application Web, oui.

        Merci de le préciser. Les pages qui en parlent sur le sites de Mozilla sont tellement peu claires que je ne l'avais pas compris. Pour moi, c'était simplement un logiciel de messagerie intégrant une collection de parseurs hétéroclites pour afficher des informations provenant de services propriétaires massivement centralisés.

        Donc en fait, c'est un webmail avec une collection de parseurs. Mozilla réfléchit à un nouveau logiciel , et c'est un webmail. La claque… Je savais déjà que Mozilla poussait le Web à tout prix, pour faire n'importe quoi, mais à ce point, quand même…
  • # Et XMPP ?

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

    Hello Paul,

    Merci pour ce rapide néanmoins complet journal...

    Mais... m... mais... y'a toujours pas de XMPP dans la roadmap de la Fondation Mozilla ?

    Comment faut-il l'expliquer ? Vous avez fait Weave à partir de zéro, vous avez réinventé la roue, vous avez mis du temps, et derrière il faut encore installer un plugin et un serveur, même si ce dernier est libre... Alors qu'avec XMPP, un user n'a qu'à installer un plugin et utiliser son compte XMPP... C'est pas sorcier pourtant, on a développé OneWeb en 5 jours seulement (et on va peut-être le porter sur mobile sur Fennec sous Maemo).

    http://www.pcinpact.com/actu/news/54352-processone-oneweb-xm(...)
    http://www.generation-nt.com/firefox-oneweb-xmpp-messagerie-(...)
    http://www.process-one.net/en/blogs/article/oneweb_demonstra(...)

    La grosse étape suivant le Web 2.0 est sans aucun doute le web temps-réel (ou « real-time web »). De nombreux hacks plus ou moins moches sont tentés sans trop de succès comme PubSubHubbub, SUP, APE, Comet, SPDY, toussa... Alors que XMPP et BOSH offrent tout cela nativement. Il est donc possible et facile d'offrir le push dans le brouteur, via simple ECMAscript ou via un éventuel plugin/extension, le mieux étant que le brouteur lui-même tchatche le XMPP nativement, ainsi les développeurs d'extensions pourront en bénéficier pour enlarger leur hackability/bidouillabilité.

    Idem, XMPP comme backend sur les serveurs web, ça peut offrir la communication inter-serveur ou S2S (« server-to-server »), l'authent, le multi-party, le multimédia avec traversement des NAT, des vCard et avatars, du publish-and-subscribe (aka « PubSub »), du stockage d'infos privées ou publiques tels que les bookmarks (voir OneWeb), du contrôle à distance (voir OneWeb), de la présence et de la présence étendue, etc. J'en passe !

    Franchement, là je ne vois pas pq Mozilla ne veut pas voir XMPP. Google a déjà pas mal compris, Apple n'a pas encore fait complètement le lien, bien qu'iChat Server soit un serveur XMPP et sur le Push de l'iPhone soit du XMPP...
    • [^] # Re: Et XMPP ?

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

      Je sais que XMPP c'est ton jouet à toi.
      On n'a pas le temps de tout faire non plus :)

      Mais clairement, je trouve aussi que ça a un sens d'intégrer XMPP, mais il y a des priorités (animations, identité, performances, sécurité, mechanisme d'extensions plus simples, ...).

      Il faut aussi définir comment XMPP intervient dans un browser et/ou dans le web (sens "page webs").
      • [^] # Re: Et XMPP ?

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

        Ou dans un logiciel de messagerie…
      • [^] # Re: Et XMPP ?

        Posté par . Évalué à 2.

        N'est il pas possible de mutualiser les efforts avec les extensions existantes ? Il y a OneWeb, cité ci-dessus, mais il semble qu'il en existe également d'autres :
        xmpp4moz ( https://addons.mozilla.org/fr/firefox/addon/3632 ), base du client SamePlace ( https://addons.mozilla.org/en-US/firefox/addon/3633 )
      • [^] # Re: Et XMPP ?

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

        > Je sais que XMPP c'est ton jouet à toi.

        Ce n'est pas sujet, et je ne fait que tenter de le promouvoir.

        > On n'a pas le temps de tout faire non plus :)

        Oui, bah t'as vu la liste énorme que tu nous balances ? Faires des (bons) choix, c'est important et difficile, c'est pour cela qu'il faut chercher de l'aide là où elle se trouve.

        Je pense que XMPP devrait être une des priorités pour Mozilla, car vous êtes les défenseurs du « open internet ».

        > Il faut aussi définir comment XMPP intervient dans un browser et/ou dans le web (sens "page webs").

        Et pourquoi pas laisser faire l'écosystème ? Foutez une pile XMPP avec des zoulies API dans Gecko, parlez-en un peu, et voilà... Non ? Vous avez pourtant l'habitude de laisser expérimenter avec les extensions et les labs, non ?

        Effectivement, comme dit le dit Fabien, il y a xmpp4moz, mais il y a aussi JSJaC ou encore Strophe, bref tout plein de choix.
        • [^] # Re: Et XMPP ?

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

          Et bien je pense que ma liste énorme est bien plus importante que XMPP.
          Après, XMPP, tu peux l'intégrer à travers une extension. Ça ne te convient pas?

          Bon, a priori, tu restes persuadé qu'on doit faire à ta manière, et que sans XMPP, on fait une grosse erreur. Ouvre un bug, écrit ton API et écrit le code!

          Juste dire "integre l'API XMPP", t'es malin, tu te rends compte du boulot?
          Désolé, XMPP n'est pas assez prioritaire, il faut que tu le comprennes. Fais un patch ou va voire l'équipe Thunderbird avec un concept ou bosse avec l'équipe Weave ou envoie une description du projet aux Concept Series, mais arrête de nous dire ce qu'on doit faire.
    • [^] # Re: Et XMPP ?

      Posté par . Évalué à 2.

      Buzzword overflow detected...

      Sinon, si il n'y a pas de contributeurs interesses, ca devrait t'indiquer que peut-etre il n'y a pas tant de demande que ca.

      Mais si tu penses que c'est l'avenir, rien ne t'empeche de contribuer. Ca ne devrait pas te prendre plus de 5 jours pour integrer tout ca. N'oublie pas de nous donner l'url de l'entree dans bugzilla, qu'on puisse tester tout ca.
  • # bravo ...

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

    Mais si vous voulez par perdre des PDM face à chrome/chromium et plus générallement les webkit-based) sous linux.
    Il faudrait surtout, au minimum, rendre la version linux au moins aussi véloce que la version windows.

    Comment expliquer qu'un firefox/win32 est bien plus rapide dans une VM Virtualbox sous linux, que la version native firefox/linux ?!?

    Il y a un truc qui ne va pas ...
    • [^] # Re: bravo ...

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

      +1 mais ne croyez pas que c'est parce qu'on se fiche de Linux (une partie des devs sont sous Linux, dont moi), au contraire, surtout que Linux c'est aussi le monde du mobile.

      Je ne m'y connais pas assez, mais je sais que les devs galères à faire une version Linux rapide sous Linux, et ce n'est pas 100% de notre faute (Gcc, la couche graphique Linux, systeme de fichier, ...), mais un peu quand même :)
      • [^] # Re: bravo ...

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

        Sans être méchant/offensant : "c'est les excuses" habituelles

        Mais force est de constater qu'il y a maintenant, au moins, un navigateur qui n'a rien à envier à son pendant windows, bien au contraire (aka "chrome/chromium")

        Disons, qu'elles sont, maintenant, juste un peu moins crédibles, vu que google y arrive (et ce n'est pas leur coeur de métier) ...

        Ils sont peut être très fort (ça j'en doute pas). Mais vu les tournures que prends tout ça ... je pense sincèrement que "firefox va se faire bouffer grave". Les versions gpl et dégoogelisée de chrome vont prendre l'ascendant haut la main.
        Le produit est bon, voir très bon ... la synchro et les extensions sont là (y développer une extension y est simplissime en comparaison) ... maintenant on va voir très vite arrivé html5, webgl, nacl et cie dans le core ... ils vont leader l'innovation (ils le font déjà dans certain domaine : js) ...

        Moi ça fait 6 mois que je tourne avec les dev builds de chromium ... et je vois bien la vitesse d'avancement : c'est fulgurant ... et à cette vitesse là, comme dit, ils vont tout leader sous peu.
        • [^] # Re: bravo ...

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

          >je pense sincèrement que "firefox va se faire bouffer grave".

          bof

          >Les versions gpl et dégoogelisée de chrome vont prendre l'ascendant haut la main.

          rebof

          > la synchro

          la synchro de quoi ?

          > et les extensions sont là (y développer une extension y est simplissime en comparaison)

          pareil chez Mozilla. cf jetpack.

          >maintenant on va voir très vite arrivé html5, webgl, nacl et cie dans le core

          comme chez Mozilla. qui n'a absolument rien à envier à chrome de ce coté là. Tout ce qui est implémenté dans chrome/webkit l'est déjà dans Mozilla ou en passe de l'être, et vice versa.

          > ls vont leader l'innovation (ils le font déjà dans certain domaine : js)

          js ? tracemonkey est aussi rapide voir plus rapide que V8. En tout cas, c'est kiff kiff. donc bon, pas la peine de se branler la nouille là dessus.
          • [^] # Re: bravo ...

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

            >> la synchro

            > la synchro de quoi ?

            Des données, sur XMPP, que Mozilla réinvente avec Weave.
          • [^] # Re: bravo ...

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

            La synchro ne concerne que les bookmarks pour l'instant ... mais ils l'ont fait, et très rapidement (et très bien, ça marche du tonnerre). S'ils avaient fait plus (mdp, history, certs ...), plein de gens auraient crié au loup ...
            Je ne doute pas un seul instant, qu'ils n'aient pas les moyens de synchroniser tout ça. La base est là, et xmpp est dans la place. C'est uniquement politique !

            Laurent, (on a déjà eu de grav'discut dans le passée ;-) ...
            jetpack ou pas jetpack ... firefox est "lent" sous notre plateforme. On n'est pas à la sur-enchère de technos ... On a beau être des geeks ... on n'en est pas moins des utilisateurs d'internet ...
            que mon navigateur fasse du webgl, du nacl ou du html5 : comme tu dis, on s'en b....
            On veut juste pouvoir naviguer dans des conditions correctes, en utilisant les technos utiles/utilisées sur les sites qu'on visite.
            il vaut être pragmatique !

            "kif-kif" pour les moteurs js ?!?... l'émulateur NES en JS (et je sais bien que ce n'est pas non plus un benchmark) tourne infiniment (100x) plus rapidement sous chrome que sous ffox.
            Je suis pragmatique, et bien conscient qu'il en est de même sur les sites abusant de js : gwave et cie ...
            Ce n'est peut être qu'une sensation alors ?! mais elle est là !

            Ce que je dis, c'est que chrome est une excellente base pour le futur ... pour un 1er navigateur (certes v4, mais ça veut rien dire niveau version): c'est déjà bluffant.
            En gros, ils ont les hanches pour faire monter en puissance leur truc ... Ce que je ne peux pas dire de ffox (aka problème de base : certainement lié aux technos xbl/xul/xpcom).

            Ils sont arrivés "au niveau" de firefox en un an ... ils vont pouvoir maintenant innover (et leader l'innovation)...
            et mon petit doigt me dit, qu'ils seront, ET DE LOIN, les premiers à couvrir html5 (entre autres, pour remplacer gears, qui est une brique importante de l' "os chrome" pour l'offline) ...
            Ils en ont la capacité, ils en ont la volonté ... et avec l'os chrome dans 6 mois : ils vont mettre les bouchées doubles.

            C'est triste qqpart pour mozilla... mais pour l'utilisateur, c'est bien. Ils ont aussi, à mon sens, un truc que mozilla n'a pas : faire plaisir à l'utilisateur final (et ça ne passe pas forcément par l'innovation (et la sur-enchère de technos))
            • [^] # Re: bravo ...

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

              >que mon navigateur fasse du webgl, du nacl ou du html5 : comme tu dis, on s'en b....

              ouai enfin non, on s'en fout pas, enfin moi non. Parce que je veux que n'importe quel site puisse fonctionner correctement, surtout si il n'utilise que des standards (ou futur standards). Pour un utilisateur, surtout si il n'y connait que pouik en techno, un site qui ne fonctionne pas, c'est un site sur lequel il ne reviendra pas. Et si il tombe sur trop de site qui ne fonctionnent pas, il passe à un autre navigateur (si c'est un utilisateur un peu avancé).

              >il vaut être pragmatique !

              je pense que Mozilla est très pragmatique. Tiens, une preuve : acid3. ils sont pas à 100% parce qu'ils estiment qu'il y a des choses qui méritent plus d'attention, que le support des fontes SVG (les derniers points à gagner sur acid3 concernent ce support principalement). Et ils ont préférés par ex travailler sur le nouveau format WOFF (http://hacks.mozilla.org/2009/10/woff/ ), qui est un meilleur compromis entre les développeurs et les fondeurs.

              >l'émulateur NES en JS (et je sais bien que ce n'est pas non plus un benchmark) tourne infiniment (100x) plus rapidement sous chrome que sous ffox.

              La majorité des bottlenecks, que ce soit pour cet émulateur ou les gros sites avec plein de DHTML de partout, ce n'est pas la faute au moteur JS, tracemonkey, mais la faute à notre couche de communication DOM <-> JS.

              Dans l'exécution d'une page web, il y a pleins de trucs qui entre en action, comme c'est expliqué sur http://blogs.msdn.com/ie/archive/2009/11/18/an-early-look-at(...) , faut donc pas mettre toutes les fautes sur le moteur JS.

              >Ils sont arrivés "au niveau" de firefox en un an

              ils n'ont, et n'auront jamais une extensibilité aussi forte que ce que permet Firefox. Ils sont au niveau en terme de navigation et visite des pages. Maintenant Chrome est loin d'être une plateforme de dev comme l'est Firefox. Faut bien voir ça. Firefox n'est pas qu'un moteur de rendu de page web. Chrome si (avec quelques boutons autour). Peut être que tu t'en fiches, que tu veux qu'un simple browser, mais Firefox n'en serait pas là où il est si il n'avait pas cette formidable extensibilité. Il (ou plutôt XulRunner, sur lequel est bati Firefox) a servi de base à plein d'appli.

              >qu'ils seront, ET DE LOIN, les premiers à couvrir html5 (entre autres, pour remplacer gears, qui est une brique importante de l' "os chrome" pour l'offline) ...

              euh, tout ce que fait gear, Firefox le fait depuis des lustres il me semble. Faut arreter un peu. En matière de support HTML5, chrome n'est pas si en avance, et Firefox ne prend en rien du retard. Et puis il n'y a pas que HTML5, mais aussi XBL2, et d'autres technos sur lesquels Chrome a encore du retard (à quand une implem XForms par ex, ou MathML).

              >Ils ont aussi, à mon sens, un truc que mozilla n'a pas : faire plaisir à l'utilisateur final

              ça c'est ton avis propre. Ce n'est pas l'avis des 330 millions d'utilisateurs de Firefox. Et aux dernières nouvelles, la progression de Chrome n'est pas si fantastique que ça, en terme de part de marché (surtout que Firefox continue à bien progresser aussi sur ce sujet). Il va falloir beaucoup de temps, à mon avis, avant que Chrome ne parviennent à rattraper Firefox.

              Enfin bon, on verra...
              • [^] # Re: bravo ...

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

                > ils n'ont, et n'auront jamais une extensibilité aussi forte que
                > ce que permet Firefox. Ils sont au niveau en terme de
                > navigation et visite des pages. Maintenant Chrome est loin
                > d'être une plateforme de dev comme l'est Firefox. Faut bien
                > voir ça. Firefox n'est pas qu'un moteur de rendu de page web.

                Je ne dis pas le contraire, je sais très bien les différences entre les 2 plateformes ...
                J'étais un early adopter des technos mozilla, et utilisateur(et evangeliste) de phoenix/firebird/firefox ...
                Les technos derrière ffox : xbl/xpcom/xul sont très biens ...

                Mais madame michu, ou même moi, s'en fiche du côté "plateforme de dev", ou extensibilité extrème du navigateur...
                (cependant, pour la grosse majorité des extensions utiles/efficaces de ffox : je ne vois pas ce qui ne pourrait pas être fait dans chrome/chromium ... pour parler "extensibilité")
                Donc, pour l'utilisateur final : kif kif.

                Ce que je dis, c'est que c'est quand même incroyable le niveau de maturité qu'à atteint leur navigateur en 1an. (tout en restant très véloce).
                Et qu'ils ont ainsi une (très) bonne base pour innover (maintenant que le plus gros est derrière).

                > euh, tout ce que fait gear, Firefox le fait depuis des lustres
                > il me semble

                oui, et pour cause : c'est eux qui l'ont fait ... ils n'avaient pas encore de navigateur ;-)

                Je ne sais pas si tu as testé "chrome os", mais il manque toute la brique offline, pour que le concept puisse prendre (et je n'ai aucun doute).
                Et c'est pour ça, à mon sens, qu'ils vont se dépêcher d'implémenter les morceaux html5 nécessaire pour l'offline. (vu que gear est officiellement abandonné now) ...

                quant à la progression de chrome ... l'os chrome sur netbook risque quand même de prendre ;-) ...
                j'ai installé "os chrome" sur mes eee pc ... c'est clairement le temps minimum entre l'allumage de la machine et la présence web ... avec le plaisir de partager ses bookmarks entre les eeepc ... mon chromium/desktop et mon chromium@boulot ...
                (pour l'anecdote, le lancement de firefox dans un jolicloud sur un eee 701 4g, prends autant de temps que le boot du 701 pour se retrouver sous chrome online... ça laisse rêveur)

                Ce que je veux juste dire, c'est qu'ils ont un truc rapide/efficace et déjà pas mal ... maintenant, ils ont la liberté de pouvoir innover, et ils vont le faire très rapidement à mon avis.

                Pour ne pas renier totalement mes anciens amours, j'utilise encore firefox, uniquement pour firebug, et les devs webs (quand je suis sous windows, car sous linux : c'est inutilisable sur ma machine) ...
          • [^] # Re: bravo ...

            Posté par . Évalué à 1.

            >Les versions gpl et dégoogelisée de chrome vont prendre l'ascendant haut la main.

            rebof


            Ah non, ils risquent en effet de leader l'innovation sur le market linux, soit almost 1% du market web total! C'est clair que vous avez tout a craindre la dessus.
            • [^] # Re: bravo ...

              Posté par . Évalué à 2.

              Je m'insurge!!!
              T'oublies tout ceux qui changent leur user agent et ceux qui bloquent xiti.
              C'est donc 1.02% du parc mondial.
        • [^] # Re: bravo ...

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

          Il ne faudrait tout de même pas oublier Microsoft dans cette histoire...

          Car, IE9 possède un nouveau moteur Js qui met une branler à Google Chrome et Firefox sur le test sunspider...

          Certe, d'ici la sortie de IE9, ca laisse du temps aux devs de firefox de rattraper leur retard... et à ceux de Google de reprendre la première place.
          • [^] # Re: bravo ...

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

            Car, IE9 possède un nouveau moteur Js qui met une branler à Google Chrome et Firefox sur le test sunspider...

            Et un parseur XML (un vrai, je veux dire) ? Il serait temps…
          • [^] # Re: bravo ...

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

            pardonne moi de mon ignorance, peut etre que j'ai raté un épisode, mais ce que je vois ici, http://blogs.msdn.com/ie/archive/2009/11/18/an-early-look-at(...) donc d'après des chiffres "officiels", le moteur js de IE9 est loin de mettre une branler à ces concurrences. Il rattrape juste son énorme retard, et reste encore un peu derrière ses concurrents... m'enfin on commence quand même à arriver aux limites, et je ne pense pas qu'on n'arrivera pas à grignoter plus de 20-30% sur les perfs actuels. on ne peut pas aller plus vite que ce que peuvent permettre les instructions processeurs (vu que pour arriver aux perfs actuels, le code js est transformé en instructions machines avant son execution, que ce soit dans V8 ou dans TraceMonkey, même si la manière de le faire est totalement différente).
          • [^] # Re: bravo ...

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

            > Il ne faudrait tout de même pas oublier Microsoft dans cette histoire...

            Non, mais sérieux, arrêter pendant 5 ans le développement d'un bout de soft aussi important, ils vont mettre du temps à faire leur rééducation...

            Sans compter qu'ils ont un énorme boulet que les autres n'ont pas : la compatibilité ascendante.

            En attendant quelques années de plus, IE ne peut que faire rire... ou pleurer...
      • [^] # Re: bravo ...

        Posté par . Évalué à 5.

        En fait, c'est un problème de build. La monnaie d'échange dans le monde de l'open source, c'est le source, pas le binaire. Je prends pour exemple Fedora et Mandriva qui activent la gestion des exceptions pour le C et le C++ ... Alors que ni KDE, ni Qt, ni Firefox n'utilisent les exceptions ou le RTTI du C++.

        Les distributions préfèrent avoir des binaires facilement debugable qu'optimisées. Elles optimisent plein de trucs, mais apparemment pas le build.

        La version Windows est simplement beaucoup plus optimisée, lors de la compilation. Ce n'est pas un problème de code ou de volonté des développeurs (selon moi). Pour faire du développement Drupal, Firefox Linux (Ubuntu, Fedora, Mandriva) se prend une méchante raclée par rapport à la version Windows.

        On peut obtenir des gains intéressants en recompilant Firefox avec les dernières optimisations de gcc. J'ai recompilé ma propre version en faisant du profile feedback il y a quelque temps, et ça marche pas mal (j'ai tout effacé, et j'ai pas fait ça de la bonne manière).

        Peut-être qu'il faudrait revoir les options de build de Firefox ou des distributions.
        • [^] # Re: bravo ...

          Posté par . Évalué à 2.

          Ouaip, visiblement, un firefox optimisé (en l'occurence swiftfox) semble se débrouiller bien mieux, en tout cas sur le test sunspider:

          http://www2.webkit.org/perf/sunspider-0.9/sunspider-driver.h(...)

          Chromium 4.0.269.0 : 476 ms +/- 5.5%
          Firefox 3.5.5 : 2549 ms +/- 3.3% 5.35x slower
          Swiftfox 3.5.3 : 1062 ms +/- 0.7% 2.23x slower

          (le tout testé sur une Kubuntu 9.10 AMD64 à jour ce matin)
          • [^] # Re: bravo ...

            Posté par . Évalué à 2.

            Et flute, je n'avais pas réactivé mon repository for Swiftfox, d'où le fait que j'ai testé la 3.5.3. On peut donc rajouter:

            Swiftfox 3.5.5 : 1141.ms +/- 1.7% 2.39x slower

            Ainsi, en bonus, qu'un test de safari sur un macbook pro (moins rapide que ma machine principal)

            Safari 4.0.4 : 423 ms +/- 0.9% (on a slower machine)

            Safari, ca poutre.
            • [^] # Re: bravo ...

              Posté par . Évalué à 2.

              Bon, malheureusement les plugins que j'ai testé (flash et java) ne marchent pas avec swiftfox. Pas de bol. À noter que j'ai également testé SwiftWeasel dont le super logo ne cache pas qu'il n'est que marginalement plus rapide que firefox (2100ms, de mémoire).
    • [^] # Re: bravo ...

      Posté par . Évalué à 6.

      Je ne vois pas où est le drame, si Firefox est moins utilisé sous GNU/Linux.
      Firefox est un peu le Ubuntu des navigateurs (et ce n'est pas un reproche): il est destiné à apporter les premiers secours et la cure de désintoxication aux windowsiens totalement formatés par Microsoft. À bouffer IE, exactement comme Ubuntu veut bouffer Windows.

      Mais je ne vois pas où est le problème si les utilisateurs d'OS libres ont des navigateurs plus performants que Firefox et tout aussi libres.. Après tout, si l'ensemble des gnulinuxiens passe à Epiphany/Konqueror/what else, ça changera quoi?
      Firefox y perdrait très peu de parts de marché, et ce serait en faveur d'autres logiciels libres. Le marché se diversifierait au-delà de l'éternel duel IE/FX, ce qui ne pourrait que pousser les webmasters à produire du code "conforme aux standards" et pas "testé sur FX/IE", comme c'est encore trop souvent le cas.

      Je préfère voir 10% d'IE, 80% de Firefox et 10% d'autres navigateurs, que 30% d'IE, 69% de Firefox et 1% d'autres navigateurs :)

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

    • [^] # Re: bravo ...

      Posté par . Évalué à 3.

      Bizarre, j'utilise Firefox au boulot (Windows) et à la maison (Linux) et je ne vois pas franchement la différence.
      • [^] # Re: bravo ...

        Posté par . Évalué à 3.

        Peut-être parce qu'au boulot, tu as un vieux PC moisi, avec un antivirus bien lourd, un parefeu bien présent, trois tonnes de scripts destinés à t'empêcher de faire des bêtises, Outlook+Excel+tout un tas de trucs, et qu'à la maison tu as une bécane qui tourne bien et n'exécute que du code strictement nécessaire?

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: bravo ...

          Posté par . Évalué à 2.

          Pourquoi tu supposes que c'est lent?

          Moi je le trouve assez rapide mon Firefox. Pas pour les jeux 4D en javascript, mais pour les sites normaux, ça va.
  • # Questions...

    Posté par . Évalué à 2.

    * Electrolysis (multi-process, aujourd'hui ça fonctionne bien pour les plugins. Bientôt, plus de crashs à cause de Flash)
    ...
    * des trucs spécifiques à Windows (Direct 2D rendering)


    Concernant Electrolysis, les plugins seront dans des process séparés et c'est une excellente chose (tout le monde pense à ses déboires avec Flash effectivement...). Cependant, verra-t-on à terme un process par onglet, comme dans Chrome ?
    J'ai tendance à penser que c'est limite crade : surconsommation mémoire (Ff n' pas besoin de ça...) et bonjour la pollution du gestionnaire des tâches quand on ouvre une trentaine d'onglets...
    Utiliser un thread par onglet me paraît plus pertinent, non ?

    Ensuite, sur le rendu Direct 2D, vous travaillez upstream avec les devs de cairo sur un backend ?
    • [^] # Re: Questions...

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

      >Cependant, verra-t-on à terme un process par onglet, comme dans Chrome ?

      oui.

      La version 3.7 apportera la séparation des processus pour les plugins, et la 4.0, la séparation des processus dans les onglets.

      >Utiliser un thread par onglet me paraît plus pertinent, non ?

      bah non. parce que tu n'a pas une séparation complète. Si il y a un crash dans un thread, c'est tout le processus qui crash (la preuve avec les crash de Firefox, qui utilisent pourtant de threads un peu partout). Mais un crash dans un processus ne fait pas crasher les autres processus (en theorie, sauf si ce crash provoque un kernel panic :-)).

      Après, au niveau consommation mémoire, faut voir comment cela va être géré.

      >bonjour la pollution du gestionnaire des tâches quand on ouvre une trentaine d'onglets...

      personnellement, je n'ouvre le gestionnaire de taches que lorsqu'il faut que je tue un processus, c'est à dire rarement....
      • [^] # Re: Questions...

        Posté par . Évalué à 2.

        Je ne saisis pas bien où est le problème de ne pas avoir une séparation complète... J'observe de manière très anecdotique des plantages de Ff - Flash mis de côté - alors qu'il m'arrive plus souvent de voir des freeze de quelques secondes lorsqu'une page un peu lourde se charge dans un onglet (mais je ne peux pas affirmer que cela vienne de là).
        Cela dit, je ne sais pas comment Ff est architecturé au niveau des threads...
        Par contre, côté performances, j'imagine qu'autant de processus séparés, cela doit être également couteux au niveau des IPC, non ?
        • [^] # Re: Questions...

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

          le freeze, c'est dû au fait que toutes les pages web et l'interface (qui est en xul+js), s'exécutent dans le même thread (pour des raisons historiques et techniques, notamment vis à vis des extensions, mais avec le projet electrolysis, ils sont en train de changer ça). Mais ça n'empêche pas Firefox d'utiliser les threads pour tout ce qui est réseau et certains traitements en taches de fond qui ne touchent pas directement l'interface ou une page web (dans la 3.6 par ex, la recherche qui s'effectuent lorsqu'on tape dans la barre d'url se fait maintenant dans un thread).

          Notons aussi que grâce aux webworkers (ff3.5), les pages web ont la possibilité de réaliser en javascript des trucs dans un thread séparé, ce qui évite les temps de "chargements" trop long.

          Sinon, au niveau IPC, je ne suis pas assez calé là dedans pour t'affirmer quoi que ce soit. Je sais juste que chez Mozilla, ils ont repris la lib IPC de chromium, avec une petite API par dessus pour que ce soit simple de communiquer entre processus via javascript.
          • [^] # Re: Questions...

            Posté par . Évalué à 2.

            dans la 3.6 par ex, la recherche qui s'effectuent lorsqu'on tape dans la barre d'url se fait maintenant dans un thread
            Ça c'est une bonne nouvelle!

            Parce que jusqu'ici, cette fonction de recherche remplaçait avantageusement Flash pour la fonctionnalité "monopoliser le CPU".

            C'est très sensible sur une petite machine:
            - Firefox avec une page, tout va bien.
            - Firefox avec 10 onglets, tout va bien.
            - Firefox sur une page plein de javascript, tout va bien.
            - Saisie d'une suite de caractères dans la barre d'URL, qui déclenche la recherche de cette séquence de caractères dans plusieurs dizaines de ko d'historique et de cache: rien ne va plus.

            THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

  • # en effet

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

    En effet, y'a un truc entre les distributions, et autre.

    J'ai vu sur debian des lenteurs indescriptible de Iceweasel, mais également avec un firefox 3.5 provenant du site Mozilla. Fuite mémoire à gogo, le processus prenait 1.5Go au bout de 2 jours. Et ça raaaaaame. Sur opensuse, avec la meme utilisation, meme extensions, meme sites, c'est bien + rapide, et je reste dans les 300 - 400Mo. Va comprendre.

    Ensuite, faut savoir que Firefox utilise des accelerations XRender (ça c'est bien), notemment sur le scroll, mais du coup le resultat est inégal en fonction de la qualité des drivers video. Pareil que KDE4 donc.
  • # Travailler plus, pour plus de lapsus.

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

    * Weave, qui va permetre de tout synchroniser (Fennec, Firefox au bureau, Firefox au travail)

    Tu travailles vraiment trop /o\
  • # Thunderbird et Firefox dans une seule fenêtre

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

    De voir des onglets arriver dans mon thunderbird, ça m'a donné envie de mettre ces onglets directement dans la fenêtre Firefox :D

    Est-ce que ça ressemble à ça le navigateur mozilla tout-en-un nomé seamonkey? Est-ce qu'il est compatible avec les add-ons Firefox et tout ça?

Suivre le flux des commentaires

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