Crash Firefox 17 et +, qu'en est-il ?

En fin d'année dernière, je rédigeais un article vous demandant d'ignorer la mise à jour vers Firefox 17 ; qu'en est-il aujourd'hui ?

Comme je l'avais promis dans l'article précédent je reviens vers vous pour vous indiquer où l'on en est sur ce sujet qui vous empêche d'utiliser Firefox à partir de sa version 17. Je vous laisse découvrir en fin d'article la chronologie.

Outre le fait de vous donner des nouvelles sur ce bug (indépendant de RBS Change), le but de ce billet est aussi de revenir sur les questions auxquelles j'ai répondu fréquemment ces derniers mois que ce soit durant mes déplacements, sur le forum, par mail, téléphone ou pigeon voyageur.

Pour nous aider à faire bouger les choses, n'hésitez pas à voter pour augmenter le niveau de criticité du bug sur le ticket bugzilla 813897. Vous pouvez aussi tweeter ce billet et retweeter nos tweets qui pourraient faire référence à ce problème (vous pouvez aussi retweeter nos autres tweets bien entendu ;)).

Où puis-je obtenir la version 10 ESR de Firefox ?

Jusqu'à il y peu la version était disponible facilement via la page dédiée aux versions ESR. La version ayant disparue vous pouvez télécharger cette version ici :

• Version portable pour Windows : [fr] - [en_GB]
• Version MacOS X : [fr] - [en_GB]
• Version Linux 32 bits : [fr] - [en_GB]
• Version Linux 64 bits : [fr] - [en_GB]

Si les versions disponibles ici ne correspondent pas à votre langue de travail, vous pouvez suivre directement le lien télécharger Firefox v10 ESR sur les serveurs de Mozilla.

Pourquoi avoir cette dépendance à Firefox ?

Vers 2005, quand nous avons commencé la refonte de l'ancêtre de RBS Change (à l'époque où le logiciel était propriétaire), nous voulions avant tout fournir une expérience utilisateur riche. Ceci impliquait de pouvoir faire du drag'n'drop, que ce soit pour manipuler des éléments dans le backoffice ou pour uploader des médias, ainsi que quelques autres fonctionnalités. A cette époque, les frameworks AJAX n'étaient pas encore aussi développés ni même matures pour être utilisés en production (jQuery n'existait pas encore ; première version janvier 2006)  et c'est pourquoi nous avons choisi XUL qui répondait à ces besoins.

Aujourd'hui pour les développeurs, XUL est très peu présent puisque tout est généré pour eux, ainsi lorsqu'ils doivent déclarer des interfaces pour le backoffice, cela se fait par l'intermédiaire d'un fichier de configuration au format XML.

Est-ce la première fois que vous rencontrez ce type de problème avec Firefox ?

Non nous avons déjà rencontré des problèmes d'accès au backoffice ; au début il n'y avait pas besoin d'extension pour se connecter au backoffice. Nous avons rencontré un premier problème de connexion au backoffice suite à l'évolution de Firefox. Dans ce cas, nous avions obtenu un délai avec une correction permettant le fonctionnement du backoffice en contrepartie du développement de l'extension, chose que nous avons faite. Par la suite nous avons rencontré d'autres petits désagréments, mais qui ont à chaque fois été corrigés dans de courts délais.

Habituellement au bout de combien de temps la correction est-elle disponible ?

A l'époque où nous avions remonté des problèmes, la correction était disponible dans la mise à jour suivante de Firefox. Mais le rythme des mises à jour de Firefox a beaucoup accéléré depuis.

Il faut dire que depuis que Mozilla a changé le rythme de release de Firefox en se rapprochant du rythme de Chrome nous n'avions plus eu de problème jusqu'à cette version 17... Cela fait maintenant plus d'un mois qu'il nous a été indiqué qu'une relecture du patch correctif allait être faite, mais sans nouvelle à ce jour. Nous ne pouvons que constater qu'il y a un changement dans le traitement, mais ne pouvons donner d'information sur la correction du problème puisque nous n'arrivons pas à avoir cette information.

Allez-vous abandonner XUL et donc cette dépendance à Firefox pour le backoffice ?

OUI c'est prévu et nous n'avons pas attendu ce problème pour remettre en cause cette dépendance. En effet, nous avons commencé à réfléchir à cette problématique peu de temps avant l'annonce de l'abandon de XUL pour les terminaux mobiles.

Je pense que vous devinez que ce type de chantier est plutôt important et ne peut être réalisé du jour au lendemain, c'est pourquoi cette version ne devrait sortir qu'au courant de cette année.

Je ne reviendrai pas sur le sujet, pour les curieux, je les renvoie aux pages 82 et 134 (et suivantes) de la keynote d'octobre 2012 pour prendre connaissance des objectifs de la future v4.

Dois-je attendre la sortie de la v4 pour travailler avec RBS Change ?

NON vous pouvez travailler avec RBS Change dès aujourd'hui. Comme à notre habitude nous fournirons un patch ou des instructions afin de permettre une migration dans les meilleures conditions.
Par ailleurs, comme nous l'indiquons dans la keynote d'octobre 2012 (page 161) nous fournirons un support pour la version 3.6 au minimum jusqu'en mai 2015.

Chronologie

21/11/2012 : Ouverture du ticket de bug Firefox 813897. Le problème est identifié comme étant une régression de Firefox liée à la correction d'un autre bug.

28/11/2012 : Nous rappelons qu'il s'agit d'un bug critique pour nos utilisateurs et demandons une estimation pour la résolution du bug. Un patch est fournit le même jour, mais aucune date, ni version de résolution, ne peut être fournie.

02/12/2012 : Nous répétons que nous souhaitons avoir une idée au moins sur une version Firefox dans laquelle le problème serait résolu, étant donné l'impact que cela représente pour nos utilisateurs e-commerçants.

03/12/2012 : On nous répond qu'étant donné que le problème se pose dans de rares cas, il ne peut être considéré comme un bug critique pour la version 17 ESR et ne doit donc pas impacter la sortie de la version 18.

04/12/2012 : Nous indiquons que le problème est systématique pour nos utilisateurs et donc que la version 17 de Firefox est bloquante pour nos utilisateurs, tout en insistant sur le fait qu'il s'agit tout de même d'une régression. Dans le même temps on nous rappelle que XUL est un projet qui a baissé en priorité et que nous ferions bien de passer sur de l'HTML5, chose que nous avons indiqué comme prévue pour cette année, mais qu'en attendant il serait de bon ton que notre backoffice puisse à nouveau fonctionner.

18/12/2012 : La personne ayant relu le code à l'origine de la régression indique qu'il ne peut pas relire le code du patch nous concernant car il ne connaît pas la globalité du code. La personne à l'origine du patch lui rappelle qu'il a une responsabilité dans cette régression mais lui indique une personne vers laquelle rediriger la relecture du patch s'il ne se sent pas à l'aise dans cette partie du code de Firefox.

11/01/2013 : La personne à l'origine du patch demande des nouvelles au relecteur s'il accepte de relire le patch ou de transférer la tâche de relecture. On nous indique alors que la tâche de relecture sera effectuée la semaine suivante une fois la tâche en cours achevée.

07/02/2013 : Nous demandons des nouvelles concernant la relecture du patch et une estimation de quand ce sera fait. Nous rappelons par la même occasion l'impact du bug vis-à-vis des utilisateurs.

10/02/2013 : La personne à l'origine du patch fait un rappel amical au relecteur.

22/02/2013 : Nous faisons une nouvelle demande d'état de la relecture avec un rappel de l'impact utilisateur, suivi de la rédaction de cet article.

Si vous êtes curieux vous pouvez suivre l'évolution du ticket de bug Firefox 813897.