Voilà un « jouet technique » qui ravira les amateurs de JavaScript : l’API BroadcastChannel permettra une communication directe entre onglets, fenêtres ou iframes… sous certaines conditions, bien entendu, afin de préserver la sécurité de la navigation. C’est ce que vient d’annoncer Jason Weathersby, porte-parole technique de Mozilla, sur le blog Mozilla Hacks. C’est un objet d’expérimentation intéressant, par exemple si on imagine de pouvoir uploader (téléverser) une photo dans un onglet et voir cette photo immédiatement mise à jour dans un autre onglet ouvert sur le même site. Cela évitera un aller-retour sur le serveur, via Ajax par exemple. Cela dit, il s’agit pour l’instant d’un sujet purement expérimental puisque cette proposition du WHATWG n’est implémentée que par Firefox. On remarquera quand même que Firefox est leader sur ce terrain d’innovation.
Commentaires fermés sur L’API JavaScript BroadcastChannel arrive dans Firefox 38
Dans un article paru ce jour sur le blog Mozilla Hacks, Florian Scholz parle de la mise à jour de la documentation Mozilla Developer Network au sujet de Canvas2D. L’an passé, Firefox a bien progressé sur le plan de ce standard de dessin, et la documentation avait donc besoin d’être mise à niveau. Par exemple, depuis Firefox 31, les objets Path2D permettent de dessiner des chemins SVG du type var p = new Path2D("M10 10 h 80 v 80 h -80 Z"); Nous vous conseillons donc la lecture de l’article de Florian.
Commentaires fermés sur Grosse mise à jour de MDN à propos de Canvas2D
Petites nouveautés sympas qui arrivent ou sont arrivées récemment dans Firefox :
Hello, une fonction arrivée à stabilité dans Firefox 35, permet de communiquer de navigateur à navigateur sans passer par Skype et autres logiciels centralisateurs. Plus d’infos en français sur cet article du BlogZiNet.
Les animations CSS remplacent petit à petit Flash et JavaScript pour des effets graphiques simples, et c’est un grand soulagement. Mais pour les développeurs, il manquait un outil qui les aide à travailler sur ces animations. Ce manque est bientôt comblé par les outils pour développeurs de Firefox, comme vous pouvez le voir sur ce tweet d’Alex Gibson. Coïncidence, cette fonctionnalité arrive en même temps dans Chrome.
Les développeurs de Firefox travaillent sur la sécurité des plugins avec le projet de les confiner dans un « bac à sable » (sandbox). Ce tweet de @FirefoxNightly donne un lien vers un article de GHacks.net qui précise que cela n’est pas lié au projet e10s dont nous parlions dans notre article précédent.
Commentaires fermés sur En vrac : Hello, de l’animation CSS, il y a du nouveau dans le bac à sable !
E10s sera-t-il dans Firefox 42 ? Notre graphique du nombre de bogues résolus montre que oui. (illustration ci-contre)
Pour rappel, le projet Electrolysis vise à paralléliser le rendu de l’interface et du contenu afin de rendre l’une et l’autre plus fluides. Cette méthode, déjà utilisée par Chrome et IE, profite de la généralisation des processeurs multi-cœurs. Cependant, Mozilla n’entend pas aller jusqu’à créer un processus par onglet comme Chrome, afin de limiter la consommation de mémoire.
Nous nous associons à l’hommage rendu aux victimes de cet attentat contre la liberté d’expression. Qu’on soit d’accord ou pas avec eux, ils ne méritaient évidemment pas ça. Comme dit la citation qu’on attribue à Voltaire : « Je ne suis pas d’accord avec ce que vous dites, mais je me battrai jusqu’à la mort pour que vous ayez le droit de le dire. »
Chris O’Brien a publié sur VentureBeat un article intitulé Why does the world still need the Mozilla Foundation? L’auteur y porte un regard sans indulgence sur les orientations actuelles de Mozilla, ce qui choquera sans doute nombre de fans, mais il semble en même temps attendre beaucoup de la fondation. En d’autres termes : sévère mais juste ? À vous d’en juger. Nous le traduisons ici quasiment intégralement :
Juste un petit mot pour vous signaler l’excellent travail et la persévérance des contributeurs de LinuxFr.org qui publient des dépêches sur les sorties de Firefox. Cette fois, ils titrent « Firefox 34, ce Hérault ». Nous saluons le jeu de mots (et de chiffres), mais il faut connaître ses départements 😉
La photo du fox est très sympa et nous nous permettons de la reproduire ici pour vous donner envie de lire l’article.
Robert O’Callahan, développeur chez Mozilla, rappelle sur son blog qu’Apple interdit à ses concurrents de produire un navigateur web autre que le sien sur iPhone, ce qui relativise l’appellation « Firefox pour iOS ». Traduction ci-dessous :
Quoi que nous fassions, nous ne porterons pas Firefox tel que nous le connaissons sur iOS. À moins qu’Apple change radicalement les règles de son App Store. Le plus gros problème, c’est que sur iOS, Apple oblige tout logiciel qui souhaite télécharger du contenu sur l’Iinternet, à utiliser leur composant Webkit. Avec cette règle, tous les navigateurs (dont Chrome) doivent plus ou moins n’être que des façades de Webkit d’Apple. Du coup, du point de vue des développeurs et des utilisateurs, tous les navigateurs web se comportent comme Safari (y compris dans leur bugs). Il est possible d’étendre les fonctionnalités de Webkit, mais c’est marginal. Grosso modo, les performances et les fonctionnalités sont restreintes à celles de Safari.
Je suis pour que Mozilla ait un logiciel sur iOS, et je ne suis pas forcément contre le fait de l’appeler Firefox, du moment que nous sommes très clairs dans notre façon de le présenter. D’une certaine façon, les utilisateurs et les développeurs web se sont déjà habitués à une telle confusion avec Chrome pour iOS. Mais, ce n’est pas la même chose pour Firefox : la différence entre Chrome et Chrome pour iOS est plus faible qu’entre Firefox et Firefox pour iOS parce que Blink (le moteur de Chrome) hérite en grande partie de Webkit. Mais, ces différences s’accroissent rapidement parce qu’il y a plein de nouvelles fonctionnalités dans Chrome et Firefox que Webkit n’a pas, par exemple : WebRTC, les Composants Web, les fonctionnalités ECMAScript 6, les Animations web.
En attendant, je pense que nous devons éviter de faire des déclarations lapidaires comme « nous portons Firefox sur iOS ».
Dans un article publié sur l’excellent ghacks.net, Martin Brinkmann explique qu’une des raisons pour lesquelles Mozilla travaille sur une architecture multi-processus, c’est que cela permettra d’avoir une sandbox pour Firefox. Qu’est-ce qu’une « sandbox » ? On pourrait traduire par « bac à sable », ce qui est une assez bonne illustration dans l’esprit « va jouer dans ton bac à sable et laisse-nous tranquilles » ! C’est en effet une architecture qui sécurise le fonctionnement d’un processus (Firefox, en l’occurence) de manière à ce qu’il ne puisse pas accéder à certaines ressources du système. C’est particulièrement important dans le cas d’une attaque via une faille. Dans ce cas, la faille ne permettra pas d’accéder à des ressources telles que le compte administrateur.
Le plus surprenant dans cette nouveauté, c’est que Mozilla part de la sandbox open source de Google, qui est utilisée dans Chrome et Chromium. Mozilla aurait pu repartir de zéro et créer sa propre version de ce composant logiciel, mais cela aurait été une perte de temps et d’énergie pour arriver peu ou prou au même résultat.
La sandbox de Firefox ne fonctionne que lorsque e10s est activé. C’est le cas pour toutes les compilations nocturnes (Nightly). Et si vous voulez tester cette sandbox, vous devez simplement télécharger une des Nightlies, et activer la préférence browser.tabs.remote.sandbox.
Dans un commentaire sous l’article, Martin répond à la question « Est-ce que cette sandbox va gonfler la consommation de mémoire de Firefox au niveau de celle de Chrome ? » par la négative. En effet, le plus gros impact sur la mémoire viendra de l’architecture multi-processus e10s, et les ingénieurs de Mozilla se sont engagés à faire en sorte que e10s augmente le moins possible la consommation de mémoire.
En bref, Mozilla s’apprête à relever le défi de prendre le meilleur de Chrome et faire mieux en terme de mémoire. C’est le genre de défi qu’on aime ! Plus d’infos sur le wiki de Mozilla, d’où provient l’illustration de cet article.