Ça bouge dans les navigateurs web

Posté par  (site web personnel) . Modéré par patrick_g.
Étiquettes :
23
11
avr.
2010
Internet
La compétition entre les principaux navigateurs web encourage leurs équipes à toujours plus d'innovation. Cette dépêche ne va effleurer que quelques unes des avancées des navigateurs, mais pas des moindres :
Je vous invite à lire la seconde partie de la dépêche pour avoir plus de détails. Google soutient Theora sur les mobiles

Sur le blog Google open source a été publié hier un article parlant de la vidéo sur internet. Après un bref rappel de la situation actuelle et une introduction à la balise de HTML5, un paragraphe explique pourquoi le codec Theora est le meilleur pour le web : non seulement il a des performances comparables à celles de ses concurrents, mais surtout il est 100% libre. Je ne résiste pas au plaisir de tirer une citation de ce billet à propos de Theora :

Really free. Not just "free to use in decoders," or "free to use if you agree to this complicated license agreement," but really, honestly, genuinely, 100% free. The specification for the stream and encoder/decoder source is available for public download and can be freely used/modified by anyone. Theora was designed and is maintained with the overriding goal of avoiding patents. No other codec can come even close to claiming to be as patent or royalty free as Theora can, whilst still holding a candle to the alternatives.

Du coup, ils parlent de Cortado pour les navigateurs qui n'ont pas de support pour la balise , et ils vont aider financièrement le projet TheorARM, Theora pour processeurs ARM.

NdM: merci à zorzorg2 pour son journal sur le sujet.

Opera voudrait distribuer Opera Mini sur l'iphone

Opera semble décider à distribuer Opera Mini sur l'iphone et à faire jouer la pression médiatique pour convaincre Apple de l'accepter sur l'App Store. Le communiqué de presse d'Opera a été accompagné d'un compteur indiquant depuis combien de temps Opera Mini est en attente de modération sur l'App Store. Ce compteur est clairement destiné à faire du buzz, probablement dans l'espoir de convaincre Apple, mais après 18 jours passés, cette tactique n'a toujours pas donné ces fruits.

Microsoft veut rattraper son retard sur les standards

Microsoft a annoncé à sa conférence Mix la sortie de Internet Explorer 9 Platform Preview. Comme son nom l'indique, ce n'est qu'une préversion et il reste encore beaucoup de travail à Microsoft avant d'en faire un navigateur digne de ce nom.

Microsoft a donc annoncé que IE9 supporterait SVG (enfin !), CSS3 (et notamment border-radius ), HTML5 et la désormais célèbre balise video. Cette version verra également l'arrivée d'un nouveau moteur javascript, dont les performances devraient être nettement meilleures. Enfin, Microsoft met en avant l'accélération matérielle du GPU, ce qui devrait permettre d'affiche bien plus rapidement les pages complexes (je vous rassure, les autres navigateurs travaillent aussi sur l'accélération matérielle).

Webkit2

Webkit2 est une évolution majeure de webkit dont le développement a commencé chez Apple. Il a 2 grands objectifs : séparer les processus et introduire des API asynchrones. La séparation des processus devrait être très similaire à ce que propose Google dans Chrome (ou mozilla, mais j'en dirais plus un peu plus tard), à la différence près qu'Apple souhaite le proposer directement dans le framework, permettant ainsi aux autres navigateurs web utilisant webkit d'en profiter. Le second point, les API asynchrones, vise quant à lui à fournir de meilleures performances.

Seul regret, webkit2 n'est, pour le moment, disponible que pour Windows et OS X (les plateformes supportées par Apple pour Safari). Espérons que d'autres ports verront bientôt le jour.

Stabilité améliorée sous Mozilla

Mozilla travaille également à séparer les processus afin d'améliorer la stabilité. Cela permet d'éviter que Firefox ne plante quand Flash, Quicktime ou Silverlight deviennent instables. Cette amélioration, nom de code Electolysis, arrivera dans la prochaine version majeure de Firefox.

En attendant, il est déjà possible d'en profiter avec Firefox 3.6 en installant Firefox Lorentz.

Protection contre la fuite d'informations sur votre historique

La propriété CSS :visited permet d'appliquer un style particulier pour des liens déjà visités. Il était possible pour un site malveillant de s'en servir pour savoir si vous aviez visité un site particulier. David Baron, de Mozilla, explique cette attaque et a proposé une solution pour s'en protéger. Mozilla a implémenté cette solution, suivi peu de temps après par Apple dans webkit.

Aller plus loin

  • # Apple et App Store

    Posté par  (site web personnel, Mastodon) . Évalué à 10.

    J'adore le matériel Apple pour sa qualité, sa finition. Je déteste Apple pour sa politique de fermeture ; le cas de Opera est symptomatique de ce problème, ce qui fait que je n'achèterai jamais leur matériel.

    Je ne suis pas super au fait de l'actualité Apple, mais il me semblait qu'il existait des "app store" alternatifs. Quelqu'un confirmerait ?
    • [^] # Re: Apple et App Store

      Posté par  . Évalué à -8.

      Parce qu'Opera c'est ouvert, peut-être ? Où sont les sources ?

      Ah pas de source. Où puis-je trouver une version OpenBSD et une version DragonflyBSD d'Opera ?

      Ah, nulle part. Pas possible. Closed-source, propriétaire. Contrairement à Webkit.
      • [^] # Re: Apple et App Store

        Posté par  . Évalué à 9.

        Je ne vois pas vraiment le rapport avec l'ouverture d'Opéra.

        Opéra, l'entreprise, a proposé son navigateur comme application pour l'AppStore. Après 18jours elle n'a pas encore été accepté et ne le sera sans doute pas.

        Tu te trompes de combat. Certes Opéra n'est pas Open Source, mais le problème qui occupe l'auteur du premier commentaire ce n'est pas celui là.
      • [^] # Re: Apple et App Store

        Posté par  . Évalué à 5.

        Pas besoin d'un code source libre pour avoir une politique ouverte.

        Opera est l'un des navigateurs les plus multiplateformes, et l'un des plus respectueux des standards. Pour ne rien gâcher, il était encore parmi les plus rapides il y a quelques temps (il y a eu tant de boulersement que je ne sais pas si c'est toujours le cas).

        De plus, ils ont fini par abandonner leur modèle basé sur la publicité pour passer au tout gratuit, tout au moins sur le poste de travail.

        Opera reste un modèle de respect pour les utilisateurs, et ça saute encore plus aux yeux quand on voit Apple.

        Y'a peut-être pas de version OpenBSD, mais il y a au moins FreeBSD, en 32 et 64bits. Et ça, tous les navigateurs ne le font pas.

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

    • [^] # Re: Apple et App Store

      Posté par  . Évalué à 5.

      Il y a bien un appstore alternatif : Cydia (en gros un dépot APT).

      Le problème est qu'Apple impose son AppStore comme l'unique boutique d'applications pour iPhone : utiliser Cydia nécessite de "jailbreaker" son iPhone.

      Sans cette pratique stalinienne, personne n'aurait à redire à la politique commerciale d'Apple (chacun vend ce qu'il veut dans son magasin) puisque les mécontents pourraient aller voir ailleurs.

      BeOS le faisait il y a 20 ans !

  • # processus séparés

    Posté par  . Évalué à 1.

    je suis septique sur les avantages de cette solution.
    je suis utilisateur de FireFox.
    j'ai facilement, en usage courant, une 10aine de fenêtres, une per thème de navigation, et une 50aine d'onglets d'ouverts.
    soit un FF occupant souvent 500MB de RAM, peu importe.
    et il est très rare que je doive killer le processus FF pour raison de blocage, je ne me rappelle pas l'avoir fait cette année.
    peut être aussi parce que je n'active le JS qu'au cas par cas - merci noscript.
    je ne vois pas comment une séparation des onglets en processus va m'aider en quoi que ce soit. si je fais un calcul un peu naïf, un FF avec un seul onglet prenant environ 50MB, j'arriverai à 2500MB dans mon utilisation et je n'ose prédire le comportement du système tentant d'ordonnancer 50 processus FF.

    bref, au delà de ce verbiage sur ma life, je me demande si mon usage est répandu parmi les utilisateurs et si il sera compatible avec ce que semblent vouloir nous proposer les éditeurs de navigateurs.

    quel est votre avis ?
    • [^] # Re: processus séparés

      Posté par  . Évalué à 6.

      quel est votre avis ? Si le truc est bien foutu la conso RAM ne devrait pas beaucoup augmenter :
      - les données statiques (code) entre processus devrait être partagée
      - les données dynamique (image, contexte html, ...) sont déjà dupliqué par onglet.
      - le coeur du navigateur (affichage, HIM, ...) devrait resté dans un processus.

      Par contre au niveau cpu, ca devrait être un peu moins bon, quoi que...
    • [^] # Re: processus séparés

      Posté par  . Évalué à 5.

      Le calcul est mauvais. Je ne puis répondre pour Windows mais en tout cas pour Linux et très probablement tous les BSD la mémoire n'augmente pas à la création d'un processus (fork). En effet, le processus fils partage tout le code et les données du processus père. Seulement lorsqu'il essaie de modifier une donnée, la donnée est dupliquer. Au final, la mémoire qu'occupera un processus correspond à ce qu'il apporte par rapport au processus père.

      En l'occurence, les plugins occuperont une place assez petite car leur code et la mémoire dont ils ont besoin est petite. Au lieu d'avoir un firefox à 250 Mio tu auras peut-être un firefox à 100 Mio et le reste divisé en plusieurs plugins et onglets.
    • [^] # Commentaire supprimé

      Posté par  . Évalué à 5.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: processus séparés

        Posté par  . Évalué à 2.

        en fait noscript désactive aussi le contenu impliquant les plugin. en gros il ne reste que le html+css.
        d'autre part, le contenu dynamique peut être réactivé hôte par hôte.
        je pense que cela contribue beaucoup à la stabilité de ma config.
    • [^] # Re: processus séparés

      Posté par  (site web personnel) . Évalué à 3.

      Mon avis est que TabGroup Manager me permet de réunir des onglets dans d'autres, des fois qu'on a 42 onglets dont 5 d'utiles à la fois et que ça en devient illisible. Avantage : on peut faire hiberner des groupes d'onglets, ne prenant ainsi quasiment aucune place en mémoire, même au démarrage de Firefox puisqu'ils ne sont dès lors pas chargés.

      Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

      • [^] # Re: processus séparés

        Posté par  . Évalué à 2.

        Merci de m'avoir fait découvrir cette superbe extension :)

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: processus séparés

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      Je pense que ça ne peut pas faire de mal, de mon côté. Firefox qui est complètement bloqué quand un onglet charge du flash ou une applet java, Firefox qui plante régulièrement sur des pages chargées en JS... bref, je trouve de plus en plus que les alternatives propriétaire (Chrome, Opera) ont un avenir certain.

      A moins que la stabilité du produit s'améliore...
      • [^] # Re: processus séparés

        Posté par  . Évalué à 0.

        Chrome n'est pas propriétaire. Enfin… Chromium c’est 99% Chrome et c’est libre.

        DLFP >> PCInpact > Numerama >> LinuxFr.org

        • [^] # Re: processus séparés

          Posté par  (site web personnel) . Évalué à 7.

          > Chrome n'est pas propriétaire. Enfin… Chromium c’est 99% Chrome et c’est libre.

          Donc ce n'est pas libre.
          • [^] # Re: processus séparés

            Posté par  (site web personnel) . Évalué à 0.

            Correction, Chrome est libre sauf ses binaires précompilés.

            Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

            • [^] # Re: processus séparés

              Posté par  . Évalué à 4.

              Que dit la licence d'utilisation de Chrome ?

              http://www.google.com/chrome/eula.html?hl=fr
              "9.2 Sous réserve des conditions énoncées à l'article 1.2, vous n'êtes pas autorisé (et ne pouvez pas autoriser un tiers) à copier, modifier, créer des travaux dérivés, faire de l'ingénierie inverse, décompiler ou tenter d'extraire de quelque manière que ce soit le code source du Logiciel ou d'une partie de celui-ci, à moins qu'une telle activité ne soit requise ou autorisée expressément par la loi ou qu'elle ne fasse l'objet d'une autorisation écrite expresse de Google."

              Ce n'est qu'un extrait (les autres paragraphes du chapitre 9 apportent d'autres restrictions) mais ça me parait déjà mal barré pour la garantie des 4 libertés du logiciel ...

              BeOS le faisait il y a 20 ans !

          • [^] # Re: processus séparés

            Posté par  . Évalué à 2.

            T'as rien compris.
            Chromium est libre.
            Chromium c’est Chrome, à 99%.
            Chrome c'est pas libre mais on s'en branle parce qu'on utilise Chromium et pas Chrome, sans perdre de fonctionnalités.

            DLFP >> PCInpact > Numerama >> LinuxFr.org

    • [^] # Re: processus séparés

      Posté par  (site web personnel) . Évalué à 2.

      En pratique, j'aurais bien aimé avoir des processus séparés il y a quelques jours.

      En développant une page web, j'étais arrivée à créer une boucle infinie avec à l'intérieur des appels à alert() pour le debug. Donc, la page m'affichait en boucle une popup.

      Bien sûr, lorsque la popup est affichée, les contrôles de la fenêtre du navigateur sont bloquée (il faut valider la popup). Mais si je ferme la popup, elle se réaffiche juste après (boucle infinie).

      Je pouvais toujours utiliser d'autres fenêtres de Firefox en attendant, mais tous les onglets de cette fenêtre étaient bloqués. La seule solution pour fermer cet onglet gênant a été de quitter Firefox complètement (et je n'aime pas trop ça).


      Après, on peut imaginer des choses similaires sur des sites web, pas juste en développement.
      • [^] # Re: processus séparés

        Posté par  (site web personnel) . Évalué à 4.

        chrome règle ce problème de manière élégante et cela n'a rien à voir avec les processus séparés.

        Lorsqu'il s'aperçoit qu'une popup s'affiche souvent (dès la 2e apparition c'est le cas) il propose par une case à cocher dans le popup de ne plus autoriser le script à afficher de nouveaux popups.
        C'est très pratique, surtout dans des cas comme le tiens !
        • [^] # Re: processus séparés

          Posté par  (site web personnel) . Évalué à 1.

          Opera a aussi la case à cocher 'Arrêter les scripts sur cette page'. En outre, depuis les dernières versions, les boites javascript ne sont plus modales, et c'est plutôt une bonne idée.

          Sinon, l'idée de faire plusieurs processus n'est pas mauvaise en soi. Mais on n'est pas forcément obligé de faire un onglet par processus... Sous Linux, Opera isole l'exécution des plugins dans des processus operapluginwrapper, mais tout le reste du contenu des onglets ne bouge pas du processus père. Comme ça, quand Flash se vautre (courant avec Opera sous Linux vu qu'Adobe en a RAF d'Opera, de Linux et donc davantage des deux en même temps), on évite que le navire coule avec le plugin.

          De toutes façons, à titre personnel je réduis au minimum l'utilisation des plugins et je patiente jusqu'à ce que HTML 5 s'impose, si possible avec Ogg Theora.
        • [^] # Re: processus séparés

          Posté par  . Évalué à 2.

          pour ma part j'utilise des profiles différents pour mon activité de browsing et mes activités de développement.
    • [^] # Re: processus séparés

      Posté par  . Évalué à 2.

      Tu as bien de la chance. Moi j'ai quasiment une fois tout les 2-3 jours besoin de le killer.
      Et un redémarrage me prend 15 ans pour se terminé car comme je suis derrière un proxy avec authentification, il m'ouvre une bonne vingtaines de boite de dialogue de connexion. Bon ok, les login/mdp sont pré-rempli mais ça prend 15 ans quand meme pour les valider...

      Oui j'aime Firefox mais il y a des fois j'ai bien envie de le balancer...
      • [^] # Re: processus séparés

        Posté par  . Évalué à 1.

        Et un redémarrage me prend 15 ans pour se terminé car comme je suis derrière un proxy avec authentification, il m'ouvre une bonne vingtaines de boite de dialogue de connexion. Bon ok, les login/mdp sont pré-rempli mais ça prend 15 ans quand meme pour les valider...

        J'avais le même problème, mais depuis Firefox 3.6 il ne le demande plus qu'une seule fois.


        Étienne
      • [^] # Re: processus séparés

        Posté par  (site web personnel) . Évalué à -2.

        tu devrais installer AutoAuth :
        https://addons.mozilla.org/fr/firefox/addon/4949

        Et hop, a pu le problème du tout ;)
      • [^] # Re: processus séparés

        Posté par  . Évalué à 1.

        Astuce à essayer : lancer un autre navigateur (ou un firefox à partir d'un autre utilisateur) pour s'identifier auprès du proxy, et ensuite lancer firefox avec les 36 onglets. Ça marche si le proxy se base sur l'IP pour l'identification, mais pas s'il se base sur un cookie.
    • [^] # Re: processus séparés

      Posté par  . Évalué à 3.

      Qu'a mon avis la séparation par processus est un *gros* avantage!!

      Tu es très prudent dans ton utilisation de JS et du reste pourquoi?
      Parce que l'architecture de FF est une *bouse*!

      J'explique: la plupart du temps, 99% des sites web utilisent des ressources normales mais il y en a un ou deux qui foirent et utilisent tout le CPU et/ou la mémoire: quand tu as autant d'onglets ouvert, comment fais-tu pour savoir lequel fait 'ramer' ton ordinateur?

      Avec Firefox tu pleure ou tu te fais ch.. avec noscript pour éviter autant que possible ce probleme.

      Avec Chrome / avec un navigateur utilisant des processus, tu ouvres le gestionnaire de ressource et ferme le ou les onglets coupables: beaucoup plus simple..


      • [^] # Re: processus séparés

        Posté par  . Évalué à 2.

        > Parce que l'architecture de FF est une *bouse*!

        Non, en fait, c'est en premier lieu pour me prémunir des failles liée à javascript, des publicités en javascript, des lourdeurs inutiles des certains sites.
        NoScript bloque aussi les plugin.
        D'autre par, après une période de réglage, il se fait rapidement oublié: les sites que je visite régulièrement sont paramétrés,
        La stabilité globale est plus un effet collatérale.
        La séparation des processus ne m'empêchera pas de garder noscript ainsi que cookiesafe et abp.

        C'est pour cet lacune que je ne suis pas passé sous chrome ou du moins que mon essai c'est rapidement achevé par un retour sous FF.

        D'ailleurs je pense qu'un site ne devrait pas pouvoir planter un navigateur juste avec html et javascript et que la séparation dans des processus distincts des seuls plugins externes serait selon moi un bon compromis.
        • [^] # Re: processus séparés

          Posté par  . Évalué à 1.

          Si tu relies mon post, je n'ai pas parler de plantage mais de consommation abusive de CPU et/ou de mémoire..
          Et la je pense que html&javascript sont suffisants pour ça, oui.

          Je ne pense pas que mettre dans des processus séparés les plugins suffisent mais on verra bien avec la nouvelle version de FF qui fait cela..
  • # pas un greffon

    Posté par  (site web personnel, Mastodon) . Évalué à 5.

    >il est déjà possible d'en profiter avec Firefox 3.6 en installant le greffon Firefox Lorentz.

    Firefox Lorentz n'est pas un greffon, plugin ou extension. C'est une version *complète* de Firefox 3.6 avec le support des plugins dans des processus séparés.
  • # MS et PNG

    Posté par  . Évalué à 1.

    Je me demande si la transparence du PNG sera prise en compte dans IE9 (sauf erreur, c'est toujours un problème) ...
  • # Theora, Google et YouTube

    Posté par  . Évalué à 2.

    Il est étonnant que le billet sur le blog de Google Open Source ne mentionne même pas YouTube, et son choix du h264. Est-ce que les services concernés se sont concertés, avant d'écrire ce billet, ou pas ?

    LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140

Suivre le flux des commentaires

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