Projet de Spécialité Contribution à Firefox - Ensiwiki

Projet de Spécialité
Contribution à Firefox
Charly Molter, Zoé Bellot, Alexandre Dumont, Grégoire de Montullé
Projet de spécialité
Ensimag 2012
Ce projet de spécialité consiste à contribuer à Mozilla Firefox, le navigateur Web libre et
gratuit développé et distribué par la Mozilla Foundation avec l'aide de centaines de
contributeurs. Il totalise plusieurs millions d’utilisateurs dans le monde et représente un projet
très volumineux. Concrètement, notre équipe est chargée de corriger un bug dans le moteur de
rendu des pages Web (Gecko) ainsi que d’étendre une fonctionnalité utilisateur sur la version
mobile du navigateur. Le projet s’organise sur quatre semaines et le rythme de travail est
cadencé selon le principe des méthodes Agiles.
I - Contexte du projet
1 - HTML5 / CSS3
HTML5 et CSS3 sont les derniers volets de la norme HTML/CSS du W3C. Ils ajoutent
de nombreuses possibilités aux navigateurs et une grande partie de ces normes vise à faciliter
l’utilisation des formulaires (validation, ergonomie...). Comme Mozilla Firefox se veut d’être un
navigateur qui respecte pleinement les standards les plus récents, la communauté travaille
activement au support de ces deux derniers.
2 - Architecture de Firefox
Le navigateur Web Firefox possède une base logicielle partagée avec les produits
Mozilla (client de messagerie Thunderbird, calendriers Sunbird, suite d’applications
Seamonkey...). Cette base commune comporte plusieurs modules et outils utilisés par Firefox
pour fonctionner correctement :
● Gecko, le moteur de rendu des pages Web. Il permet de générer un affichage graphique
des pages écrites en HTML tout en prenant en compte le style css.
● Necko, le moteur pour la connectivité réseau. Il assure la gestion des communications
réseaux, des sockets...
● XUL (XML-based User interface Language), un outil permettant la description
d’interfaces utilisateurs.
● SpiderMonkey, le moteur Javascript.
Lors de ce projet, notre équipe a principalement été amenée à manipuler le moteur de
rendu Gecko utilisé par Firefox, ainsi que sa version mobile s’exécutant sur le système
d’exploitation pour smartphones Android.
3 - Processus de développement
La communauté Firefox regroupe un grand nombre de contributeurs et les exigences de
qualité du logiciel imposent une hiérarchie et un contrôle rigoureux lors de l’ajout de code à la
base. Le processus de développement de Firefox est articulé autour de quatre grandes versions
du navigateur, qui représentent chacune une étape dans le processus :
2/11
Projet de spécialité
mozilla-central
(ou Nighlty)
Ensimag 2012
C’est la version de développement actif. Les nouvelles fonctionnalités et
les changements récents sont d’abord ajoutés à cette version, puis sont
longuement testés et remaniés si nécessaire. Cette version a un
caractère expérimental et peut ainsi parfois produire des comportements
inattendus (instabilité). C’est la version pour laquelle nous avons
contribué.
C’est la version alpha du navigateur. Sont retenues dans cette version les
fonctionnalités suffisamment stables pour être utilisées par le grand public
et/ou arrivées à maturité. Cette version comporte des bugs mineurs et
peut encore être soumise à des modifications.
mozilla-aurora
C’est la version d’essai du navigateur. Toutes les fonctionnalités
constituant cette version feront parties de la prochaine version de Firefox.
Elle ne comporte que des bugs très légers qui sont corrigés assez
rapidement.
mozilla-beta
C’est la version publique offerte au téléchargement à tous les utilisateurs.
Les seules modifications apportées sont des corrections de failles de
sécurité.
mozilla-firefox
Les versions mozilla-aurora et mozilla-beta n’ont pour seul but que de stabiliser les
changements retenus dans mozilla-central. Le processus de développement prend environ 16
semaines. Toutefois, de nombreuses fonctionnalités prennent plus de temps et mettent plus de
16 semaines à arriver dans la version publique de Firefox.
3/11
Projet de spécialité
Ensimag 2012
II - Contributions
L’objectif de ce projet est de comprendre une partie de la base de code de Firefox et de
corriger deux bugs liés à l’implémentation du navigateur qui interviennent dans la gestion des
formulaires HTML, et plus précisément les balises input et textarea. Concrètement, les deux
bugs à traiter sont :
●
L’ajout de la prise en charge de l’attribut inputmode à la balise input afin de permettre de
sélectionner le type de clavier affiché sur la version mobile (Android) de Firefox.
●
Une restructuration du moteur de rendu Gecko au niveau de la hiérarchie de la classe
nsTextControlFrame, classe assurant la gestion des entrées utilisateur (les balises
HTML input et textarea). En plus de faire gagner de la clarté au code, cette modification
permet de corriger d’autres bugs connus de Firefox qui avaient été mis de côté. Par
exemple, un bug récurrent a été résolu par cette correction : le padding dans les zones
de texte n’était pas pris en compte par le navigateur lorsqu’il était précisé en
pourcentage dans la feuille de style CSS.
1 - Ajout de l’attribut inputmode
Présentation du problème
Grégoire et Zoé ont travaillé sur la version Android de Firefox (nom de code du projet :
Fennec). Sous Android, il existe différents types de claviers virtuels, en fonction de ce que
l’utilisateur doit saisir dans une zone de texte (classique, numérique, majuscules, email, url...).
Deux types de claviers virtuels Android
4/11
Projet de spécialité
Ensimag 2012
Sur une page HTML, Firefox choisit le type de clavier pour une balise input en fonction
de la valeur de l’attribut type de la balise. Cependant, ceci n’est pas toujours satisfaisant. Par
exemple, si un site Web demande à l’utilisateur de saisir un numéro de carte bancaire, un
clavier numérique serait préférable alors que le type de donnée n’est pas un entier mais plutôt
une chaîne de caractère
< input type=”text” /> → le type correspond bien mais le clavier n’est pas le bon
< input type=”numeric” /> → le clavier est le bon mais le type ne correspond pas
C’est pourquoi un nouvel attribut inputmode a été ajouté à la balise input dans la norme
HTML5. Cet attribut permet de spécifier quel type de clavier virtuel doit être utilisé pour la saisie
par l’utilisateur, en gardant le type de données voulu. Pour l’exemple de la carte bleue, on peut
alors utiliser : < input type=”text” inputmode=”numeric” />.
L'attribut inputmode est censé être prioritaire sur type pour le choix du clavier, mais la
communauté a préféré faire l'inverse – si type impose un certain clavier, il est prioritaire sur
inputmode – pour s'assurer de ne rien casser dans ce qui était géré avant. En effet, l'attribut
inputmode est tout nouveau et on n'est pas encore certain de la façon dont il sera utilisé.
Implémentation
Déclaration de l’attribut inputmode de la balise input
Pour ajouter ce nouvel attribut à la balise input, il a fallu trouver où étaient gérés les
autres attributs. Ensuite, il a suffit de déclarer cet attribut en s’inspirant de ce qui existe déjà
pour les autres, en précisant les valeurs possibles de cet attribut. Dans un premier temps
(premier sprint du projet), nous avons simplement considéré une valeur auto, valeur par défaut,
et la valeur numeric qui permet l’affichage d’un clavier numérique. Nous avons aussi rajouter un
cas dans le parser HTML appelé par la fonction GetAttr qui permet de récupérer la valeur d’un
attribut.
Après avoir déclaré cet attribut et testé qu’il était bien reconnu (utilisation de la base de
tests automatisés de Firefox et plus précisément des Mochitests), un premier patch a été
soumis à la communauté Firefox, puis revu par notre mentor Mounir Lamouri et par un autre
membre de la communauté, ce qui a permis d’améliorer notre code en suivant leurs remarques.
Gestion du clavier virtuel Android
Ensuite, il a fallu se renseigner sur le développement Android pour comprendre
comment est géré l’affichage du clavier virtuel, et à quel niveau le choix du bon clavier est
effectué. Nous avons compris que c’est l’attribut inputType qui est utilisé par Android. Cet
attribut peut prendre différentes valeurs prédéfinies pour les différents claviers1.
Nous avons trouvé la façon dont il est traité dans le code de Fennec pour l’affichage des
claviers en fonction de la valeur de l’attribut type d’une balise HTML input. Nous avons en
conséquence suivi exactement la même démarche pour l’attribut inputmode. On donne la
bonne valeur à la variable inputType en fonction de la valeur de l’attribut inputmode de la balise
HTML. Un deuxième patch a été soumis pour review à Firefox et là encore des retours nous
sont parvenus et le code a été modifié en conséquence.
1
http://developer.android.com/reference/android/text/InputType.HTML
5/11
Projet de spécialité
Ensimag 2012
Ajout de nouvelles valeur pour inputmode
Sur demande de Mounir Lamouri, d’autres valeurs possibles ont été ajoutées pour
l’attribut inputmode, et les claviers correspondants ont été gérés. L’attribut inputmode gère
actuellement les valeurs suivantes :
● 'numeric' : 0-9, +, -, virgule, point
● 'digit' : 0-9 seulement
● 'uppercase' : A-Z seulement
● 'lowercase' : a-z seulement
● 'titlecase' : majuscule pour la première lettre de chaque nouveaux mot
● 'autocapitalized' : première lettre de chaque phrase en majuscule
Il n’y a pas actuellement de clavier Android composé uniquement de chiffres, Firefox
gère donc pour le moment les attributs ‘numeric’ et ‘digit’ de manière identique.
2 - Restructuration de Gecko - gestion des balises input et textarea
Fonctionnement de la mise en page (layout) dans Firefox
Dans Firefox, le rendu d’une page Web (écrite en HTML et formatée par une feuille de
style CSS) se fait via le moteur de rendu Gecko. Afin d'interpréter du code HTML/CSS en un
affichage graphique cohérent et dynamique, Gecko passe par différentes étapes. Lors de ces
étapes, le code HTML est interprété puis traduit sous forme d’arbre de Frames (cadres).
Concrètement, une page se divise en plusieurs cadres dans lesquels sont placés les divers
éléments constituant la page (images, tableaux, zones de texte...). Il existe de nombreux types
de Frames, chacune spécialisée dans le rendu graphique d’une ou de plusieurs balises HTML.
De façon générale, chaque Frame dispose de caractéristiques qui lui sont propres, comme ses
dimensions et le style CSS qui doit lui être appliqué lors de l’affichage.
Cet arbre sert de support à l’affichage de la page telle qu’elle est présentée à
l’utilisateur. A chaque nouvel évènement (e.g. lorsque l’utilisateur redimensionne la fenêtre,
lorsque la page doit être chargée ou encore lorsque son contenu est modifié dynamiquement),
cet arbre est susceptible d’être modifié : le processus de rafraîchissement de l’arbre de Frames
s’appelle le Reflow, et s’applique sur chacune des Frames de l'arbre qui en a besoin.
Chaque Frame est chargée de calculer sa taille et son emplacement dans la fenêtre du
navigateur, en fonction de son père et de ses fils dans le Frame Tree, ainsi que de son style
CSS. Lorsqu’une opération de Reflow est lancée sur une Frame, celle-ci se rafraichit (met à jour
son état, ses dimensions, ses caractéristiques...) et rafraichit ses enfants dans l’arbre si besoin.
La mise en page étant une opération graphique, elle est coûteuse et doit donc être légère et
éviter tout calcul redondant.
6/11
Projet de spécialité
Ensimag 2012
Fonctionnement du layout - du HTML à l’affichage graphique
Présentation du problème
La partie de Gecko sur laquelle nous travaillons concerne le rendu graphique des
balises input et textarea. Au sein de l’arbre de Frames, ces balises sont gérées dans une
Frame nommée nsTextControlFrame dans la base de code de Firefox. L’implémentation des
Frames dans le navigateur induit un héritage entre ces éléments. Dans le cas des deux balises
HTML qui nous intéressent, cet héritage n’est pas satisfaisant car il provoque des bugs lors du
rendu.
L’implémentation actuelle de nsTextControlFrame hérite de celle de nsStackFrame.
Toutefois cet héritage n’est pas nécessaire et les particularités de nsBoxFrame (cf schéma ciaprès) font que les balises input et textarea sont mal affichées dans certains cas particuliers.
Par exemple, le padding précisé en pourcentage dans le CSS n’est pas supporté pour ces
zones de texte (exemple suivant).
Input - Padding : 4% non supporté
7/11
Projet de spécialité
Ensimag 2012
Le travail à faire consiste à remonter cette relation d’héritage au niveau de
nsContainerFrame, et cette restructuration permettra de faciliter la résolution d’autres bugs par
la suite.
Héritage des classes à remanier
Restructuration et validation
Le changement d’héritage impose un remaniement quasi total de nsTextControlFrame. Il
a fallu réimplémenter l’opération de Reflow et la façon dont sont calculés la taille et le
positionnement de la Frame dans la page affichée par le navigateur.
De plus, il a fallu s’assurer que la modification de l’héritage ne change pas l’affichage
actuel des balises concernées (non régression). La validation de la restructuration passe par
une batterie de tests hébergée sur les serveurs de Mozilla. Le navigateur offre aussi des outils
de debug utiles pour corriger notre implémentation. Désormais, notre patch propose une
réimplémentation de cette Frame et corrige aussi le bug lié au padding (cf précédemment).
Input - Padding : 4% supporté
8/11
Projet de spécialité
Ensimag 2012
3 - Gestion de projet
Pour le projet, nous avons choisi d’utiliser les méthodes Agiles. Ce choix est justifié par
la difficulté d’évaluer à l’avance le temps des tâches à faire, en particulier pour la restructuration
du code de Gecko au niveau de nsTextControlFrame. Nous avons décidé de travailler en trois
itérations pour l’ajout de l’attribut inputmode et en deux itérations pour la modification de
l’héritage dans le moteur de rendu.
Burndown du projet
Ci dessus, la courbe verte représente l’évolution du travail pour l’ajout de l’attribut
inputmode (3 sprints) et la courbe orange montre l’avancée pour la restructuration du
moteur de rendu (2 sprints).
9/11
Projet de spécialité
Ensimag 2012
III - Communauté Mozilla
Nous sommes entrés en contact avec la communauté Firefox par l’intermédiaire de
Mounir Lamouri, employé de Mozilla Corporation depuis deux ans. Il a été notre mentor pendant
les quatre semaines, en suivant de près l’évolution du projet. C’est avec lui que nous avons
défini les objectifs que nous nous sommes fixés, il a été notre interlocuteur privilégié pour
répondre à nos questions et il s’est chargé de relire le code que nous avons proposé à la
communauté pour nous faire des remarques. Nous avons eu l’occasion de le rencontrer dans
les locaux de Mozilla à Paris lors d’un rassemblement de la communauté francophone.
1 - Soumission de patchs
Une contribution à Mozilla s’effectue sous forme de soumission d’un patch. Une fois le
code modifié et testé, le patch est proposé sur la page du bug correspondant. Ensuite, un
système de review se met en place. Des personnes habilitées - souvent une ou deux - relisent
le code proposé et font des remarques en retour. Le contributeur peut alors modifier son patch
pour en proposer un nouveau, et ainsi de suite jusqu’à ce que la communauté accepte les
modifications. Une revue de code peut prendre entre 2 jours et 6 mois, c’est pourquoi Mounir
Lamouri nous a aidé à faire accélérer les choses, soit en relisant lui-même le patch, soit en
demandant à d’autres de le faire.
Les reviewers ne sont pas là pour modifier et améliorer le code soumis de façon à le
rendre acceptable. L’esprit est vraiment de laisser le contributeur travailler jusqu’au bout, et s’il
ne corrige pas son code en fonction des remarques, le travail sera perdu jusqu’à ce que
quelqu’un d’autre s’y intéresse.
2 - Communication
La communication est un atout clé dans le développement du logiciel libre. La
communauté échange ainsi via IRC. Pendant quatre semaines, nous avons eu l’occasion de
discuter avec des contributeurs d’origines très différentes, mais aussi avec des employés
influents de Mozilla dont les conseils sont pertinents et adaptés. Il y a toujours quelqu’un pour
répondre à une question sur les différentes chaînes thématiques : introduction, mobile,
francophone, développeurs...
Les channels IRC intéressants sont #developers, #introduction et #mozfr (canal de la
communauté française). Une autre partie de la communication se fait par mailing-lists, toutefois
les discussions se font le plus souvent sous forme de débats sur des nouvelles fonctionnalités
plutôt que des explications. Le dernier vecteur d'échange de la communauté est Bugzilla,
puisque chez Mozilla tout passe par des bugs (y compris la demande de droit d'accès au
serveur de tests).
10/11
Projet de spécialité
Ensimag 2012
IV - Bilan
1 - Bilan de l’équipe
Ce projet nous a beaucoup appris. Tout d’abord, nous avons découvert ce que c’est que
de contribuer à un logiciel libre. Nous nous sommes intégrés à une communauté en échangeant
sur IRC, en posant des questions et en proposant des solutions. Nous avons même eu la
chance de rencontrer nos interlocuteurs français lors d’un rassemblement de la communauté
francophone dans les locaux de Mozilla à Paris.
Nous avons dû faire des efforts pour répondre aux exigences de qualité. Nous avons
aussi appris à ne pas paniquer avant de travailler sur une base de code déjà très conséquente
et à bien se documenter avant de se lancer. Tout cela nous a forcé à être très autonomes, à
interagir avec des personnes très qualifiées, et nous a donné l’opportunité de travailler sur un
projet concret et professionnel.
De plus, nous nous sommes familiarisés avec de nouveaux outils utilisés par la
communauté :
● MXR : un outil en ligne pour parcourir la base de code de Mozilla
● Des bases de tests automatisées
● Mercurial : tout particulièrement les queues pour gérer les patchs
● L’environnement Android : cette partie a été à l’origine de plusieurs difficultés. Nous
avons d’abord appris à développer des applications simples sur Android, avant de
mettre en place un environnement pour Fennec, qui est plus complexe.
2 - Bilan de l’enseignement
Nous avons particulièrement apprécié que l’Ensimag nous donne la possibilité de
travailler sur un projet professionnel et complétement extérieur à l’école. C’est une excellente
occasion de découvrir, d’apprendre de nouvelles façons de travailler et d’enrichir nos
expériences professionnelles.
Nous avons aimé pouvoir évoluer de façon très autonome, en ayant une salle réservée
pour nous et un encadrant qui visiblement nous faisait confiance tout en restant assez
disponible.
11/11